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

Dear Tom,

Thank you very much for your constructive comments. I apologise for the delay in answering to them!

We have disussed your comments in several CNEG meetings but needed some additional time to clarify some of the details.

> 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. We will remove this example and instead highlight the ODRL case where profile identification is explicit. The implication is that the DCMIMT community will need to publish identifiers for profiles that can be "conformed to" in order to be referenced in Conneg-by-AP context.

In the ODRL case, the ODRL Information Model 2.2 [3] document also performs multiple roles but specifies a "Core Profile" (https://www.w3.org/TR/odrl-model/#profile-core) which is the conformance target. There ODRL states that "in circumstances that require the ODRL Core Profile to be identified, that is the Policy _only_ conforms to the ODRL Core Vocabulary, then the following identifier MAY be used for the Core Profile: http://www.w3.org/ns/odrl/2/core" so this latter URI is what’s used to request or show conformance to ODRL.

> DCMI itself defines DCMIMT as a vocabulary, aka namespace.  Ever since 1999, the
> Dublin Core community has talked about how such vocabularies (namespaces) are
> "used" in "application profiles" [2].  Application profiles use vocabularies;
> a vocabulary is not itself considered to be an application profile. 

This seems to be mainly a matter of perspective. The DCMI community may choose to consider "application profiles" to be exclusively profiles of its published specification(s) (vocabulary), but a broader community may, for example, see the DCMIMT vocabulary to be a profile of RDF.  This is consistent with the reasoning that profiles define sets of conforming resources that are subsets of the set conforming to a base (profiled) specification - any class is a subclass of itself - so it doesn’t matter where you choose to start from, the single mechanism of treating all such content specifications as profiles provides the simplest way of dealing with this choice. 

The interpretation is that a community may use the term "profile" in a specific context, and may choose to model profiles within that context. The goal of the DXWG here is to allow any community to use a common approach that can be used across different scopes. 

When identifying the conformance target for DCMI-related content, the namespace URI of DCTMIMT, http://purl.org/dc/terms/, could possibly be used to identify its conformance target, as ODRL’s Core Profile URI is used for ODRL-related content.

> Anyone familiar to this model would likely be confused by seeing DCMIMT referred to as a profile.

We will need to improve the explanation to avoid such confusion. Since we refer to DCAP in the Introduction and the Singapore Framework in the Related work sections, we have a couple of places to naturally add to the new/different ways that PROF is describing things. It’s now (for PROF 3rd PWD) on the agenda to do this work.  

>> For example, information about an online book might adhere to the
>> Dublin Core Terms [DCTERMS] metadata specification with each field,
>> such as title, description, author etc., being defined and formatted
>> according to various Dublin Core elements (dct:title, dct:description
>> & dct:creator, respectively).

> DCMIMT, as a vocabulary specification, presents itself as a dictionary
> of terms available to be drawn on and used in a profile, not as a set
> of terms that must be used _in its entirety_ in a metadata record or format.
> Nothing in the DCMIMT specification says that "each field" in the "information
> about an online book" (i.e., its metadata) needs to be "formatted" according
> to the vocabulary.  

> In the Dublin Core context, an application profile typically uses just
> a selection terms from DCMIMT, typically in combination with selected
> terms from other namespaces, such as FOAF.  

> One obvious example of an application profile in the Dublin Core sense
> is DCAT, which uses terms from nineteen namespaces.  In Dublin Core
> terminology, those namespaces -- OWL, RDFS, PROV, etc -- would not
> themselves be called "profiles" or "application profiles". In CONNEG
> terms, DCMIMT and the other namespaces are DCAT's "base specifications".  

> Accordingly, it would be unusual to say that some metadata "adheres"
> to a vocabulary (such as DCMIMT), though one might reasonably say
> that some metadata "adheres" to an application profile.

We see the proposed model as consistent with all these cases. In the proposed model, the usage of the term "profile" is -- compared with the DCMI processes -- relaxed to meet the more general concept, where base specifications are just a role and every vocabulary can be thought of as a trivial profile of itself (an empty set of constraints). Then the mechanisms for referencing any form of specification is the same, and a profile is just a form of specification. (We could say this is content-negotiation-by-conformanceToSpecification, but the term ‘profile’ is simpler, and reminds people that a specification may be a specialised version of another more general one.)

> I see two possible solutions.  The first:
> • Avoid referring to base specifications such as
> DCMIMT (and other namespace vocabularies) as profiles.
> • Use DCAT as the flagship example of a profile, perhaps
> pointing out that it uses terms from nineteen namespaces
> (its "base specifications").

> • Provide a definition for "constraint" -- a central concept
> here inasmuch as "profiles" are defined as "sets of constraints".

> • Reword the definition of "profile" to acknowledge that a
> profile, such as DCAT, may include more than just a set of constraints.

> The second solution, which I strongly prefer:

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

> • Drop the notion of "base specification" from the definition
> of "profile". In the entire CONNEG draft, it mentioned _only_
> in the context of defining "profile", so dropping it would require
> no further changes.

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.

> • A definition might be as simple as: "Any document or schema
> that formally or informally describes the content of structured data".
> I see no obvious requirement, in this spec, for a definition that is
> any more precise or specific.

The notion of profiles is more general than this (a document or a schema): it is up to communities to determine the scope of what may be specified. The DXWG definition is currently under discussion in #963 [5] and we’ll adopt that.

> • The spec could simply say that content negotiation would
> "typically" use the URIs of application profiles, in a broad
> sense that includes Dublin Core Application Profiles, ShEx schemas,
> SHACL graphs, XML formats… This would not disallow the use of URIs
> of things that are not commonly considered profiles, such as namespace
> documents.

No normative change in the specification is necessary as this is already the intent, however improved explanations and examples around this need to be provided.

> A few additional points of detail:

> • References to DCMIMT should refer to it by its title,
> "DCMI Metadata Terms", not as "Dublin Core Terms".

We’ll fix that [6].

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

> • The concept of "adherence", which appears to be quite
> central to the specification, should be defined or explained.

Agreed - the OpenGeospatial Consortium has a concept of "conformance target" for its specifications - we have tried to avoid getting into the general problem of defining a model for specifications, but lack of one is hurting when trying to understand that all specifications may just be profiles of something more abstract.  We need to push this up to the level of dct:Standard - so defining a property such as "conformanceTarget" whose domain is dct:Standard and whose range is any rdfs:Class (the type of thing that can conform to the Standard) could allow us to be clearer about the nature of specifications.

:myProfile a dct:Standard, prof:Profile ;
    prof:conformanceTarget my:ClassOfThingsThatConformToMyProfile .

> • Section 4 (Motivation) goes straight into technical
> details but should, instead, articulate an overall
> motivation for this work.

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.

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

Best,

Lars

[1] https://www.w3.org/TR/2019/WD-dx-prof-conneg-20190430/ 
[2] http://www.ariadne.ac.uk/issue25/app-profiles 
[3] https://www.w3.org/TR/odrl-model/
[4] https://github.com/w3c/dxwg/issues/641
[5] https://github.com/w3c/dxwg/issues/963
[6] https://github.com/w3c/dxwg/issues/992

Received on Friday, 12 July 2019 07:35:22 UTC