ACTION-328: Draft replies to tom's email in a new gh issue

https://lists.w3.org/Archives/Public/public-dxwg-comments/2019May/0001.html

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.

R : thanks for clarifying your assumption here. This seems to be the key issue here, and suggests we need to revisit our explanation yet again. We need to make it clearer that, as the profiles ontology itself states: “The subject of 'is profile of' defines constraints on the object which plays the role of a base specification”. “Specification” was chosen as the term although the formalism is that the range is dct:Standard - as even though the definition of dct:Standard is adequate and open enough, but the name confuses people expecting it to apply to formal Standardisation processes. “Specification” does imply an unambiguous set of rules (or “constraints” on the nature of the target for such specifications) that can be conformed to. There does not appear to be
In all cases, the general case is intended - “constraints” does not imply SHACL or any other specific constraint language that only applies to to schema - it may be any form of constraint - even for example that implementations has passed formal validation processes.

This broad interpretation means that any “vocabulary” is a “specification” that constrains the usage of terms to mean certain things, as well as the obvious things like the datatypes of values (so some subset of the constraints specified by a vocabulary can be expressed in RDFS, OWL, SHACL etc - others arise from the wording of definitions and any processes defined to evaluate conformance to these definitions.)





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.

R: your community may choose to consider “application profiles” to be exclusively profiles of your published specification(s) (vocabulary), but a broader community may, for example, see your vocabulary to be a profile of RDF. This is consistent with 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 doesnt 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.

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

R We will need to improve the explanation to avoid such confusion,

> 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.
R: the proposed model is consistent with all these cases, once it it understood the usage of the term “profile” in the DCMI processes is relaxed to meet the more general concept proposed, 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 negotation
process described in this spec, e.g., where the value
of the Accept-Profile header might be
http://purl.org/dc/terms/.

R: that is precisely what has been done, we will revisit explanations to make this clearer.

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

R: we have already dropped the notion of a ‘base specification’ (see https://github.com/w3c/dxwg/issues/641) 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.

R: the notion of profiles is more general than this, it is up to communities to determine the scope of what may be specified.

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

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

R: will comply

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

R: agreed

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

R: 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 whose domain is dct:Standard and whose range is rdfs:Class could allow us to be clearer about the nature of specifications.

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

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

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.