Re: ISSUE-133: Wiki page with syntax examples

On Tue, Jul 19, 2016 at 3:35 AM, Holger Knublauch <holger@topquadrant.com>
wrote:

> On 18/07/2016 18:34, Dimitris Kontokostas wrote:
>
> In general I am in favor of syntax simplifications but I have some
> concerns on this one, mainly from the use perspective
> What might not be straightforward for the users with this proposal is that
> when they use sh:or in property constraints they will not be able to use
> components such as
> sh:hasValue, sh:equals, sh:disjoint, sh:min/maxCount, sh:uniqLang and in
> general all components with NC not checked in the table of section 4
> e.g. when someone defines that a property ex:p  must :
>  - have sh:hasValue X or sh:hasValue Z
>  - be sh:equals to ex:p1 or ex:p2
> they will always get back failures or violations (depending on ISSUE-139)
>
>
> Let's try to get to the bottom of this.
>
> In the current syntax the above would be expressed as
>
> ex:MyShape
>     a sh:Shape ;
>     sh:constraint [
>         sh:or (
>             [ sh:property [
>                 sh:predicate ex:p ;
>                 sh:hasValue X ;
>             ] ]
>             [ sh:property [
>                 sh:predicate ex:p ;
>                 sh:hasValue Z ;
>             ] ]
>         ) ;
>     ] ;
>     sh:constraint [
>         sh:or (
>             [ sh:property [
>                 sh:predicte ex:p ;
>                 sh:equals ex:p1 ;
>             ] ]
>             [ sh:property [
>                 sh:predicte ex:p ;
>                 sh:equals ex:p2 ;
>             ] ]
>         ) ;
>     ] .
>
> i.e. the sh:or must be placed on the outside. With the new syntax that
> situation does not change, only that the sh:constraint triples would be
> collapsed:
>
> ex:MyShape
>     a sh:Shape ;
>     sh:or (
>         [ sh:property [
>             sh:predicate ex:p ;
>             sh:hasValue X ;
>         ] ]
>         [ sh:property [
>             sh:predicate ex:p ;
>             sh:hasValue Z ;
>         ] ]
>     ) ;
>     sh:or (
>         [ sh:property [
>             sh:predicte ex:p ;
>             sh:equals ex:p1 ;
>         ] ]
>         [ sh:property [
>             sh:predicte ex:p ;
>             sh:equals ex:p2 ;
>         ] ]
>     ) .
>
> Using sh:hasValue and the other operators inside of an sh:or at a property
> constraint would not have the desired effect, because sh:or iterates over
> all values of the property and then applies the constraint independently.
> And the members of the sh:or list are sh:Shapes, not sh:NodeConstraints.
>
> But this topic seems orthogonal to the question of merging
> sh:NodeConstraint with sh:Shape to me. Could you clarify where you see the
> connection?
>

I agree that if you know how you want to do something the new syntax will
make it easier for you.
but if we merge sh:Shapes with with sh:NodeConstraints, we will make it
very natural for people to express shapes in a wrong way, i.e. write it like

ex:MyShape
    a sh:Shape ;
    sh:property [
        sh:predicate ex:p ;
        sh:or (
            [sh:hasValue X ;]
            [sh:hasValue Y ;]
       ) ;
        sh:or (
            [sh:equals ex:p1 ;]
            [sh:equals ex:p2 ;]
       ) ;
] ;

and it will be harder for us to explain why the former is wrong while the
following is correct

ex:MyShape
    a sh:Shape ;
    sh:property [
        sh:predicate ex:p ;
        sh:or (
            [sh:datatype ex:d1 ;]
            [sh:datatype ex:d2 ;]
       ) ;
        sh:or (
            [sh:class ex:c1 ;]
            [sh:class ex:c2 ;]
       ) ;
] ;

imho If we keep the sh:constraint (or sh:node) explicit in the definition
it will be easier to explain the difference



-- 
Dimitris Kontokostas
Department of Computer Science, University of Leipzig & DBpedia Association
Projects: http://dbpedia.org, http://rdfunit.aksw.org,
http://aligned-project.eu
Homepage: http://aksw.org/DimitrisKontokostas
Research Group: AKSW/KILT http://aksw.org/Groups/KILT