- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Wed, 11 Nov 2015 15:04:57 -0800
- To: public-data-shapes-wg@w3.org
In a sense, I don't care at this point about some possible confusion (and personally I don't see it as confusing). The primary problem is the meaning of rdfs:label, which is not the meaning that is being proposed in SHACL. This is simply not an acceptable use of rdfs:label, IMO. If sh:label would be confusing, then it can be called something different, like sh:uiLabel or sh:formDisplay or anything else. We have the option to name the SHACL properties however we wish so if a name might be confusing, a different name can be chosen. It's a very weak argument to claim that the name is confusing when the name does not yet exist. And this makes no sense to me at all: > I'd rather map "label" to "rdfs:label" everywhere so that the default > namespace can be used for the whole system vocabulary. That is a statement about your application. "Mapping" of this type is a serialization issue -- in fact, all properties and classes are fully defined in their ntriple form and qnames are simply a programming convenience. There should be nothing in the SHACL standard that tells people which serialization they must use or what qualified names they should use, nor should decisions be made based on one person's preference in this area. kc On 11/11/15 2:37 PM, Holger Knublauch wrote: > 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. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> >>> >> > > > -- Karen Coyle kcoyle@kcoyle.net http://kcoyle.net m: 1-510-435-8234 skype: kcoylenet/+1-510-984-3600
Received on Wednesday, 11 November 2015 23:05:29 UTC