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
>>
>
>
>
