- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Tue, 24 Mar 2015 07:21:22 -0700
- To: public-data-shapes-wg@w3.org
I strongly support the suggestion by ARthur that we address at least two different audiences. One is the group of people who will will write and apply SHACL constraints to their (or someone else's) data. The other is the much smaller group of people who will develop SHACL validation engines. You can make an analogy with HTML (and all its trappings) - there are those who use the HTML language to mark up their documents, and there are those who write HTML interpreters within web browsers. The first group is vastly more numerous than the last. The first group will be the primary audience for any SHACL tutorials that are developed, but should also be taken into account in the general specification. Therefore, a section that describes the SHACL language as used by the first group needs to be part of the output of this group. The division that Arthur has suggested below makes sense to me, although I personally have no opinion on the exact break between parts 2 and 3. I think that sections 1-6 are edging in the direction of Arthur's Part 1, but more change needs to be made. Both Arthur and I proposed that the Constraints Validation Vocabulary section needs to be moved after the two sections that follow to make the document more readable from the "Group 1" point of view. That suggestion was not accepted. I have made other suggestions to wording, some of which have been accepted into the document and some that have not. I could suggest more changes, but am not sure that we have a viable process relating to decision-making, so I'm going to hold off. kc On 3/23/15 12:11 PM, Arthur Ryman wrote: > I suggest the following using the Part 1/2/3 split: > > Part 1: SHACL High Level Vocabulary > -- This defines the commonly occurring constraints. > > Part 2: SHACL Extensions Vocabulary > -- This defines the extension mechanism and at least the SPARQL > language binding. May also contain the JavaScript language binding if > there is enough interest from the WG members and public. > > Part 3: SHACL Semantics > -- This defines the processor semantics in enough detail for > implementers of SHACL engines. > > -- Arthur > > > On Fri, Mar 20, 2015 at 6:06 AM, Richard Cyganiak <richard@cyganiak.de> wrote: >> Hi Jose, >> >>> On 20 Mar 2015, at 06:21, Jose Emilio Labra Gayo <jelabra@gmail.com> wrote: >>> >>> What I like about Lite is that it signals that this is just part of a larger "full" language. >> >> +1 >> >>> My preference is to postpone the identification of the different profiles until we know what is the main "SHACL language". For me, the SHACL language should contain the most useful constructs and some extensibility mechanism. I would not oppose to have also some kind of macro-facility also. >>> >>> Once there is a full-language defined, it is possible to identify different profiles and assign names to them. >> >> To me this sounds very reasonable and a good way forward. >> >> The problem with that approach is that other members of the WG have already made it clear that they: >> >> - will object to including an extension mechanism in “SHACL Lite” (the high-level language) >> - will object to defining “SHACL Lite” and “SHACL Full” in the same document >> - will object to a normative reference from the “SHACL Lite” document to the “SHACL Full” document >> >> This rules out the notion of having one big language with several named subsets/profiles for specific use cases. I can’t see how that could possibly be achieved if the “profiles” don’t normatively reference the full language. >> >> Best, >> Richard > > -- Karen Coyle kcoyle@kcoyle.net http://kcoyle.net m: 1-510-435-8234 skype: kcoylenet/+1-510-984-3600
Received on Tuesday, 24 March 2015 14:21:57 UTC