- 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
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. --AZ 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 France Tél:+33(0)4 77 42 66 03 Fax:+33(0)4 77 42 66 66 http://zimmer.aprilfoolsreview.com/
Received on Thursday, 15 September 2016 14:11:34 UTC