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

Martin,

Confused.
Do you mean you want to change the localname (the bit after the namespace in the URI) or the label?

In your examples below, you have the same string for the localname and label.
This looks like a bug.  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 actual string used in the URI has no meaning, it is just an identifier.
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.


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.

So  gr:valueAddedTaxIncluded rdfs:label  "includes VAT"@en, "TVA inclus"@fr .

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.



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.


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.

Tim

On 2011-04 -21, at 14:28, Martin Hepp wrote:

> Hi Bob,
> Thanks!
> 
> In my opinion, explicit versioning of ontologies should be avoided in general; rather, one should evolve deployed ontology in a backwards-compatible fashion only. While there is is quite some academic work on ontology versioning, fact is that in practice, if you use fine-grained versioning, the Semantic Graph will break more frequently and you will need a lot more inferred triples.
> 
> So in GoodRelations, we use only one version of the ontology (http://purl.org/goodrelations/v1) and all modifications are as much backwards-compatible as possible. From time to time, we have widened the domain or range of a property from a single class to the union of multiple classes or other minor changes, but the side-effects of that are practically irrelevant, in particular if you judge them in the light of real-world data quality of WWW data.
> 
> Thus, we do not use owl:priorVersion, owl:versionIRI, owl:backwardCompatibleWith etc., because it is still the same ontology. 
> 
> I intend to keep it like that ;-)
> 
> It's only now that I would like to use shorter labels for 2 - 3 conceptual elements that are already in use, without forcing anybody to 
> 
> - update data or
> - update derived ontologies or
> - change queries.
> 
> owl:sameAs for all classes, properties, and individuals would further reduce the type of reasoning needed to ensure backward-compatibility, but would at the same time turn GoodRelations into OWL Full.
> 
> As for the SemWeb Vocab Status ontology: For keeping things simple, we just use owl:deprecated for the few elements that have been deprecated over time. From my perspective, the popularity / usage of an existing element is more important than the indicated degree of stability.
> 
> Martin
> 
> On Apr 21, 2011, at 2:43 PM, Bob Ferris wrote:
> 
>> Hi Martin,
>> 
>> I think this issue is also related to ontology versioning and assigning an applied version of an ontology in a dataset (see, e.g., [1]).
>> OWL provides some properties to describe an version of an ontology, e.g., owl:priorVersion, owl:versionIRI, owl:backwardCompatibleWith (see [2,3]). However, all these relations have a range and domain of owl:Ontology. I'm unsure, whether you also like to type every property or class as an ontology (I think from a philosophical point of view this doesn't matter).
>> So far your class and property alignment to prior versions looks good. Albeit, I would separate these axioms from the core ontology, because they are only need if one likes to process reasoning with backward compatible term definitions.
>> Furthermore, you can make use of the SemWeb Vocab Status ontology [4] to mark an term, e.g., as 'archaic'.
>> 
>> Cheers,
>> 
>> 
>> Bob
>> 
>> 
>> [1] http://answers.semanticweb.com/questions/2815/how-do-i-knowmodel-the-applied-version-of-an-ontology-specification
>> [2] http://www.w3.org/TR/2009/REC-owl2-syntax-20091027/#Ontology_IRI_and_Version_IRI
>> [3] http://www.w3.org/TR/2009/REC-owl2-syntax-20091027/#Ontology_Annotations
>> [4] http://www.w3.org/2003/06/sw-vocab-status/ns#
>> 
>> On 4/21/2011 11:46 AM, Martin Hepp wrote:
>>> Dear all:
>>> 
>>> I am considering to rename a few conceptual elements in the GoodRelations ontology. However, they are already in use in data, queries, and applications. Thus, I am thinking of the least intrusive way of implementing this. I think this question is also relevant for many other OWL vocabularies on the Web.
>>> 
>>> Attached, please find my proposal. It critically depends on the ability of typical triple-stores to compute basic(*) inferences for
>>> 
>>> - owl:equivalentProperty for owl:DatatypeProperty and owl:ObjectProperty entities,
>>> - owl:equivalentClass for pairs of owl:Class and
>>> - owl:sameAs for pairs of "ontological" instances, e.g. value nodes defined in the vocabulary.
>>> 
>>> With "basic", I mean that additional triples for the additional class membership or property or instance must be materialized; this could be a subset of the complete theoretical implications.
>>> As far as I know, Virtuoso does support this to a sufficient degree, but I am unsure about other parts of widely deployed infrastructure.
>>> 
>>> It would be no problem to express the necessary inferences by means of a SPARQL CONSTRUCT rule or in SPIN.
>>> 
>>> Please share any suggestions and concerns with me.
>>> 
>>> Old, but in use:
>>> ---------------
>>> foo:LongClassName a owl:Class ;
>>> 	rdfs:label "LongClassName" .
>>> 
>>> foo:LongPropertyName1 a owl:DatatypeProperty ;
>>> 	rdfs:domain foo:LongClassName ;
>>> 	rdfs:label "LongPropertyName1" .
>>> 
>>> foo:LongPropertyName2 a owl:ObjectProperty ;
>>> 	rdfs:domain foo:LongClassName ;
>>> 	rdfs:range foo:SomeOtherClass1 ;	
>>> 	rdfs:label "LongPropertyName1" .
>>> 
>>> foo:LongNameIndividual a foo:SomeOtherClass2 ;
>>> 	rdfs:label "LongNameIndividual" .
>>> 
>>> Now, we want to rename those elements as follows, without breaking old data nor old queries / applications:
>>> 
>>> foo:LongClassName -->  foo:NewClassName
>>> foo:LongPropertyName1 -->  foo:NewPropertyName1
>>> foo:LongPropertyName2 -->  foo:NewPropertyName2
>>> foo:LongNameIndividual -->  foo:NewNameIndividual
>>> 
>>> Proposal:
>>> --------
>>> a) Step 1: Define new classes, properties, individuals and link back to their old variants
>>> 
>>> foo:NewClassName a owl:Class ;
>>> 	owl:equivalentClass foo:LongClassName .
>>> 	rdfs:label "NewClassName (Note: This was foo:LongClassName previously)" .
>>> 
>>> foo:NewPropertyName1 a owl:DatatypeProperty ;
>>> 	owl:equivalentProperty foo:LongPropertyName1 ;
>>> 	rdfs:domain foo:NewClassName ;
>>> 	rdfs:label "NewPropertyName1 (Note: This was foo:LongPropertyName1 previously)" .
>>> 
>>> foo:NewPropertyName2 a owl:ObjectProperty ;
>>> 	owl:equivalentProperty foo:LongPropertyName2 ;
>>> 	rdfs:domain foo:NewClassName ;
>>> 	rdfs:range foo:SomeOtherClass1 ;	
>>> 	rdfs:label "NewPropertyName2 (Note: This was foo:LongPropertyName2 previously)" .
>>> 
>>> foo:NewNameIndividual a foo:SomeOtherClass2 ;
>>> 	owl:sameAs foo:LongNameIndividual ;
>>> 	rdfs:label "NewNameIndividual (Note: This was foo:LongNameIndividual previously)" .
>>> 
>>> b) Step 2: Deprecate the old elements in OWL 2 style (using owl:deprecated)
>>> foo:LongClassName a owl:Class;
>>> 	owl:deprecated true;
>>> 	rdfs:label "LongClassName - Deprecated, use foo:NewClassName instead" .
>>> 
>>> foo:LongPropertyName1 a owl:DatatypeProperty ;
>>> 	owl:deprecated true;
>>> 	rdfs:domain foo:LongClassName ;
>>> 	rdfs:label "LongPropertyName1 - Deprecated, use foo:NewPropertyName1 instead" .
>>> 
>>> foo:LongPropertyName2 a owl:ObjectProperty ;
>>> 	owl:deprecated true ;
>>> 	rdfs:domain foo:LongClassName ;
>>> 	rdfs:range foo:SomeOtherClass1 ;	
>>> 	rdfs:label "LongPropertyName1 - Deprecated, use foo:NewPropertyName2 instead" .
>>> 
>>> foo:LongNameIndividual a foo:SomeOtherClass2 ;
>>> 	owl:deprecated true ;
>>> 	rdfs:label "LongNameIndividual - Deprecated, use foo:NewNameIndividual instead" .
>>> 
>>> c) Since the owl:deprecated property is not defined in OWL1, I would also add the following axiom in order to remain within OWL 1 DL:
>>> #OWL 1 DL compatibility of the OWL2 deprecated property
>>> owl:deprecated a owl:AnnotationProperty.
>>> 
>>> Thanks in advance!
>>> 
>>> Best
>>> 
>>> Martin
>> 
> 
> 
>

Received on Thursday, 21 April 2011 19:20:01 UTC