- From: Holger Knublauch <holger@topquadrant.com>
- Date: Thu, 12 Nov 2015 08:37:43 +1000
- To: public-data-shapes-wg@w3.org
I expect users to be confused about when to use which property. Consider ex:Person a sh:ShapeClass ; rdfs:label "Person" ; sh:property [ sh:predicate ex:firstName ; sh:label "first name" ; ] . There would be two label properties. People will mix these up all the time. We will need to explain this over and over again,. This will become worse in JSON-LD where a @context would likely turn this into { "@id" : "ex:Person", "@type" : "ShapeClass", "rdfs:label" : "Person", "property" : [ { "predicate" : "ex:firstName", "label" : "first name" } ] } I'd rather map "label" to "rdfs:label" everywhere so that the default namespace can be used for the whole system vocabulary. I believe both of these approaches have weaknesses, so a pragmatic compromise would be best. Holger On 11/12/2015 3:30, Karen Coyle wrote: > I want to note here that I am not (and I don't think anyone else is) > arguing that we should not have UI labels for properties. My only > concern is that rdfs:label is being used in a way incompatible with > its definition. It would make sense to me to define sh:label and any > other SHACL-specific properties to fulfill UI functions that are > desired. We should think through the functions needed for forms and UI > first, and then discuss how they best fit into SHACL. The current > implementation of this functionality seems a bit haphazard, and is > also greatly under-specified in our use cases and requirements. > > This would allow us to use rdfs:label and rdfs:comment in SHACL graphs > in a way that is compatible with their use in RDFS. However, we should > make sure that this is sufficient for the desired documentation > functionality. > > kc > > On 11/10/15 8:02 AM, Karen Coyle wrote: >> On 11/9/15 7:02 PM, Holger Knublauch wrote: >>> On 11/10/2015 12:54, Karen Coyle wrote: >>>> Holger, in the case of a more complex example, such as Ex. 11: >>>> >>>> ex:StandAlonePropertyConstraintExampleShape >>>> a sh:Shape ; >>>> sh:property ex:StandAloneConstraint . >>>> >>>> ex:StandAloneConstraint >>>> a sh:PropertyConstraint ; >>>> sh:predicate ex:someProperty ; >>>> sh:defaultValue ex:SomeInstance ; >>>> sh:minCount 1 ; >>>> sh:valueClass ex:SomeClass . >>>> >>>> What does it mean to include a label in ... >>>> >>>> ex:StandAlonePropertyConstraintExampleShape >>>> a sh:Shape ; >>>> sh:property ex:StandAloneConstraint ; >>>> rdfs:label "something something " . >>> >>> That label is about the Shape. >>> >>>> >>>> ...and if you have ... >>>> >>>> ex:StandAloneConstraint >>>> a sh:PropertyConstraint ; >>>> sh:predicate ex:someProperty ; >>>> sh:defaultValue ex:SomeInstance ; >>>> sh:minCount 1 ; >>>> sh:valueClass ex:SomeClass ; >>>> rdfs:label "label label label" . >>> >>> That label is about the constraint, which is about the use of a >>> property >>> in the context of a shape. >> >> So isn't this the same as your example below? >> >> >>> ex:MyShape >> >>> a sh:Shape ; >> >>> sh:property [ >> >>> sh:predicate ex:firstName ; >> >>> sh:maxCount 1 ; >> >>> rdfs:label "first name" ; >> >>> ] . >> >> and therefore both labels are about the shape, not the property? If so, >> then the text in the draft is misleading, because it says: >> >> "Property constraints may have an rdfs:label to provide a human-readable >> label for the property in the scope where it appears." >> >> Because the label is on the constraint, and therefore labels the >> constraint regardless of whether it is a property constraint or some >> other type of constraint. I just don't see a situation where "label for >> the property" is valid. >> >> kc >> >>> >>> Holger >>> >>>> >>>> ... does it label ex:someProperty? ex:SomeClass? or >>>> ex:StandAloneConstraint? Note that we require the ability to add human >>>> readable labels and comments to a shapes in general. rdfs:label and >>>> rdfs:comment were cited as the solutions to requirement R4, which >>>> requires human-readable documentation that is associated with SHACL >>>> instances.[1] >>>> >>>> kc >>>> [1] >>>> https://docs.google.com/document/d/1whx2DeJtng-WZXo2DAHc_GZL7ElXNS_B8fBxarGA-0o >>>> >>>> >>>> >>>> >>>> >>>> On 11/9/15 2:49 PM, Holger Knublauch wrote: >>>>> Karen, >>>>> >>>>> if we look at >>>>> >>>>> ex:MyShape >>>>> a sh:Shape ; >>>>> sh:property [ >>>>> sh:predicate ex:firstName ; >>>>> sh:maxCount 1 ; >>>>> rdfs:label "first name" ; >>>>> ] . >>>>> >>>>> The maxCount does not generally apply to the property >>>>> ex:firstName, but >>>>> to the *use of ex:firstName in the context of ex:MyShape*. That's the >>>>> same situation with the label. SHACL doesn't talk about the (global) >>>>> label of ex:firstName, but only about the local label. The blank >>>>> node is >>>>> about the use of the property in the shape, so there is nothing wrong >>>>> with reusing rdfs:label here. >>>>> >>>>> Holger >>>>> >>>>> >>>>> On 11/10/15 12:18 AM, Karen Coyle wrote: >>>>>> Well, yes, I think that Peter has pointed out an issue -- that >>>>>> rdfs:label in this: >>>>>> >>>>>> >>>>> 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" ; >>>>>> >>>>> ] . >>>>>> >>>>>> refers to the blank node, not the ex:someProperty. So it isn't clear >>>>>> to me how any system that adheres to rdfs would display that as the >>>>>> label for the property. This is particularly puzzling because there >>>>>> has been much talk of combining SHACL and instance data, which quite >>>>>> possible makes use of rdfs:label as defined in rdfs. >>>>>> >>>>>> rdfs:label is a label for the subject of the triple. >>>>>> >>>>>> rdfs:comment is shown in Example 10 as: >>>>>> >>>>>> "rdfs:comment "Description of the role of ex:someProperty (in the >>>>>> context of the constraint)" ;" >>>>>> >>>>>> It looks to me that rdfs:comment could be used as a comment on the >>>>>> property constraint represented by the blank node, but again >>>>>> there is >>>>>> nothing in rdfs that connects it to the value ex:someProperty. So >>>>>> in a >>>>>> case where SHACL and instance data are in the same graph, how is it >>>>>> possible that rdfs:label and rdfs:comment will have such different >>>>>> meanings? RDF aside, that's something that I would assume would be >>>>>> discouraged in any programming language. >>>>>> >>>>>> kc >>>>>> >>>>>> >>>>>> >>>>>> On 11/8/15 4:40 PM, Holger Knublauch wrote: >>>>>>> I had seen similar comments in the Twittersphere recently. I >>>>>>> believe the >>>>>>> wording of section 1.1 is unnecessarily dramatic. I had meanwhile >>>>>>> tried >>>>>>> to soften it up a bit, but it could need more work (I welcome >>>>>>> suggestions). >>>>>>> >>>>>>> http://w3c.github.io/data-shapes/shacl/#shacl-rdfs >>>>>>> >>>>>>> The main rationale was to allow SHACL to be used without requiring >>>>>>> full >>>>>>> RDFS inferencing. But I believe there is no harm in running SHACL >>>>>>> over a >>>>>>> system with RDFS activated. Does anyone see conditions where >>>>>>> applying >>>>>>> the RDFS semantics would cause measurable problems (leaving >>>>>>> aside the >>>>>>> usual philosophical questions about the distinction between a >>>>>>> representation and the real-world entity that the rdfs:label >>>>>>> discussion >>>>>>> seems to refer to)? >>>>>>> >>>>>>> Holger >>>>>>> >>>>>>> >>>>>>> On 11/9/2015 10:14, Karen Coyle wrote: >>>>>>>> Well, these seems like a non-starter to me, and I don't understand >>>>>>>> why >>>>>>>> there isn't more concern. There is no way to prevent applications >>>>>>>> from >>>>>>>> applying RDFS semantics to the RDFS properties in SHACL. The >>>>>>>> statement >>>>>>>> in the introduction to SHACL that says ... >>>>>>>> >>>>>>>> "SHACL uses RDF and RDFS vocabulary (in particular rdf:type, >>>>>>>> rdfs:Class, rdfs:subClassOf, rdfs:label, rdfs:comment, >>>>>>>> rdf:Property, >>>>>>>> rdf:List, rdf:langLiteral, and rdfs:Resource) and notions (notably >>>>>>>> classes, instances, and subclasses). However, SHACL does not use >>>>>>>> this >>>>>>>> vocabulary or these notions in the way that they are defined in >>>>>>>> RDF >>>>>>>> and RDFS [rdf11-mt]." has always struck me as a huge red flag. >>>>>>>> >>>>>>>> kc >>>>>>>> >>>>>>>> On 11/6/15 8:24 PM, Peter F. Patel-Schneider wrote: >>>>>>>>> It would be ex:someProperty, not the [...] that is the value of >>>>>>>>> sh:property. >>>>>>>>> >>>>>>>>> In RDFS, rdfs:label and rdfs:comment are supposed to be about the >>>>>>>>> [...]. The >>>>>>>>> current non-conforming SHACL use is for ex:Property in the >>>>>>>>> context of >>>>>>>>> ex:InLinePropertyConstraintExampleShape. >>>>>>>>> >>>>>>>>> Note that in RDF there is no problem in having properties also be >>>>>>>>> nodes in the >>>>>>>>> graph. In RDFS properties are generally nodes in the graph so >>>>>>>>> that >>>>>>>>> they can be >>>>>>>>> given domains and ranges, etc. >>>>>>>>> >>>>>>>>> peter >>>>>>>>> >>>>>>>>> On 11/06/2015 11:39 AM, Karen Coyle wrote: >>>>>>>>>> Does "for the property in the scope where it appears" refer to >>>>>>>>>> sh:property or >>>>>>>>>> ex:someProperty in the example? It cannot be ex:someProperty >>>>>>>>>> because >>>>>>>>>> that >>>>>>>>>> isn't a rdf:Resource in the graph -- it's never a subject of a >>>>>>>>>> triple. All of >>>>>>>>>> the predicates in the sh:property [...] graph have >>>>>>>>>> sh:property as >>>>>>>>>> their subject. >>>>>>>>>> >>>>>>>>>> Now I'm fully confused about the whole sh:property graph and >>>>>>>>>> what the >>>>>>>>>> predicates in the graph mean. I should probably take a walk and >>>>>>>>>> think about it >>>>>>>>>> later. >>>>>>>>>> >>>>>>>>>> kc >>>>>>>>>> >>>>>>>>>> On 11/6/15 9: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. >>>>>>>>>>> >>>>>>>>>>> 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 Wednesday, 11 November 2015 22:38:22 UTC