Re: Properties v classes in validation

Hi!

Just as a small proof of concept, following ConstraintTemplate (and 
helper function) is able to check whether X instances of type ex:person 
exist (tested with TopBraid 5.0).

So such constraints are in general expressible.. If we want to natively 
support those by respective ConstraintTemplates is another question 
though ;)

# instance data & shape
# ----------------------
   ex:Person rdf:type rdfs:Class .
   ex:Enrico rdf:type ex:Person . ex:Diego rdf:type ex:Person .
   ex:Alessandro rdf:type ex:Person . ex:Sergio rdf:type ex:Person .
   ex:John rdf:type ex:Person . ex:Maurizio rdf:type ex:Person .

  ex:MyShape
     a sh:Shape ;
     sh:scope [
         a sh:PropertyScope ;
		sh:predicate rdf:type ;
     ] ;
     sh:constraint [
         a ex:ClassMembershipCountTemplateConstraint ;
         ex:type ex:Person ;
         sh:minCount 7 ;
         sh:maxCount 7 ;
     ] .


# constraint template & helper function
# ---------------------------------------
  ex:ClassMembershipCountConstraintTemplate
	a sh:ConstraintTemplate ;
	rdfs:subClassOf sh:TemplateConstraint ;
	rdfs:label "Example Template" ;
	rdfs:comment "Enforces a constraint on the cardinality of the number of 
occurrences of instances of a given type using minCount and maxCount. By 
default, given graph may have 0 to unlimited number of instances of a 
given type" ;
	sh:argument [
		sh:predicate ex:type ;
		sh:valueClass rdfs:Resource ;
	] ;
	sh:argument [
		sh:predicate sh:minCount ;
		sh:defaultValue 0 ;
		sh:optional true ;
		sh:datatype xsd:integer ;
		rdfs:label "min count" ;
		rdfs:comment "The minimum number of instances of defined type 
required. Defaults to 0." ;
	] ;
	sh:argument [
		sh:predicate sh:maxCount ;
		sh:optional true ;
		sh:datatype xsd:integer ;
		rdfs:label "max count" ;
		rdfs:comment "The maximum number of instances of defined type 
required. Defaults to unlimited." ;
	] ;
	sh:message "Required value count [{?predicate}..{?object}] but found 
{?count}" ;
	sh:sparql """
		SELECT ?this (?type AS ?subject) ?count (?minCount AS ?predicate) 
(?maxCount AS ?object)
		WHERE {
			BIND (sh:instanceCount(?type) AS ?count) .
			FILTER ((?count < ?minCount) || (bound(?maxCount) && (?count > 
?maxCount))) .
		}
		""" ;
.

  sh:instanceCount
	a sh:Function ;
	rdfs:label "instance count" ;
	rdfs:comment "Gets the number of instances of a given type (?arg1). The 
result is the number of matches of (?s, ?a, ?arg1)." ;
	sh:argument [
		sh:predicate sh:arg1 ;
		sh:valueClass rdfs:Resource ;
		rdfs:comment "The subject resource." ;
	] ;
	sh:returnType xsd:integer ;
	sh:sparql """
		SELECT ((COUNT(?s)) AS ?result)
		WHERE {
			?s a ?arg1 .
		}
		""" ;
.

cheers,
simon

---
DDipl.-Ing. Simon Steyskal
Institute for Information Business, WU Vienna

www: http://www.steyskal.info/  twitter: @simonsteys

Am 2015-09-01 05:04, schrieb Karen Coyle:
> 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

Received on Tuesday, 1 September 2015 05:49:31 UTC