Re: shapes-ISSUE-112 (misuse of RDFS properties): SHACL uses RDFS properties in ways that violate their intended RDFS meaning [SHACL Spec]

On 11/7/15 3:40 AM, Peter F. Patel-Schneider wrote:
> rdfs:label and rdfs:comment are supposed to be about the resource itself,
> which for SHACL is a constraint or shape.  However, the wording in SHACL says
> to make them about the property, which is different from the constraint or shape.

Please read again. The wording is about the property *in the scope where 
it appears*. The scope where it appears is exactly what the constraint 
represents - it's the use of a property in the context of a shape.

Also note that Peter's proposal doesn't even suggest an alternative to 
using rdfs:label or rdfs:comment. The way that it's written he would 
just delete this possibility altogether, just like he wants to delete 
sh:defaultValue (in a separate ticket). The last time I looked, WG 
members were encouraged to find compromises.

Holger


>
> For example, the SHACL example is
>
> ex:InlinePropertyConstraintExampleShape
>  a sh:Shape ;
>  sh:property [
>   sh:predicate ex:someProperty ;
>   sh:minCount 1 ;
>   sh:valueClass ex:SomeClass ;
>   rdfs:label "some property" ;
>   rdfs:comment "This is used for some purpose" ;
>  ] .
>
> where as it really should be
>
> ex:InlinePropertyConstraintExampleShape
>  a sh:Shape ;
>  sh:property [
>   sh:predicate ex:someProperty ;
>   sh:minCount 1 ;
>   sh:valueClass ex:SomeClass ;
>   rdfs:label "ex:someProperty constraint in
> ex:InlinePropertyConstraintExampleShape" ;
>   rdfs:comment "This constrains values of ex:someProperty to belong to
> ex:someClass" ;
>  ] .
>
> peter
>
>
> On 11/06/2015 07:40 AM, Karen Coyle wrote:
>> Peter, this is a bit overly subtle for me. Can you say what exactly you see as
>> violating RDFS? I'll tell you what I see and you can tell me how I'm wrong ;-)
>> - when a property is itself a resource (X rdfs:label Y) then this has the RDFS
>> meaning. What I see is that the resource that is named with rdfs:label in the
>> case of SHACL is the blank node.
>>
>> Now, what's the real problem? I assume it's not just wording.
>>
>> Thanks,
>> kc
>>
>> On 11/5/15 3:57 PM, Holger Knublauch wrote:
>>> I had long thought about using new properties such as sh:label and
>>> sh:definition instead. I decided to prefer rdfs:label and rdfs:comment,
>>> because these properties are most likely already used as annotations on
>>> the shapes, classes and other resources in SHACL files. People will get
>>> confused which property to use in which context, adding just another
>>> unnecessary complication in the learning curve.
>>>
>>> Since a property constraint resource describes the use of a property in
>>> the context of a shape scope, I see no reason why using rdfs:label would
>>> violate the official spec.
>>>
>>> PROPOSAL: Close ISSUE-112 - no change required.
>>>
>>> Holger
>>>
>>>
>>> On 11/6/2015 7:55, RDF Data Shapes Working Group Issue Tracker wrote:
>>>> shapes-ISSUE-112 (misuse of RDFS properties): SHACL uses RDFS
>>>> properties in ways that violate their intended RDFS meaning [SHACL Spec]
>>>>
>>>> http://www.w3.org/2014/data-shapes/track/issues/112
>>>>
>>>> Raised by: Peter Patel-Schneider
>>>> On product: SHACL Spec
>>>>
>>>> >From http://w3c.github.io/data-shapes/shacl/:
>>>>
>>>> Property constraints may have an rdfs:label to provide a
>>>> human-readable label for the property in the scope where it appears.
>>>>
>>>> >From http://www.w3.org/TR/rdf-schema/
>>>>
>>>> rdfs:label is an instance of rdf:Property that may be used to provide
>>>> a human-readable version of a resource's name.  A triple of the form:
>>>> R rdfs:label L . states that L is a human readable label for R.
>>>>
>>>> The SHACL use does not abide by the RDFS meaning.  SHACL should not
>>>> use RDFS properties in ways that violate their RDFS meaning.
>>>>
>>>> Similarly for rdfs:comment.
>>>>
>>>>
>>>> PROPOSAL:  Remove the non-conforming wording for and uses of
>>>> rdfs:label and rdfs:commment.
>>>>
>>>>
>>>>
>>>
>>>

Received on Friday, 6 November 2015 20:37:25 UTC