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

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

Best,
Dimitris


On Fri, Aug 21, 2015 at 8:29 AM, Holger Knublauch <holger@topquadrant.com>
wrote:

> To me the main question is not whether these features are useful, but how
> they should be published. On the one hand side we could continue to add
> them under the label of the "Core" Vocabulary. Yet, I think at some stage
> we need to acknowledge that we are possibly bloating what the Core was
> originally supposed to mean. Everything in Core is expected to be supported
> by *all* implementations of SHACL, including client-side JavaScript
> libraries. The main spec would become larger and larger, even though no
> other features of the SHACL language depend on them. Furthermore, the more
> features we are adding, the larger will the gap between the Compact Syntax
> and the RDF-based syntaxes become.
>
> Maybe these use cases suggest we spawn off another library which could
> still be published under the umbrella of the WG but as a separate
> deliverable and possibly with another namespace. This library could even be
> set up as a living standard that is continuously curated similar to how
> schema.org is maintained, even after the WG expires.
>
> Holger
>
>
>
> On 8/21/2015 15:17, Simon Steyskal wrote:
>
>> Hi!
>>
>> At least we have also 2 use cases motivating this [27,32]. Where [32]
>> specifically states that:
>>
>> "If these validations can be expressed in a higher level language which
>> makes it simpler for clients to implement them constraint systems will be
>> useful in more places. "
>>
>> cheers,
>> simon
>>
>> [27]
>> http://w3c.github.io/data-shapes/data-shapes-ucr/#uc27-relationships-between-values-of-multiple-properties
>> [32]
>> http://w3c.github.io/data-shapes/data-shapes-ucr/#uc32-non-sparql-based-solution-to-express-constraints-between-different-properties
>>
>> ---
>> DDipl.-Ing. Simon Steyskal
>> Institute for Information Business, WU Vienna
>>
>> www: http://www.steyskal.info/  twitter: @simonsteys
>>
>> Am 2015-08-19 02:03, schrieb RDF Data Shapes Working Group Issue Tracker:
>>
>>> shapes-ISSUE-81 (Property pair constraints): Shall SHACL Core include
>>> support for disjoint properties and other property pair constraints?
>>> [SHACL Spec]
>>>
>>> http://www.w3.org/2014/data-shapes/track/issues/81
>>>
>>> Raised by: Holger Knublauch
>>> On product: SHACL Spec
>>>
>>> SKOS has several pairs of properties that must be disjoint. E.g.
>>> skos:prefLabel and skos:altLabel must not have the same values. This
>>> seems to be a recurring pattern, also supported by OWL. We may want to
>>> add something like
>>>
>>> sh:AbstractPropertyPairConstraint
>>>     sh:argument sh:predicate1 ;
>>>     sh:argument sh:predicate2 .
>>>
>>> sh:DisjointPropertyPairConstraint
>>>     rdfs:subClassOf sh:AbstractPropertyPairConstraint .
>>>
>>> Another common pattern would be
>>>
>>> sh:OrderedPropertyPairConstraint
>>>     rdfs:subClassOf sh:AbstractPropertyPairConstraint .
>>>
>>> where all values of ?predicate1 must be < ?predicate2.
>>>
>>
>
>


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