Re: Labels separate from localnames (Was: Best Practice for Renaming OWL Vocabulary Elements

See several comments inline.

Le 22/04/2011 09:44, Martin Hepp a écrit :
> Hi Tim, all:
>
> First: Thanks for your great feedback.
>
> As for labels vs. identifiers: What I want to do is change the
> identifier of a few conceptual elements. The reason why I also
> changed the labels in my example is that in GoodRelations, labels are
> historically geared towards the publisher of data and not the
> consumer and thus as close as possible to the identifier. Thus, we
> currently use
>
> - the original camel words for class labels, (e.g. "BusinessEntity")
> - the original camel words plus and indicator for cardinality
> information for properties (e.g. "eligibleRegions (0..*)") - the
> original camel words plus a hint to the most relevant class for an
> individual (e.g. "MasterCard (PaymentMethod)", even though
> gr:MasterCard is also an instance of gr:PaymentMethodCreditCard, but
> it is more important to know that it is a payment method)
>
> I agree with your suggestions to change the syntax in the labels from
> the camel words to regular spaces in between the words, but I want to
> keep the cardinality information for properties and the class
> membership information for individuals.
>
> Again, I think the perspective of someone coding / publishing data is
> more important that the consumption side, in my opinion, because in
> non-trivial data structures (e.g. relationships of higher arity), one
> cannot derive a meaningful user interface directly from the raw
> labels anyway. I assume that 90 % of the people consuming the
> GoodRelations specification, in both OWL and HTML, will be Web
> developers trying to encode data, not clients used for displaying the
> raw data.

Sorry to say this, but I think you are making a mistake. To say that the 
rdfs:label has to look like a variable name because it is for Web 
developers sounds to me like you are saying that the javadoc of a method 
should look like a piece of code because it is addressed to programmers. 
I refuse to believe that Web developers understand better pseudo code 
than natural language.

Moreover, Web clients most of the time display raw data (in a nice way) 
extracted from databases. For instance, a Wikipedia article displays a 
nice readable title, which is exactly the raw data that is found in a 
column of a database. Of course, you can decide that you won't use 
rdfs:label for human readable text and reserve another property for that 
(eg, dc:title), but you cannot decide how others will use your data and 
they may have a preference for the rdfs:label. As a matter of fact, 
rdfs:label is commonly used for showing people a nice readable piece of 
text in natural language.

Now, let's imagine I have a "product browser" which aggregates 
information about products found on the Web, leveraging the 
GoodRelations vocabulary and possibly other vocabularies. It may display 
the products in a table and have a column for "product type", which 
displays the class of the product. There are chances that the client 
will display the rdfs:label of the class as the "product type", which in 
the case of GoodRelations would look sibylline to a casual reader, with 
camel-toed text and nonsensical information about arity.

Moreover, with such practice, how can you provide labels in multiple 
languages? Paymentmethod is not even an English word!

Having said that, I don't agree with Tim when he says that the URI of 
the class should never change and that we don't care how it looks. The 
class name is important, it has to be easy to remember and meaningful. 
Like in a computer programme, the names of the variables do matter.
Plus, I find it ok to add a new name while keeping the one which is 
already used and assert an equivalence between the two.

> See inline comments for the remaining points.
>
> On Apr 21, 2011, at 11:15 PM, Kingsley Idehen wrote:
>
>> On 4/21/11 3:19 PM, Tim Berners-Lee wrote:
>>> Martin,
>>>
>>> Confused. Do you mean you want to change the localname (the bit
>>> after the namespace in the URI) or the label?
> Actually both, because they are the same in the case of
> GoodRelations, but the important thing is changing the localname so
> that coding in RDFa gets simpler and quicker.
>>>
>>> In your examples below, you have the same string for the
>>> localname and label. This looks like a bug.
> It was intended, but I see your point and share Kingsley's support
> for more readable labels.
>
>>> Let me explain things from the point of view of the tabulator,
>>> for example, which actually uses the rdfs:label for users.
>>>
>>>
>>> 0) if you want to change the label, don't change the URI. Keep
>>> the URIs the same, unless the meaning has changed, in which case
>>> make a new URI and keep the old one marked obsolete.
> The meaning has not changed, but I have to make coding in RDFa easier
> for common class names without breaking existing code or data. For
> example, GoodRelations uses, for historic reasons, a long name for
> stores, etc., which tries to capture the ontological essence:
>
> gr:LocationOfSalesOrServiceProvisioning
>
> It could not have been gr:Store, because this is basically and point
> of interest from which a product or service is available, including
> bus stops, gas stations, movie theaters, etc.
>
> But since this class is so frequently used, I want to change it to
> simply gr:Location while remaining as much of backward compatibility
> as possible; that is the background of the pattern I suggested.

