Re: Properties v classes in validation

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).

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?

kc



-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600

Received on Tuesday, 1 September 2015 03:05:20 UTC