Re: On various syntax issues

On 20/05/2016 11:19, Holger Knublauch wrote:
> On 20/05/2016 10:58, Peter F. Patel-Schneider wrote:
>> On 05/19/2016 03:47 PM, Holger Knublauch wrote:
>>>
>>> On 20/05/2016 1:07, Peter F. Patel-Schneider wrote:
>>>> It seems to me that one of the goals of syntax simplification is to 
>>>> end up
>>>> with a simpler syntax.  One aspect of having a simpler syntax, to 
>>>> me, is
>>>> that constructs that intuitively make sense are permitted, 
>>>> particularly if
>>>> similar constructs are also permitted.
>>>>
>>>> 1/ Because existing property constraints can be conjoined, it 
>>>> should be
>>>> possible to conjoin existing shapes, like
>>>>
>>>> ex:s1 rdf:type sh:Shape ;
>>>>    sh:nodeKind sh:IRI ;
>>>>    sh:class ex:Citizen .
>>>>
>>>> ex:s2 rdf:type sh:Shape ;
>>>>    sh:property [ sh:predicate ex:child ;
>>>>             sh:class ex:Person ] .
>>>>
>>>> ex:s3 rdf:type sh:Shape ;
>>>>    sh:scopeClass ex:Person ;
>>>>    sh:filter [ sh:property [ sh:predicate sh:age ;
>>>>                   sh:minInclusive 18 ] ] ;
>>>>    sh:and ( ex:s1 ex:s2 ) .
>>>>                           So sh:and is needed unless there is 
>>>> another simple way to achieve this.
>>> This can be written using sh:shape (in case it gets approved):
>>>
>>> ex:s3 rdf:type sh:Shape ;
>>>   sh:scopeClass ex:Person ;
>>>   sh:filter [ sh:property [ sh:predicate sh:age ;
>>>                  sh:minInclusive 18 ] ] ;
>>>   sh:shape ex:s1 ;
>>>   sh:shape ex:s2 .
>>>
>>> So unless we want to create a sh:and as an alternative syntax 
>>> aligning with
>>> sh:or, I don't think we need sh:and.
>> This new feature probably means that sh:and is redundant. Whether it 
>> is a
>> good idea to have sh:or and sh:not without a matching sh:and is a 
>> separate matter.

On whether sh:and would still make sense, I believe the solution with 
sh:shape has several advantages:
- it doesn't require an extra (and ugly) rdf:List
- any constraint violations will automatically get "propagated up" into 
the surrounding shape, while sh:and would by default "swallow" them

This also lead me to think there is further potential here. We agree 
sh:Shape is an intersection of constraint/components, i.e. in order to 
fulfill the whole shape, all individual constraints need to be 
fulfilled. Assuming we have sh:Shape rdfs:subClassOf sh:Constraint, why 
not introduce a similar construct for unions of constraints:

     sh:Union rdfs:subClassOf sh:Constraint .

Then, sh:or would point at instances of sh:Union:

     ex:PersonShape
         sh:property [
             sh:predicate ex:address ;
             sh:or [     # a sh:Union (optional)
                     sh:datatype xsd:string ;
                     sh:class ex:Address ;
             ]
         ]

The difference between sh:Shape and sh:Union would be that all 
constraint components would be treated with "or" semantics instead of "and".

We could this way get rid of rdf:Lists and have a more regular syntax. 
Just a thought for now...

Holger

Received on Friday, 20 May 2016 03:32:09 UTC