- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Tue, 18 Jun 2019 12:56:46 -0700
- To: public-dxwg-wg@w3.org
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] https://www.w3.org/2017/dxwg/wiki/ProfileContext [2] http://profilenegotiation.github.io/I-D-Accept--Schema/I-D-accept-schema 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] > https://www.w3.org/2017/dxwg/wiki/ProfileContext#Definitions_of_Profile.2C_Application_Profile.2C_Metadata_Application_Profile > > [2] https://w3c.github.io/dxwg/dcat/#conformance > [3] https://w3c.github.io/dxwg/conneg-by-ap/ > 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 >> https://eur-lex.europa.eu/eli/reg/2014/1312/oj) 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] >> https://profilenegotiation.github.io/I-D-Accept--Schema/I-D-accept-schema >> [2] https://w3c.github.io/dxwg/dcat/#conformance >> [3] https://w3c.github.io/dxwg/dcat/#quality-conformance-statement >> > > -- Karen Coyle kcoyle@kcoyle.net http://kcoyle.net skype: kcoylenet
Received on Tuesday, 18 June 2019 19:57:12 UTC