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

Sorry, forgot to put the WG list in cc...

> Gesendet: Montag, 05. August 2019 um 09:49 Uhr
> Von: lars.svensson@web.de
> An: "Thomas Baker" <tom@tombaker.org>
> Cc: public-dxwg-comments <public-dxwg-comments@w3.org>
> Betreff: Aw: Re: Comments on "Content Negotation by Profile" (30 April)
>
> 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
> 
>

Received on Monday, 5 August 2019 07:55:51 UTC