- From: Holger Knublauch <holger@topquadrant.com>
- Date: Fri, 21 Aug 2015 15:29:45 +1000
- To: RDF Data Shapes Working Group <public-data-shapes-wg@w3.org>
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.
Received on Friday, 21 August 2015 05:30:21 UTC