- From: Antoine Isaac <aisaac@few.vu.nl>
- Date: Tue, 18 Jun 2019 22:05:19 +0200
- To: <public-dxwg-wg@w3.org>
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. Antoine 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] 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 >>> >> >> >
Received on Tuesday, 18 June 2019 20:05:45 UTC