- From: Thomas Baker <tom@tombaker.org>
- Date: Fri, 12 Jul 2019 11:41:02 +0200
- To: public-dxwg-comments <public-dxwg-comments@w3.org>
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