Re: shapes-ISSUE-81 (Property pair constraints): Shall SHACL Core include support for disjoint properties and other property pair constraints? [SHACL Spec]

On 8/21/2015 17:58, Dimitris Kontokostas wrote:
> I think specifying direct cases will indeed bloat the core library. I 
> would prefer to make this type of pair checking a little more flexible
>
> sh:AbstractPropertyPairConstraint
>     sh:argument sh:predicate1 ;
>     sh:argument sh:predicate2 ;
>     sh:argument sh:operator .
>
> where operator would possibly be
>  - a string like < > = != <= >=
>    * we could define special uris for the above i.e. sh:equals, ..
>  - a simple expression compatible to SPARQL Filter but limited perhaps 
> to specific operators or xsd functions
>
> if we allow the latter it could be useful for simple sh:property 
> constraints as well

By coincidence I had today added sh:hasMinExclusive etc

https://github.com/w3c/data-shapes/blob/ISSUE-79/shacl/shacl.shacl.ttl

as functions returning a boolean that may theoretically be useful here. 
Reusing this may lower the implementation costs, and people can more 
easily add execution instructions in non-SPARQL environments to those 
functions.

We could indeed do something similar to ISSUE-79 and define a custom 
code injection mechanism for property pairs, which of course has its 
specification and implementation costs too.

However, before we go there, could we enumerate how many variations are 
really needed? I guess we only need one direction, so we could drop > 
and >=, which would leave us with

sh:ExclusiveOrderedPropertyPairConstraint (?predicate1 < ?predicate2)
sh:InclusiveOrderedPropertyPairConstraint (?predicate1 <= ?predicate2)
sh:DisjointPropertyPairConstraint (?predicate1 != ?predicate2)
sh:EqualPropertyPairConstraint (?predicate1 = ?predicate2)

I am not sure how frequent the latter really is, so maybe we are just 
talking about 3 and a half distinct use cases so far? And for the common 
case of disjointness, I would personally prefer a less verbose syntax 
without the third argument. But I am very open to discussing this 
assuming there are more use cases that fall into this pattern?

(I don't see how simple string expressions could work given that we try 
to be independent of SPARQL - wouldn't this soon become an object 
language equivalent to SPARQL only with yet another syntax, leading to 
an even larger spec? Finally, allowing *any* expression will make the 
"core" language very unpredictable).

Cheers,
Holger