Re: Do we really need a notion of profile "conformance"?

Antoine, I don't remember discussion of the IETF definition, and it
isn't included in our roundup of definitions [1]. If my memory is
correct, at that time we were looking at an even earlier version of the
IETF document which mainly referenced Dublin Core profiles, but that
also referenced MARCXML as a "profile," and that is no longer the case.
Here's the latest version (AFAIK) [2], and the definition there is clearer.


On 6/18/19 12:35 PM, Antoine Isaac wrote:
> Hi Tom, all,
> I believe that the group has already expressed its discomfort with the
> IETF definition, as it was considered when we had our (very long)
> discussion that has lead to the current definition DXWG [1] and was not
> kept. As much as I'm ok adapting this DXWG definition (and I may suggest
> it in a short while) I would rather want to avoid reviving the entire
> discussion. In particular I like very much the notion of 'specification'
> rather than 'document'.
> 'document' points to a rather concrete instance of a profile, while
> 'specification' is more conceptual, and allows to to group things
> together. For example, 'specification' allows me to consider the
> Europeana Data Model as a specification that can be detailed in an XML
> Schema, an RDFS/OWL document, or a SHACL represention. If we jump
> straight to the definition, then all the 'instanciations' of the
> Europeana Data Model would live in splendid isolation. There are many
> more downsides to focusing on 'documents' but this one seems a major
> showstopper to me.
> DCAT mentions 'specification' too [2]. In fact I believe that if DCAT
> doesn't cite the DXWG definition but it's more close to it than the one
> of IETF. And I believe it's not far at all. But this requires a unifying
> approach to profiles, which I am trying to articulate (and have started
> to write) but which I'll probably fail to send before the call.
> By the way DCAT does rely on a notion of conformance: "A data catalog
> that conforms to the profile also conforms to DCAT." And this is where
> it becomes closer to the DXWG, as it hints that profiles are chiefly
> based on "Additional constraints in a profile".
> And of course the Profile Negotiation document has conformance in plenty
> places [3]. So we'll probably need to articulate something on this. I'll
> try to hook something in what I'm trying to write...
> Best
> Antoine
> [1]
> [2]
> [3]
> On 12/06/2019 09:46, Thomas Baker wrote:
>> An XML, SHACL, or ShEx processor can test whether some
>> data conforms to an XML schema or to a SHACL or ShEx
>> document.
>> However, I see no requirement simply to assert (for
>> example, in metadata) that an XML schema, SHACL or ShEx
>> document -- not to mention the PDF of an application
>> profile -- "conforms to" some base specification.  The
>> XML schema, SHACL or ShEx document, or even the PDF of an
>> application profile usually cite their own sources --
>> e.g., the namespaces used -- explicitly enough.
>> In the absence of an algorithmic conformance test, simply
>> asserting conformance only really states intent -- for
>> example, that something conforms to the text of the
>> two-page EU Regulation at
>> as per
>> Section 12.2.1 of [3].  The result of an algorithmic
>> conformance test can be recorded in metadata, though
>> since most specifications are mutable, at least in
>> principle, such an assertion can only reliably be seen as
>> the result of a given test against a version of a
>> document at a given time.
>> For CONNEG, the generic definition of "profile" provided
>> by Svensson and Verborgh -- "a document that expresses
>> the structural and/or semantic constraints of other
>> documents" [1] -- seems good enough if the typical use
>> case will be to point to an application profile such as
>> DCAT. The IETF draft reinforces this point by citing the
>> definition of "application profile" from Heery and Patel
>> 2000.
>> To conclude:
>> * For CONNEG, I see no need to define "profile" any more
>>    precisely than Svensson and Verborgh [1].
>> * As the section on DCAT conformance says very clearly,
>>    DCAT APs are "application profiles" in the Dublin Core
>>    sense: "The notion of profile used in this document
>>    denotes metadata specifications that the Dublin Core
>>    community would call application profiles" [2].
>>    I see no compelling need to harmonize the definition of
>> "profile" between CONNEG and DCAT, and for the purposes
>> of CONNEG and DCAT, I see no need for a more elaborate or
>> generalized theory of profiles.  A WG Note on Guidance
>> summarizing existing practice would be useful though I do
>> not see it as being on the critical path to finalizing
>> Tom
>> [1]
>> [2]
>> [3]

Karen Coyle
skype: kcoylenet

Received on Tuesday, 18 June 2019 19:57:12 UTC