Re: shapes-ISSUE-168 (instance count): How to constrain number of instances of a class in a graph [SHACL - Core]

I was balancing brevity with precision in my proposal. The meaning of 
sh:minInstanceCount would be a constraint to limit the minimum number of 
(SHACL) instances of a given (SHACL) class. I could write down the 
SPARQL query, but whether that helps depends on whether the reader is 
familiar with SPARQL:

SELECT $this
WHERE {
     ?instance rdf:type/rdfs:subClassOf* $this .
} HAVING (COUNT(?instance) < $minInstanceCount)

And as an attempt to explain scoping from another angle: The variable 
$this above is substituted with the in-scope nodes. So if you have

ex:CountShape
     a sh:Shape ;
     sh:scopeNode schema:FlightReservation ;
     sh:constraint [
         sh:minInstanceCount 1 ;
     ] .

then $this is replaced with schema:FlightReservation, so the query 
basically counts

     ?instance rdf:type/rdfs:subClassOf* schema:FlightReservation .

(the rdfs:subClass* walks up into all subclasses of the given class).

Anyway, since you indicated that you would want a feature to count 
direct instances only (no subclassing) then the whole proposal is 
probably unnecessary and we don't need to do anything. Counting direct 
instances is already possible with a constraint on rdf:type triples.

HTH
Holger



On 23/06/2016 6:56, Karen Coyle wrote:
> I would really like to hear from folks who are not part of TopBraid, 
> because it appears that there is a kind of "secret language of twins" 
> where things communicate to Holger and Irene even though they are 
> opaque to others. No where in ISSUE 168 is what Irene says below 
> explained. In fact, the issue seems to have some magic  involved with 
> min and maxInstanceCount, which are not defined anywhere in the issue. 
> I really don't care if it makes sense to Holger and Irene if it isn't 
> communicated clearly in the spec. The meaning of these new elements 
> are not defined in the proposal, so the proposal needs to be clarified 
> before it can be considered. What are min/maxInstanceCount, what is 
> the formality that describes them, and exactly where throughout SHACL 
> can they be used?
>
> kc
>
>
> On 6/22/16 8:51 AM, Irene Polikoff wrote:
>>
>> The definition of a class is that it is a resource of type 
>> (transitively)
>> rdfs:Class. There can be classes that have zero instances. This doesn’t
>> change the fact that they are classes. I could also imagine a constraint
>> that would dictate that a certain class should have no instances in the
>> graph. This means that if one wanted to check if something was a class,
>> they would look for its own type statement, not if it has instances.
>>
>> However, scopes don’t really make such checks. They only selects nodes
>> that are to be evaluated against constrains. In this case, the 
>> constraint
>> will check if ex:A is the object of rdf:type triple.
>>
>> If the constraint sets minInstanceCount to 1 or higher and ex:A is 
>> not an
>> object of rdf:type triple, there will be a violation. If constraint sets
>> minInstanceCount to exactly 0 or 0 or more and there are no rdf:type
>> triples ex:A is an object to, no violation is raised. I believe this is
>> what expected.
>>
>>
>> Irene
>>
>>
>>
>>
>>
>> On 6/22/16, 10:10 AM, "Karen Coyle" <kcoyle@kcoyle.net> wrote:
>>
>>> Thank you, Holger, that answers my question. But it also confirms that
>>> this solution is unrelated (aka "orthogonal") to the request for a way
>>> "How to constrain number of instances of a class in a graph" as this
>>> issue is called, because this does not constrain the number of 
>>> instances
>>> of a class in a graph. If this is presented as a solution, there 
>>> must be
>>> an explanation of how it differs from the requirement as stated. This
>>> sets as scope node any IRI provided. Nothing here checks that "ex:A" is
>>> the object of rdf:type.
>>>
>>> kc
>>>
>>> On 6/21/16 3:38 PM, Holger Knublauch wrote:
>>>>
>>>>
>>>> On 22/06/2016 4:57, Karen Coyle wrote:
>>>>> OK, let me persist here. We have the suggested code example of:
>>>>>
>>>>> ex:MyShape
>>>>>    a sh:Shape ;
>>>>>    sh:scopeNode schema:FlightReservation ;
>>>>>    sh:constraint [
>>>>>        sh:minInstanceCount 1 ;
>>>>>        sh:maxInstanceCount 1 ;
>>>>>    ] .
>>>>>
>>>>> I'm going to abstract this as:
>>>>>
>>>>> ex:MyShape
>>>>>    a sh:Shape ;
>>>>>    sh:scopeNode ex:A ;
>>>>>    sh:constraint [
>>>>>        sh:minInstanceCount 1 ;
>>>>>        sh:maxInstanceCount 1 ;
>>>>>    ] .
>>>>>
>>>>> Given the examples below, which of these are in scope for
>>>>> "sh:scopeNode ex:A"
>>>>>
>>>>> ex:A ex:B ex:C .
>>>>>
>>>>> ex:B ex:A ex:C .
>>>>>
>>>>> ex:B ex:C ex:A .
>>>>
>>>> Just ex:A is in scope. sh:scopeNode is independent of any triples, 
>>>> i.e.
>>>> even if a node appears in no triple, it would still be in scope. This
>>>> also means that sh:scopeNode is orthogonal to a node being subject,
>>>> predicate or object. This is only relevant to sh:scopeProperty and
>>>> sh:scopeInverseProperty.
>>>>
>>>> Holger
>>>>
>>>>
>>>>>
>>>>>
>>>>> kc
>>>>>
>>>>> On 6/17/16 4:43 PM, Irene Polikoff wrote:
>>>>>> Also, I don¹t think the below is right. I thought that the scope
>>>>>> identifies nodes. Not subject or objects, just nodes.
>>>>>>
>>>>>> Then, constraints specify conditions or patterns to be specified.
>>>>>> Focus
>>>>>> nodes can be either an object or a subject in these patterns. For
>>>>>> example,
>>>>>> when a PropertyConstraint is used focus nodes are subjects, but an
>>>>>> InverseProperty constraint specifically allows specifying patterns
>>>>>> where
>>>>>> focus nodes are objects.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 6/17/16, 1:10 PM, "Karen Coyle" <kcoyle@kcoyle.net> wrote:
>>>>>>
>>>>>>> nd scopeNode binds to the subject of a
>>>>>>> triple, AFAI can determine.
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>> -- 
>>> Karen Coyle
>>> kcoyle@kcoyle.net http://kcoyle.net
>>> m: 1-510-435-8234
>>> skype: kcoylenet/+1-510-984-3600
>>>
>>
>>
>>
>

Received on Wednesday, 22 June 2016 23:27:41 UTC