W3C home > Mailing lists > Public > semantic-web@w3.org > May 2011

Re: Best Practice for Renaming OWL Vocabulary Elements

From: Ryan Kohl <ryanckohl@gmail.com>
Date: Wed, 18 May 2011 15:05:35 -0400
Message-ID: <BANLkTikJno8BkyV75bhbBzF6cAiC1hCNfA@mail.gmail.com>
To: Michael F Uschold <uschold@gmail.com>
Cc: Martin Hepp <martin.hepp@ebusiness-unibw.org>, Alan Ruttenberg <alanruttenberg@gmail.com>, "semantic-web@w3.org" <semantic-web@w3.org>, "public-lod@w3.org" <public-lod@w3.org>
Michael,
  You're primarily suggesting that Individuals be assigned meaningless URIs,
leaving the URIs for Classes and Properties meaningful, right?  Otherwise,
writing and maintaining SPARQL queries would look like an exercise in
assembler :)
-Ryan

On Wed, May 18, 2011 at 2:37 PM, Michael F Uschold <uschold@gmail.com>wrote:

> Alan, I'm glad you made that suggestion.  I was also glad to see that
> Tim-BL acknowledged that the URIs are just identifiers.  As you know, noone
> seems to be treating them that way, nor is there good tool support to make
> it easy to do -- probably the main reason the practice persists.
>
> Part of Martin's argument is based on what he already did, given that,
> maybe he is doing the right thing now.
>
> Moving forward for the broader semantic web community,  the more
> interesting question is, if Martin was starting from scratch right now,
> would there still be any good arguments for having URIs with meaningful
> names?
>
> Given the RDFa context:
>
>    - How much effort would it be, in terms of extra tool support, or
>    training users etc.
>    - Would it have even been possible to get GR off the ground in todays
>    market place w/o meaningful URIs?
>
>
> It will be interesting to see how this issue unfolds.  It is not going away
> any time soon.
>
> Michael
>
>
> On Fri, Apr 22, 2011 at 1:58 PM, Martin Hepp <
> martin.hepp@ebusiness-unibw.org> wrote:
>
>> Hi Alan:
>> Thanks for the suggestion. However, I am convinced that numerical IDs are
>> not suited for ontologies that will mostly be used in RDFa syntax.
>> Also, changing a majority of identifiers of an already established
>> vocabulary would mean throwing away all of the existing momentum. There may
>> be technical gains, but in terms of network economics, this would be
>> suicide.
>> That is no option in my case and also not needed.
>>
>> To keep things in perspective: GoodRelations is deployed and stable. I am
>> only trying to shorten the identifier of two conceptual elements already in
>> moderate use, because I think that the increased ease for writing markup and
>> queries will be much bigger than the loss in terms of broken legacy systems
>> or data.
>>
>> On the more theoretical side, I do not thing that English identifiers are
>> necessarily a barrier to global adoption. HTML is based in English
>> identifiers, most XML schemas are based on English identifiers, the HTTP
>> protocol uses English tokens, etc. ;-)
>>
>> Martin
>>
>> On Apr 22, 2011, at 8:14 PM, Alan Ruttenberg wrote:
>>
>> > Dear Martin,
>> >
>> > My advise is to bite the bullet now and once and change all the URIs to
>> use numerical ids, ridding them of any domain content.
>> >
>> > If you have the desire now to change a string you will have it again.
>> Get rid of the issue now and forever while the semantic web is young.
>> >
>> > Aside from the issue you are facing, in my opinion choosing any
>> particular language (English in this case) in a privileged position in the
>> URI will be a barrier, perhaps subtle, to global adoption.
>> >
>> > The OBO Foundry policy is at http://obofoundry.org/id-policy.shtml  the
>> in case it might be useful. You will see we decided to bite the bullet
>> (because of another bad design choice) and how we are documenting it.
>> >
>> > -Alan
>> >
>> > On Apr 21, 2011, at 5:46 AM, Martin Hepp <
>> martin.hepp@ebusiness-unibw.org> 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
>> >>
>> >> --------------------------------------------------------
>> >> martin hepp
>> >> e-business & web science research group
>> >> universitaet der bundeswehr muenchen
>> >>
>> >> e-mail:  hepp@ebusiness-unibw.org
>> >> phone:   +49-(0)89-6004-4217
>> >> fax:     +49-(0)89-6004-4620
>> >> www:     http://www.unibw.de/ebusiness/ (group)
>> >>        http://www.heppnetz.de/ (personal)
>> >> skype:   mfhepp
>> >> twitter: mfhepp
>> >>
>> >>
>> >>
>> >
>>
>>
>>
>
>
> --
> Michael Uschold, PhD
>    Senior Ontology Consultant, Semantic Arts
>    LinkedIn: http://tr.im/limfu
>    Skype, Twitter: UscholdM
>
>
Received on Friday, 20 May 2011 06:56:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:48:27 UTC