Re: ISSUE-139: uniform descriptions and implementations of constraint components

I read the following sentence in the spec as meaning that {foaf:Person
rdf:type rdfs:Class} triple is not really required to be there in order to
use foaf:Person as scope node.

SHACL makes no assumption whether a SHACL class has any particular value
for rdf:type in the graph.


Is this correct?

Irene 





On 6/8/16, 1:32 AM, "Karen Coyle" <kcoyle@kcoyle.net> wrote:

>
>
>On 6/7/16 10:09 PM, Holger Knublauch wrote:
>>
>>
>> On 8/06/2016 14:57, Karen Coyle wrote:
>>>
>>>
>>> On 6/7/16 7:38 PM, Holger Knublauch wrote:
>>>> Yes and SHACL should implement the same policy, because sh:maxCount
>>>>also
>>>> only makes sense for predicate-based constraints and not node
>>>> constraints.
>>>
>>> Does this then rule out a constraint like "n things of type x"? For
>>> example, if you want to limit the number of foaf:Person nodes?
>>
>> No. To express "A graph must have at most 2 instances of foaf:Person"
>> you would write
>>
>> ex:MyShape
>>     a sh:Shape ;
>>     sh:scopeNode foaf:Person ;
>>     sh:inverseProperty [
>>         sh:predicate rdf:type ;
>>         sh:maxCount 2 ;
>>     ] .
>>
>> In other words "there must be at most 2 triples that have foaf:Person as
>> object and rdf:type as predicate".
>>
>> Peter's suggested use of sh:maxCount at node constraints would mean
>>
>> "Verify that the set of value nodes is not larger than two. Oh, and
>> regardless of the actual data, I already know that this set of value
>> nodes has size 1, because it always consists of the focus node only. So
>> actually I only need to test whether the value of sh:maxCount > 0."
>>
>> which is a rather useless construct. You have just confirmed that
>> misusing sh:maxCount as node constraints will likely confuse users.
>>
>> Is this difference clearer now, or what else could I clarify?
>
>Treating this as a simple test of the triple pattern makes sense to me,
>but it would make more sense if that was the general SHACL approach. In
>other words, the emphasis on the "class" nature elsewhere rather than
>always working with the abstract triple model. The emphasis on an
>interpretation of rdf:type as defining a class elsewhere in SHACL makes
>this simple solution less obvious. When is a class not a class? (That's
>a rhetorical question, but perhaps there is an answer.)
>
>kc
>
>
>>
>> Thanks,
>> Holger
>>
>>
>>
>
>-- 
>Karen Coyle
>kcoyle@kcoyle.net http://kcoyle.net
>m: 1-510-435-8234
>skype: kcoylenet/+1-510-984-3600
>

Received on Wednesday, 8 June 2016 07:02:29 UTC