Re: ISSUE-95: Template Simplifications

Arthur,

On 10/29/2015 22:23, Arthur Ryman wrote:
> Holger,
>
> 1. Yes, I agree that we need a concrete alternative for the SHACL data
> model. We should start with a minimal Turtle vocabulary file which
> contains all the terms we use in the spec and only add features agreed
> to by the WG.

I have made another pass through "my" Turtle file, currently at

https://github.com/TopQuadrant/shacl/blob/master/src/main/resources/etc/shacl.ttl

I have cleaned up a few things, deleted unapproved features and added 
TODO comments with links to open ISSUEs for features at risk. I believe 
this incremental approach is more helpful than reinventing the wheel 
with a blank sheet of paper.

Here is an outline of what it is currently in the file:

1) Shape Classes (sh:Shape, sh:ShapeClass)
2) Shapes that extend existing RDFS/OWL to declare sh:entailment, 
sh:shapesGraph
3) Node Kind vocabulary (sh:BlankNode, sh:IRI etc)
4) Results vocabulary (sh:ValidationResult etc)
5) Macros meta-model (sh:Function, sh:Template etc)
6) The sh:sparql property
7) Scope vocabulary (sh:PropertyScope etc)
8) Constraint vocabulary (sh:Constraint, templates etc)

All this is quite generic and would need to be part of any proper SHACL 
model.

9) The specific constraint types (sh:PropertyConstraint, 
sh:NodeConstraint etc)
10) The specific functions used by the constraint types

These two parts are about 60% of the document. This will become 
significantly shorter if I am allowed to proceed with my proposal to 
ISSUE-95. Yet, they do define all the details about the allowed 
constraint properties that is needed in one way or another, so we cannot 
completely drop them.

A contentious issue may be that my current file includes the SPARQL 
queries. I may be able to live with taking those out of the published 
vocabulary. Yet, I would then still need stable URIs to attach the 
SPARQL queries that I want to use to, and this is what the abstract 
template classes and functions provide.

11) Declarations of defaultValueTypes
12) Definition of some RDFS system classes so that constraint checking 
of shapes graphs can pass
13) Declarations of rdf:Properties for the built-ins, with a label, for 
legacy applications

Some of that content could be taken out of the file too.

>
> 2. I believe the WG should give first precedence to making SHACL easy
> to understand for people who are going to write SHACL documents. We
> should not sacrifice that for technical advantages related to
> validating SHACL documents.

Since we can generate RDFS, OWL or HTML versions from a SHACL model, I 
don't see any of this blocking the other. However, I do believe that we 
shouldn't let the current status of SHACL cloud our judgement about how 
the language should be layered in general. In particular, statements 
such as "nobody understands SHACL yet so we should not rely on it yet" 
would be short-sighted. In a year from now, there will be lots of 
articles, tutorials, tools and probably even books written about SHACL. 
In two years from now, people would wonder why the hell did the WG not 
use SHACL to describe the SHACL vocabulary itself. Only because some 
people didn't grasp the details of the metaclasses at this stage, yet, 
and because the spec that is supposed to explain these things is 
unfinished and poorly written?

How many people here in the WG have actually used SHACL yet? We are all 
beginners right now, but that will change quickly.

Holger

>
> 3. My second line of reasoning relates to the use of meta-classes. I
> believe it is very easy to get lost when mentally traversing
> meta-levels. I believe data models are easier to understand when
> meta-classes are avoided. I believe the OWL approach of classifying
> all terms as classes, properties, or individuals results in data
> models that are easier to understand. Yes, avoiding meta-classes is a
> matter of personal taste but it makes data models clearer.
>
> -- Arthur
>

Received on Friday, 30 October 2015 06:30:21 UTC