Re: On various syntax issues

These may all be good ideas, but what effect do they have?

It appears that the intent is that anywhere a node constraint could be a shape
is allowed, but there is no indication that this is indeed the case.



sh:and is still needed to allow shapes or constraints to be conjoined together.

peter


On 05/18/2016 06:11 AM, Holger Knublauch wrote:
> 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 16:14:25 UTC