Re: shapes-ISSUE-129 (existential constraints): Existential constraints should be consistent [SHACL - Core]

Many constraint types indeed apply to "all values" only:
- sh:class, sh:classIn, sh:datatype, sh:datatypeIn, sh:directType
- sh:max/min/In/Exclusive, sh:maxLength, sh:minLength
- sh:nodeKind
- sh:in
- sh:valueShape

These are handled by NodeValidationFunctions in the current draft.

Other constraint types are more heterogeneous, and calling them 
"existential" is IMHO an over-simplification:
- sh:and, sh:or, sh:not
- sh:closed
- sh:equals, sh:notEquals, sh:lessThan, sh:lessThanOrEquals
- sh:minCount, sh:maxCount
- sh:qualifiedXY
- sh:uniqueLang
- sh:hasValue

Just looking at sh:equals for example, the query is something like


         SELECT $this ($this AS ?subject) $predicate ?object
         WHERE {
             {
                 $this $predicate ?object .
                 FILTER NOT EXISTS {
                     $this $equals ?object .
                 }
             }
             UNION
             {
                 $this $equals ?object .
                 FILTER NOT EXISTS {
                     $this $predicate ?object .
                 }
             }
         }

i.e. the system will produce violations if the "other" property has a 
value that isn't present but also vice-versa. It may even fire a 
violation if there is no value at all, but the other property has values.

Coming up with an artificial limitation is likely going to hurt 
extensions that we cannot anticipate yet, so I believe we must treat 
them as "arbitrary" constraint types that may do anything they like.

I also have seen many use cases of sh:hasValue, esp in filterShapes, so 
i would be against dropping that.

Holger



On 7/03/2016 20:49, RDF Data Shapes Working Group Issue Tracker wrote:
> shapes-ISSUE-129 (existential constraints): Existential constraints should be consistent [SHACL - Core]
>
> http://www.w3.org/2014/data-shapes/track/issues/129
>
> Raised by: Dimitris Kontokostas
> On product: SHACL - Core
>
> The current core spec defines three existential constraints: sh:minCount, sh:maxCount and sh:hasValue.
> sh:hasValue requires for a value to exist and match the one supplied in the shape definition.
>
> This is not consistent with sh:in which is a variation of sh:hasValue and probably not easy for users to understand the different of sh:hasValue and other constraints e.g. sh:minLength, sh:class, etc
>
> I suggest we restrict the core existential constraints to sh:minCount and sh:maxCount only. The rest of the constraints will apply only when there is a value.
>
>
>

Received on Monday, 7 March 2016 22:48:59 UTC