- From: Holger Knublauch <holger@topquadrant.com>
- Date: Wed, 18 May 2016 23:11:48 +1000
- To: "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
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? Thanks, Holger
Received on Wednesday, 18 May 2016 13:12:26 UTC