- From: Holger Knublauch <holger@topquadrant.com>
- Date: Tue, 24 Mar 2015 13:47:57 +1000
- To: Arthur Ryman <arthur.ryman@gmail.com>, "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
On 3/24/2015 5:11, 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. I think the term "high level vocabulary" is not precise enough. Even user-defined templates and 3rd party libraries created for specific domains will be high level vocabularies. What sets the built-in terms such as sh:minCount apart is that they are included in the SHACL namespace, forming what could be considered a "core". > > 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. I don't like the term "extensions" - it creates a wrong impression. Writing a constraint based on a SPARQL query is not an extension, it is a completely normal use of SHACL. And creating a template is simply using the macro facility, which is also a regular part of SHACL. I would rather call these "advanced" topics, or speak about "complex queries" and "macro facilities". Holger > > 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
Received on Tuesday, 24 March 2015 03:49:09 UTC