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

Dear Lars,

Thank you for the constructive responses!

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

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/), and that
requirements about the internal structure of profiles
would properly belong in best-practice guidelines --
not in CONNEG per se.

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

> > • Define "profile" in terms general enough to
> > encompass the use of a namespace URI for the content
> > negotiation process described in this spec, e.g.,
> > where the value of the Accept-Profile header might be
> > http://purl.org/dc/terms/. 
> 
> We prefer the second solution, too. Profile definition
> is currently work-in-progress (again); we will revisit
> explanations to make this clearer once that has been
> settled.

Excellent.

> We have already dropped the notion of a ‘base
> specification’ (see [4]) being a specific class of
> things - so again we need to make this clearer.

+1

> > • An HTTP request does not return a "list of profiles" (see
> > above), but a list of URIs (or mappable tokens). This point
> > could be made more precisely.
> 
> Agreed

+1

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

> Agreed - will add a paragraph about the need to have flexibility in the delivery of content and the client to be able to understand what is returned.

Fine.

> Once again thanks for your feedback. We hope that this response clarifies our intent.

Thank you for the responses!  If I am reading the
responses correctly, my remaining objections appear to
concern things that I had always assumed to be outside
the scope of CONNEG per se.  Would you agree?

Tom

-- 
Tom Baker <tom@tombaker.org>

Received on Friday, 12 July 2019 09:41:31 UTC