W3C home > Mailing lists > Public > public-rdf-comments@w3.org > September 2016

Re: Usage of rdfs:label

From: Antoine Zimmermann <antoine.zimmermann@emse.fr>
Date: Thu, 15 Sep 2016 16:10:59 +0200
To: Richard Cyganiak <richard@cyganiak.de>, Felicja Sobczyk <felicja.sobczyk@kueea.info>
Cc: public-rdf-comments@w3.org
Message-ID: <57DAABF3.8080905@emse.fr>
I wouldn't have said better, Richard!

Note, however, that the W3C uses rdfs:label with values that follow the 
CamelCase convention (with labels like "seeAlso", "ObjectProperty", 
etc.), which is odd because it is a programming language convention, not 
to be used in natural language writing.  The values for rdfs:label are 
often used in end user applications to display information in natural 
language.  Such labels would look bizarre to non programmers and someone 
may even think that there is a typo or a bug.


Le 15/09/2016 15:15, Richard Cyganiak a écrit :
> Felicja,
> rdfs:label is for human-readable labels.
> You say: “If the label literal were to be used as a replacement for the URI, then I would not know what resource is the label for.”
> That’s right. But if you need to know *exactly* what resource the label is for, then why would you replace the URI with the label? If you need a precise, globally unique identifier, then use the URI. If you want something a bit shorter, use the canonical prefixed name such as rdfs:Resource. If you need something that looks like a normal end-user friendly string for rendering in an end-user interface, use the rdfs:label.
> You say: “There is nothing in this label telling me that "Resource" is a class.”
> That’s right. That’s why there is not just an rdfs:label but also an rdf:type!
> Labels are just that—labels. They don’t tell you everything about a resource, and are not necessarily unique.
> rdfs:Resource is a difficult example to make these distinctions clear, because it’s a metamodelling construct with a very specific meaning, and not a domain class. The distinction should be clearer if you consider a domain ontology like schema.org. It has classes for things like TV episodes, music playlists, bus trips, and so on. These terms may show up in end-user applications. The label presented to an end user should be “TV episode”, not “TVEpisode” or “schema:TVEpisode”. So, the rdfs:label should be “TV episode”, not “schema:TVEpisode”.
> Also consider multilinguality. Labels can be translated into different languages. If we had labels like “rdfs:Resource” or “schema:TVEpisode”, a translation would not be meaningful.
> Best,
> Richard
>> On 15 Sep 2016, at 12:26, Felicja Sobczyk <felicja.sobczyk@kueea.info> wrote:
>> Dear Antoine,
>> I understand that the definition of rdfs:label is outlined by the RDF
>> Schema specification. I asked, because the ontology returned by
>> requesting <http://www.w3.org/2000/01/rdf-schema> (and others) returns
>> a document with the labels I mentioned. I found it wierd. I should have
>> probably be more expressive about it.
>> I would rather expect the labels to at least contain an "rdfs:" prefix,
>> so that the label is not, for example "Resource", but "rdfs:Resource".
>> The label of "rdfs:Resource" would name the resource that is the class
>> of RDF resources as defined by RDF Schema in the general, universal
>> context. Such a label is also used in all specifications I have read.
>> I just don’t understand why the labels differs from the specification.
>> If the label literal were to be used a replacement for the resource URI,
>> then I would not know what resource is the label for. There is nothing
>> in this label telling me that "Resource" is a class; "rdfs:Resource"
>> would, because I am familiar with this (more expressive) label. It’s
>> more natural.
>> Was those documents produced by people other than those that have
>> written the specifications? Although, now that I am writing it,
>> I noticed that these is also a back-referenece in the form of
>> rdfs:isDefinedBy, so I’m maybe I’m being too picky here.
>> I wasn’t sure what would be the right design decision in a vocabulary
>> I’m writing as a hobby. I asked to be certain whether I ought to define
>> my properties as sub-properites or define them as distinct from
>> rdfs:label. The labels I saw confused me about the meaning of this property.
>> If I should be prioritizing the text of the specification, then your
>> answer is enough.
>> Sincerely,
>> Felicja
>> On 29/08/16 11:08, Antoine Zimmermann wrote:
>>> Dear Felicja,
>>> The intended meaning of the property rdfs:label is explained in the
>>> recommendation RDF Schema [1].  The property should be used to provide a
>>> human readable name for a resource.  It very often happens that
>>> rdfs:label (like all standard properties) is missused.  Considering the
>>> intended meaning of rdfs:label, one should not use camelCase or
>>> underscore_names as a label, IMHO.  Yet, what "human-readable" means is
>>> subject to interpretation and one could argue that camelCase identifiers
>>> are perfectly human-readable.
>>> Best,
>>> --AZ
>>> [1] Dan Brickley, R.V. Guha (eds.). RDF Schema 1.1, W3C Recommendation
>>> 25 February 2014. Section 3.6, rdfs:label.
>>> https://www.w3.org/TR/rdf-schema/#ch_label
>>> Le 27/08/2016 23:18, Felicja Sobczyk a écrit :
>>>> Excuse me, what is the intended usage of rdfs:label?
>>>> What the currently deployed software expects from the property value?
>>>> By examining RDF, RDF Schema and OWL2 vocabularies, I can see that all
>>>> terms contain their local names as their labels. Why? Why was such
>>>> a label chosen here? If it is supposed to be a human-readable name for
>>>> the resource, then why are there no spaces and the name is written in
>>>> camelCase? How is this property indended to be used by applications?
>>>> Is there some kind of context for the human readability that the
>>>> specification mentions?
>>>> Sincerely,
>>>> Felicja

Antoine Zimmermann
ISCOD - Institut Henri Fayol
École des Mines de Saint-Étienne
158 cours Fauriel
CS 62362
42023 Saint-Étienne Cedex 2
Tél:+33(0)4 77 42 66 03
Fax:+33(0)4 77 42 66 66
Received on Thursday, 15 September 2016 14:11:34 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 15 September 2016 14:11:34 UTC