Ouch! I'm afraid amateur Linked Data producers who are searching for 
terms in a SemWeb search engine will find gr:Location very appropriate 
for *any* location. As a consequence, it will be inferred that all 
locations recorded in geonames are selling something! The Semantic Web 
will break and bring in its downfall the World Wide Web and the 
Internet, then the end of the world...

>>>
>>> The actual string used in the URI has no meaning, it is just an
>>> identifier.
> Yes, thats clear.
>>> If it seems weird but people use it - make sure it is well
>>> documented but don't change it if there is data using it out
>>> there. Do make sure the labels track the meaning and usage.
>
> Well, in my case that would mean I cannot change a)
> gr:LocationOfSalesOrServiceProvisioning to gr:Location b)
> gr:ProductOrServicesSomeInstancesPlaceholder to gr:SomeItems and c)
> gr:ActualProductOrServiceInstance gr:Individual

Those names are horribly long but they have the merit of being little 
ambiguous, as opposed to gr:Individual. In FOAF, the names are very 
short, which certainly helps getting the vocabulary adopted but creates 
a considerable amount of misuses (foaf:img, foaf:mbox, ...).  Moreover, 
these long names are easier to discover in keyword-based search engines 
because there is more contextual information to properly index and 
relate the words in the name.

> but I want to and will do that because the loss in backwards
> compatibility (if any) is minimal as compared to the increased ease
> of creating data, in particular in RDFa. Reducing the effort for lay
> Web developers to use SW tech is key.
>
>
>>>
>>>
>>> 1) Please use for the RDFS label what you would expect to see in
>>> a form which a user is filling in. Ideally give it in several
>>> languages.
>> +1
>>
> As said, I am considering to change the formatting from camel word to
> non-camel style but keep the cardinality and class membership info
> for developers. The issue of several languages is, in theory, a nice
> feature, but extremely difficult to implement in six-sigma quality
> due to the differences in connotations and semantic granularity of
> natural languages. Having second-class translations would do more
> harm than good, in my opinion. The only reliable translations I could
> provide easily would be German, but that would really not increase
> adoption significantly - most German Web developers speak English.

You do not need to make the translations yourself. Find fluent 
translators or expert linguists.

>>> So  gr:valueAddedTaxIncluded rdfs:label  "includes VAT"@en, "TVA
>>> inclus"@fr .
>
> I am willing to change thus to "value added tax included" but want to
> avoid major differences between the identifiers and the labels,
> because someone using authoring tools should be kept familiar with
> the identifiers.
>>>
>>> This will be often shorter than a long URI localname
>>>
>>> The label has to be a reasonable prompt for the user, and not a
>>> complete explanation of what the field means.  It should be
>>> usable also as a column  heading in a table, for example.   So
>>> while the URI is "gr:availableDeliveryMethods" the best label
>>> might just be "delivery methods".   The longer string makes it
>>> clear for developers but the short label is quite explicit enough
>>> for a column header or field name in a report generated for a
>>> user.
> Well, from a perspective of consuming SW data in a tabular form, you
> are definitely right; however, I am not yet convinced that this is
> the most important use-case to address by rdfs:label in a Web
> ontology.
>
>>>
>>>
>>>
>>> 1.1) DO NOT do
>>>
>>> gr:appliesToDeliveryMethod rdfs:label "appliesToDeliveryMethod".
>>>
>>> This is worse than nothing. If you leave no rdf:label at all for
>>> gr:appliesToDeliveryMethod, then tabulator will synthesize a
>>> label "applies to delivery method" from the camel case. Actually
>>> on a form it will typically use the string "Applies to delivery
>>> method" as in English often form field names are capitalized.
>>>
>>> If you give an rdf label which actually is just the same as the
>>> URI localname, you are saying that that is the string which you
>>> recommend be used for the form.  This will force tabulator to
>>> display the camel-case, which is not user-friendly.
> This is, IMO, a Tabulator-specific issue and only addresses the
> *consumption* of the data in a tool that directly uses the vocabulary
> labels for generating the user interaction. I am so far unconvinced
> that this is a dominant use-case for interacting with GoodRelations
> data. For example, a user seeing GoodRelations data via Google Rich
> Snippets or Yahoo SearchMonkey will never see the vocabulary labels,
> only the person configuring the generation of data.

