Re: Properties v classes in validation

> Minor tweak here: to avoid having to misuse ?predicate and ?object you
> can simply return ?minCount and ?maxCount as SELECT variables:

ah sure, forgot to refactor the final template ;)

> Maybe we should have a general policy to always make all template
> argument values visible in the sh:messages?

+1 from my side

cheers,
simon

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

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

Am 2015-09-01 07:55, schrieb Holger Knublauch:
> On 9/1/2015 15:49, Simon Steyskal wrote:
>> 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)
> 
> Minor tweak here: to avoid having to misuse ?predicate and ?object you
> can simply return ?minCount and ?maxCount as SELECT variables:
> 
> SELECT ?this (?type AS ?subject) (rdf:type AS ?predicate) ?minCount
> ?maxCount ?count
> 
> and then use them as
> 
>     sh:message "Required value count [{?minCount}..{?maxCount}] but
> found {?count}" ;
> 
> Maybe we should have a general policy to always make all template
> argument values visible in the sh:messages?
> 
> Cheers,
> Holger
> 
> 
>>         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:59:11 UTC