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 <usch...@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.h...@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.h...@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: h...@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 > >
