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

Dear Tom,

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.

> 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, 

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 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!



Received on Tuesday, 16 July 2019 09:49:39 UTC