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

The working draft "Content Negotation by Profile" of 30
April [1], Introduction, second paragraph, reads:

    When online information about a resource adheres to
    one or more profiles, methods described here allow
    clients to list those profiles and request content
    according to one or more of them in order of
    preference. 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). Then, a request for the information
    about this book may ask for the list of profiles
    according to which the metadata is available, or it
    may ask specifically for a response adhering to the
    Dublin Core Terms. When no profile or an unsupported
    profile is requested, a server returns default
    content, that is, content conforming to the default
    profile supported by the server.

...where "profile" is defined as:

    A named set of constraints on one or more identified
    base specifications, including the identification of
    any implementing subclasses of datatypes, semantic
    interpretations, vocabularies, options and parameters
    of those base specifications necessary to accomplish
    a particular function.

    This definition includes what are often called
    "application profiles", "metadata application
    profiles", or "metadata profiles".

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.

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.  Anyone familiar
to this model would likely be confused by seeing DCMIMT
referred to as a profile.

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

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 negotation
  process described in this spec, e.g., where the value
  of the Accept-Profile header might be 
  http://purl.org/dc/terms/.

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

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

A few additional points of detail:

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

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

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

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


Tom Baker, Chair, DCMI Usage Board



[1] https://www.w3.org/TR/2019/WD-dx-prof-conneg-20190430/
[2] http://www.ariadne.ac.uk/issue25/app-profiles

Disclaimer: While members of the DCMI Usage Board
provided helpful feedback on a draft of these comments,
the text was not put to a formal vote so the comments
should be considered mine.

-- 
Tom Baker <tom@tombaker.org>

Received on Tuesday, 14 May 2019 10:41:47 UTC