On various syntax issues

On a long evening walk I thought a bit about all the various open 
decisions regarding our syntax, such as mixed ranges (sh:type), node 
constraints (sh:constraint) and syntactic sugar for and/or.

Anticipating that we will create a new property sh:sparqlConstraint, and 
generalize sh:valueShape to sh:shape, here is what we could do:

1) Delete sh:NodeConstraint, make sh:Shape rdfs:subClassOf sh:Constraint.

2) Delete sh:constraint, because the constraint parameters will be 
directly attached to a sh:Shape, including sh:closed.

3) Delete sh:and - a sh:Shape is already an intersection of constraints, 
plus we have sh:shape.

4) Delete sh:classIn and sh:datatypeIn - use sh:or ( [ sh:datatype 
xsd:string ] [ sh:class schema:Address ] ) so that there are not too 
many ways to state the same things.

All this should simplify the language quite a bit (at least from a 
technical view point), and the path from our current design to this 
looks quite straight-forward. I haven't thought about what this means 
for the terminology as a "shape" is now simply a specific kind of 
"constraint", a conjunction in fact.

Any feedback?


Received on Wednesday, 18 May 2016 13:12:26 UTC