Re: Re: Comments on "Content Negotation by Profile" (30 April)

I'm confused by this conclusion: "So yes, that means that many profiles
that exist in the wild currently cannot be used for content negotiation on
profile."

The question, however, is about parts of documents: "In order to be able to
use profiles specified as parts/sections of larger documents, those
profiles/sections need their own URIs." Should the above sentence read
instead: "... many profile sections or fragments that exist in the wild
...."? or "... many profiles that are sections or fragments of larger
resources ..." Because a document that is a profile and that has a URI can
be used for content negotiation, e.g. DCAT-AP in PDF form. True? It's just
that sections within that document, if they cannot be accessed through a
fragment URI, cannot.

I believe that the set of profile documents that do not have URIs, and
therefore are not online, are outside of the scope of conneg. Are there any
resources that meet the definition of profile and that have a URI that are
outside the scope?

On Mon, Aug 5, 2019 at 12:50 AM <lars.svensson@web.de> wrote:

> Dear Tom,
>
> On Dienstag, 16. Juli 2019 um 11:49 Uhr lars.svensson@web.de scripsit:
>
> > On Freitag, 12. Juli 2019 um 11:41 Uhr, Thomas Baker scripsit:
> >
> > > > > The CONNEG draft characterizes DCMI Metadata Terms
> > > > > (DCMIMT) as a profile, where the definition of
> > > > > "profile" distinguishes between profiles and base
> > > > > specifications on which profiles are based.
> > > >
> > > > This issue is related to the problem of identifying
> > > > profiles (and specifications) when embedded in
> > > > documents with multiple sections or performing multiple
> > > > roles, where clear identification of the conformance
> > > > requirement is not available.
> > >
> > > The ODRL example looks fine, but does this mean that if
> > > sections of those documents were not clearly defined, any
> > > DCAT profile (or indeed most profiles that currently
> > > exist in the wild) would not be suitable for content
> > > negotiation as per CONNEG?
> >
> > That's a fair question and something we'll need to discuss.
>
> On Thursday, August 1, the CNEG subgroup discussed your question about the
> identification of profiles that are embedded in documents [1]. Following
> the spirit of Issue #1017 [2], we resolved on the following:
>
> In order to be able to use profiles specified as parts/sections of larger
> documents, those profiles/sections need their own URIs. Those URIs can be
> constructed as fragment of the URIs of their embodying specification URI or
> be independent thereof. If the profile does not have a URI of its own, it
> is not possible to perform content negotiaion for representations
> conforming to that profile.
>
> So yes, that means that many profiles that exist in the wild currently
> cannot be used for content negotiation on profile. Communities are
> encouraged to use some (other) URI space to mint URIs for those profiles
> and refer back to the original specification through a textual note. E. g..
>
> @prefix definitionUriSpace: <https://example.org/specs/>
>
> profileUriSpace:profileOfSomeOtherSpecification a prof:Profile ;
>     rdfs:label "Profile of Other Specification" ;
>     dct:definition """This is a profile of the Other Specification as
> specified in
>         'Insert Name of Your Specification Here'. Please refer to
>         <https://example.org/specs/otherSpecification.pdf> §18.4 for the
>         formal definition""" ;
>     rdfs:seeAlso definitionUriSpace:otherSpecification.pdf .
>
> Does this resolve your question?
>
> [1] https://www.w3.org/2019/08/01-dxwgcneg-minutes#x04
> [2] https://github.com/w3c/dxwg/issues/1017
>
> Best,
>
> Lars for the CNEG subgroup
>
> ACTION-355
>
> > > I always thought that the spirit of CONNEG was to be
> > > liberal about may be used as a URI for content
> > > negotiation (e.g., even purl.org/dc/terms/),
> >
> > From a conneg point of view, the profile URI can point to anything
> (including nothing, i. e. the profile URI can return 404).
> >
> > In the IETF document we say that _if_ the profile URI is a protocol URI
> (http/https/ftp/sftp/...) it SHOULD resolve to a resource with a profile
> description. This is something we need to make more explicit in the conneg
> document. A further possibility is to constrain this further and say that
> the profile URI SHOULD resolve to a profile description and that the server
> SHOULD use content negotiation (by profile) to serve the best available
> representation of the profile. The client can ask for a specific profile of
> the profile (e. g. a ShEx version) and then the server would return a ShEx
> document that can be used for validation. If the client does not specify
> any specific representation of the profile URI, the server can return any
> representation it wishes and in many cases that might be a PDF document
> with only human-readable information, but it can also be a profile
> description document using the PROF vocabulary so that the client can
> figure out which representations of the profile are available.
> >
> > That said, I agree that
> >
> > > requirements about the internal structure of profiles
> > > would properly belong in best-practice guidelines --
> > > not in CONNEG per se.
> >
> > Yes, that's outside of Conneg. Would be part of the profile guidance
> document, if that's written.
> >
> > > > The DCMI community may choose to consider "application
> > > > profiles" to be exclusively profiles of its published
> > > > specification(s) (vocabulary),
> > >
> > > I see why you would say this but need to clarify a point.
> > >
> > > For many years, the Dublin Core community has broadly
> > > used the term "Dublin Core application profile" to refer
> > > not to a profile specifically of DCMI Metadata Terms, but
> > > to a profile in the style that has emerged in the DC
> > > community since 1999, of mixed-vocabulary profiles --
> > > irrespective of whether DCMI metadata terms are even used
> > > in the profile at all.  In other words, the DC concept of
> > > profile is quite ecumenical and would include profiles
> > > that consist entirely of terms from Schema.org or BIBFRAME.
> >
> > OK. Thank you for this clarification. Do you see any need for us to
> update the Conneg document with this information or would you say that it
> should be handled in Profile Guidance?
> >
> > [...]
> >
> > > > Agreed - the OpenGeospatial Consortium has a concept of
> > > > "conformance target" for its specifications
> > > ...
> > > > :myProfile a dct:Standard, prof:Profile ;
> > > >     prof:conformanceTarget my:ClassOfThingsThatConformToMyProfile .
> > >
> > > Okay... but surely this is in the realm of best practice
> > > for profiles -- and outside of the scope of CONNEG?
> >
> > Yes, that's outsied of conneg.
> >
> > Thanks for your contribution!
> >
> > Best,
> >
> > Lars
>
>

-- 
--  ---
Karen Coyle / Digital Library Consultant
kcoyle@kcoyle.net http://www.kcoyle.net
skype: kcoylenet
mo.: 510-435-8234
------------------------------------