Re: On various syntax issues

On 18/05/2016 23:30, Jim Amsden wrote:
> Could you redo the example using these changes so we can see how much 
> simplification is provided - both conceptual and textual realization?
>

The example from 1.3 would become a bit simpler, because sh:constraint 
would be moved up a level:

ex:PersonShape
	a sh:Shape ;
	sh:scopeClass ex:Person ;    # Applies to all persons
	sh:closed true ;
	sh:ignoredProperties ( rdf:type ) ;
	sh:property [
		sh:predicate ex:ssn ;
		sh:maxCount 1 ;
		sh:datatype xsd:string ;
		sh:pattern "^\\d{3}-\\d{2}-\\d{4}$" ;
	] ;
	sh:property [
		sh:predicate ex:child ;
		sh:class ex:Person ;
		sh:nodeKind sh:IRI ;
	] ;
	sh:inverseProperty [
		rdfs:comment "A person's parents are represented via ex:child used in the inverse direction." ;
		sh:predicate ex:child ;
		sh:name "parent" ;
		sh:maxCount 2 ;
	] .


But the main advantage would be merging two very similar concepts - node 
constraints were about a given focus node, shapes were about a given 
focus node too. Only difference was that only sh:Shapes can have scopes.

HTH
Holger


>
> Jim Amsden, Senior Technical Staff Member
> OSLC and Linked Lifecycle Data
> 919-525-6575
>
>
>
>
> From: Holger Knublauch <holger@topquadrant.com>
> To: "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
> Date: 05/18/2016 09:13 AM
> Subject: 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?
>
> Thanks,
> Holger
>
>
>
>
>