- From: Holger Knublauch <holger@topquadrant.com>
- Date: Tue, 1 Sep 2015 15:47:43 +1000
- To: public-data-shapes-wg@w3.org
On 9/1/2015 13:04, Karen Coyle wrote: > > > On 8/31/15 5:15 PM, Arnaud Le Hors wrote: >> I have to say that I'm not sure I completely understand either. Karen, >> are you saying that for every X rdf:type ex:CulturalObject there can be >> one or more X rdf:type ex:Person ? > > Yes, that's one case. > > Does that mean you really want to >> enforce that for every X rdf:type Person there must be one X rdf:type >> ex:CulturalObject ? > > Yes. And in that sense it's a simple question of cardinality > definitions, but it operates on the class membership rather than the > property presence (which seems to be what SHACL addresses). The above could be expressed as ex:Person a sh:ShapeClass ; sh:property [ sh:predicate rdf:type ; sh:hasValue ex:CulturalObject ; rdfs:comment "Every Person must also be a CulturalObject" ; ] ... > > So starting with something more specific, this is what was sent to me: > > <!--Each graph must have exactly one instance of rdf:type > edm:ProvidedCHO and one > instance of rdf:type ore:Aggregation (R-225)--> > > Which is essentially: > > each focus node must have exactly one instance of rdf:type A and > exactly one instance of rdf:type B. > > Then there will be cases with different cardinality patterns, but > defined as class instances, not properties. > > We are gathering some more examples, but I first wanted to make sure > that this is even relevant to SHACL before we do any work. Plus, I > wanted to start the question before the f2f, in case it is relevant. > If this is seen as out of scope or a quirk of ours, we'll do the > analysis to see if we can re-define our validation requirements in > terms of properties. At least in some cases I believe the answer to > that will be yes, but in other cases it may be difficult or require > some re-engineering of the vocabularies, like creating > super-properties where the properties that can be used are awkwardly > numerous. > > So I guess the underlying question of mine is: can validation > conditions operate on instances of classes, in addition to validation > that is defined in terms of properties? SHACL can certainly express all this, but maybe not with its Core Vocabulary. It's still SHACL though. Holger
Received on Tuesday, 1 September 2015 05:48:20 UTC