Google Rich Snippets don't show the labels because it is specifically 
tuned for GoodRelations. But a generic tool which aggregates information 
from various sources using various vocabularies has to make a generic 
assumption on what to display. rdfs:label is what is often chosen by 
generic tools to be shown to people.

>>>
>>
>> +1
>>
>>> 2) Never put explanations for ontology engineers in the label. In
>>> the comment, OK, not the label.
>>>
>>>
>>> NOT rdfs:label "NewPropertyName1 (Note: See old URI
>>> foo:LongPropertyName1 used previously)" . but more like
>>> rdfs:label "new form label1"; rdfs:comment " (Note: See old URI
>>> foo:LongPropertyName1 used previously)" .
>>>
>>> You don't want that stuff showing up for users, in reports,
>>> forms, etc.
>
> As for the reference to the new element etc., I agree with you; that
> was just to keep the proposal short and simple. We will usually have
> a note "(DEPRECATED)" as part of the label, but no further
> explanation.
>
> It is pretty simple for and end-user tool to filter out the three
> patterns of developer information from GoodRelations labels by simple
> regex.
 >
> Again, the majority of the people dealing with rdfs:labels from
> vocabularies will be developers, not end-users, because you will need
> an intermediate layer between the data and the user anyway.

Again, this only works if you fine tune your application towards 
GoodRelations. One of the strength of RDF is that it is easy to 
aggregate data relying on many vocabularies that the consuming 
application doesn't even know about. Having general guidelines for 
rdfs:label such that it can be applied to any vocabulary is very good, 
IMO. By ignoring these guidelines, you make GoodRelations a kind of 
proprietary format which only works fine with GoodRelations-specific 
applications.


Regards,
AZ.

>>
>> +1
>>
>> Martin:
>>
>> In addition, if you are evolving the ontology (which I believe is
>> the case) and seek to keep backward compatibility i.e., keeping
>> classes and properties functional across ontology releases, just
>> use owl:equivalentClass and owl:equivalentProperty accordingly.
>> Naturally, if this evolution includes new levels abstraction then
>> rdfs:subClassOf and rdfs:subPopertyOf should be put to use etc..
> Yes, that was in my original proposal.
>>
>> We can't really negate reasoning, especially when showcases emerge
>> that help general appreciation of OWL which (IMHO) continues to get
>> an unjustified bad rap.
> Yes, I agree. I also think that since the little bit of reasoning
> needed in here can be easily implemented in SPARQL CONSTRUCT rules or
> SPIN, it is much better to take conceptually superior OWL axioms than
> "quick and dirty sameAs", which will backfire in the long run.
>
> Again, thanks for your detailed feedback!
>
> Martin
>

[...]

-- 
Antoine Zimmermann
Researcher at:
Laboratoire d'InfoRmatique en Image et Systèmes d'information
Database Group
7 Avenue Jean Capelle
69621 Villeurbanne Cedex
France
Tel: +33(0)4 72 43 61 74 - Fax: +33(0)4 72 43 87 13
Lecturer at:
Institut National des Sciences Appliquées de Lyon
20 Avenue Albert Einstein
69621 Villeurbanne Cedex
France
antoine.zimmermann@insa-lyon.fr
http://zimmer.aprilfoolsreview.com/

Received on Friday, 22 April 2011 10:33:38 UTC