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

Good point, Karen, and I don't think I will have the time to dig up whether it was proposed. I'll just observe that everyone including the people behind the IETF definition have been involved in the discussion, I can't believe that they would have kept silent for all these months, if they thought that our direction would be wrong for what would update the IETF.

As a matter of fact this clearer definition is very much syntax oriented (including "structural constraints"), at the risk of colliding with the JSON-LD profiles that we managed to untangle from our own profiles at the Lyon F2F. I'm quite sure we would want to change it now.


On 18/06/2019 21:56, Karen Coyle wrote:
> 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.
> kc
> [1]
> [2]
> 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
>>> CONNEG and DCAT.
>>> Tom
>>> [1]
>>> [2]
>>> [3]

Received on Tuesday, 18 June 2019 20:05:45 UTC