- 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