Re: ISSUE-133: Wiki page with syntax examples

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?

Holger


>
> the reason is that when someone uses sh:or from a property constraint, 
> sh:or in interpreted as a node constraint and although  in many cases 
> this works well, (e.g. with datatypes, nodeKind, etc) all components 
> that do not support both contexts are problematic
> we also have sh:closed that with the current definition applies only 
> on Node Constraints and people will be actually able to use it in an 
> sh:or in a property constraint now
>
> Based on the above, I would prefer not to go with this change but 
> since I saw support during the last call I only raise my concerns and 
> will stay neutral on this.
>
>
>
>
> On Mon, Jul 18, 2016 at 4:21 AM, Holger Knublauch 
> <holger@topquadrant.com <mailto:holger@topquadrant.com>> wrote:
>
>     On 17/07/2016 5:17, Karen Coyle wrote:
>
>         Holger, thanks for this. My question now is, would we still need:
>
>         sh:PropertyConstraint
>         sh:NodeConstraint
>         sh:property
>         ?
>
>
>     sh:NodeConstraint would disappear - it would be sh:Shape. The
>     class hierarchy would look like
>
>     sh:Constraint
>         sh:PropertyConstraint
>         sh:Shape
>
>     and sh:property would be the parameter of a constraint component
>     that takes sh:PropertyConstraints as its values. A sh:Shape would
>     be a constraint that is satisfied if all its constraint components
>     are satisfied (see sh:hasShape).
>
>
>         If (as it appears) sh:property is always followed by a node
>         with sh:predicate, then those are redundant, and only
>         sh:predicate is necessary.
>
>
>     I cannot follow this train of thought. Along the same lines, all
>     classes would be redundant as soon as they have a property that
>     makes them identifiable. But sh:PropertyConstraint is very
>     distinct from sh:NodeConstraint or sh:Shape. Among others it
>     serves as a container to group together properties that only make
>     sense there, e.g. sh:predicate, sh:path, sh:name, sh:description,
>     sh:order, sh:group - none of which apply to shapes in general. I
>     believe it will also be an intuitive concept for people coming
>     from OWL or object-oriented backgrounds - basically a shape
>     declares properties, and these properties have their own
>     characteristics. In OWL this is similar to owl:Restrictions. The
>     metamodel is IMHO cleaner this way.
>
>     Holger
>
>
>
>
>         kc
>
>         On 7/14/16 3:43 PM, Holger Knublauch wrote:
>
>             I have started a wiki page to collect examples of how the
>             proposed
>             syntax change to merge sh:Shape and sh:NodeConstraint
>             would look like:
>
>             https://www.w3.org/2014/data-shapes/wiki/ISSUE-133
>
>             Please feel free to edit this page and/or discuss on the
>             mailing list.
>
>             Cheers,
>             Holger
>
>
>
>
>
>
>
>
>
> -- 
> 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
>