Re: Early feedback on SHACL Spec appreciated

On 2/28/2015 18:12, Jose Emilio Labra Gayo wrote:
> I agree with some of Peter's remarks.
>
> From my point of view there are some missing sections on the spec and 
> some sections that should probably moved out of the spec and be part 
> of some different deliverable.
>
> - I miss a section describing the core vocabulary used to define the 
> shapes. That section should be one of the first sections. Now, there 
> is section 6 but it contains a mixture of things.

We would first need to agree what "core vocabulary" means. It could be 
either
a) the template mechanism
b) the sh:property vocabulary (this could be a named sh:Profile)

Also, do we even need a notion of "core" in the (full) spec? My 
understanding is that this is largely a formal document for 
implementers, while other possible deliverables (such as Primer and a 
SHACL Compact) could focus on how to partition the overall language into 
easier digestible parts. Certainly, a Primer could start off with the 
most frequently needed terms of the vocabulary and have the SPARQL bits 
at the end, but my goal with the Spec was to have a logical progression 
of chapters.

>
> - That core vocabulary for shape definitions should not need any 
> reference to SPARQL. I suggest to remove the examples using SPARQL in 
> section 4 and to use examples based on that core vocabulary.

The only "executable" language currently mentioned in the Spec is 
SPARQL, so any example of Native Constraints needs to use SPARQL (unless 
we want to speculate on something for JavaScript, which I believe would 
be premature). For the two template-based subsections 4.2 and 4.4 I also 
wanted to include SPARQL so that the examples are self-contained. For 
global constraints SHACL currently does not define any templates that we 
could have used instead. I have however added the following sentence to 
set expectations straight:

https://github.com/w3c/data-shapes/commit/35013f2302456c28904ff4e466a0cc8e1bb6b1a0

>
> - The definitions in section 6.2.1, 6.2.2, 6.2.3, etc. are in natural 
> language and in SPARQL. I propose to use a semantic formalism which 
> does not depend on SPARQL and to have SPARQL mappings in a different 
> section (probably section 15).

I disagree, as mentioned before. SPARQL is precise enough, directly 
executable, better aligned with the RDF stack, and likely better 
comprehensible to most people familiar with RDF technology.

>
> - I would add a subsection about how to map from the core vocabulary 
> terms defined in RDf to the abstract syntax used to define the semantics.

I don't think any Abstract Syntax is needed or helpful. SHACL is already 
self-contained using SPARQL.

>
> - Sections 9 (templates) and 10 (functions) should probably be removed 
> until we have more consensus on what extensibility mechanism we are 
> going to use. In the requirements we employed the name "Macros" 
> instead of templates.

Macros are been an officially approved requirement, and most people 
using SPIN agree that Functions are extremely useful. It would be a huge 
mistake to throw them away. Both sections are currently necessary to 
keep the document self-contained.

>
> - I would remove sections 11 (Graph management), 12 (Contexts) and 13 
> (Profiles) because some of them are almost empty and others contain 
> features on which there is no consensus yet.

Section 11 is clearly marked as unfinished, but there are indications in 
section 15 that this topic will need to be revisited, so I believe we 
should leave this placeholder in for now. The context requirement of 
section 12 is not yet approved and may be removed, but there are also no 
votes against that requirement yet (but 2 in favor). I would be 
surprised if it gets rejected because it addresses the "different shapes 
at different times" user stories that several people found important. 
Section 13 (Profiles) covers an approved requirement.

Thanks
Holger

Received on Sunday, 1 March 2015 06:48:14 UTC