Re: Best Practice for Renaming OWL Vocabulary Elements

When you speak of tools to overcome this limitation, I can imagine two
situations:

1. Protege, TopBraid, and the other development environments have their
interfaces tweaked.
2. Like C++ is to C and C is to assembler, a new query language is created
to manage the lower level details of SPARQL

Gun to my head, I'd choose the second path.  Since most of my SPARQL is
written alongside code, and I tend to code in Emacs, I might be waiting a
long time for Emacs to include the relevant interface tweaks.

Or is there another situation I'm not seeing?


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

>
>
> On Wed, May 18, 2011 at 12:05 PM, Ryan Kohl <ryanckohl@gmail.com> wrote:
>
> Michael,
>>   You're primarily suggesting that Individuals be assigned meaningless
>> URIs, leaving the URIs for Classes and Properties meaningful, right?
>>
>
> No, I'm suggesting that all URIs use meaningless names. Classes and
> property names change too.
>
>
>> Otherwise, writing and maintaining SPARQL queries would look like an
>> exercise in assembler :)
>> -Ryan
>>
>>
> This is a a limitation with current tools. Alan Ruttenberg bit the bullet
> because the issue for them was too important. They found ways to get around
> the SPARQL issue you correctly raise.
>
> Michael
>
> On Wed, May 18, 2011 at 12:05 PM, Ryan Kohl <ryanckohl@gmail.com> wrote:
>
>> 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
>>>
>>>
>>
>
>
> --
> Michael Uschold, PhD
>    Senior Ontology Consultant, Semantic Arts
>    LinkedIn: http://tr.im/limfu
>    Skype, Twitter: UscholdM
>
>