Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[protege-discussion] IRI uniqueification ideas

Timothy Redmond tredmond at stanford.edu
Fri Nov 9 01:56:53 PST 2012


Yes - you have pretty much given the argument.  There are a number of 
ontologies that use numeric ids and have their human readable label 
given by some annotation property (often rdfs:label) value for these 
types of reasons.

-Timothy

On 11/08/2012 08:33 PM, Jim Tivy wrote:
>
> *Hi Tim*
>
> **
>
> *That makes sense.*
>
> *For individuals, is the word on the street to avoid IRIs with 
> embedded names and other possibly changing semantic information.  For 
> example, with a name you may find it is misspelled or not the complete 
> name or not unique.  If it is baked into the URI then any changes to 
> the IRI would cause necessary changes to assertions and other things 
> that refer to the individual IRI -- a nightmare.  And deleting the 
> individual causes it's death and break the integrity of any existing 
> assertions.*
>
> **
>
> *Jim*
>
> **
>
> *From:*protege-discussion-bounces at lists.stanford.edu 
> [mailto:protege-discussion-bounces at lists.stanford.edu] *On Behalf Of 
> *Timothy Redmond
> *Sent:* November-08-12 7:32 PM
> *To:* protege-discussion at lists.stanford.edu
> *Subject:* Re: [protege-discussion] IRI uniqueification ideas
>
>
> The usual technique that moves in this direction is to use numeric 
> ids.  An example of such an id is:
>
>                   http://purl.org/obo/owl/APO#APO_0000018
>
>
> and the idea is that the next id will be #19, etc.  These ids are not 
> guaranteed to be unique and their non-uniqueness creates a host of 
> problems.   I think that this format is popular because the ids are 
> somewhat more memorable than unique ids would be.
>
> On the other hand, if you want your ids to be truly unique there is a 
> standard for this and there is an associated java implementation [1].  
> Protege supports a method for generating the ids of new entities based 
> on such unique identifiers.
>
> -Timothy
>
>
> [1]http://docs.oracle.com/javase/1.5.0/docs/api/java/util/UUID.html
>
>
> On 11/08/2012 05:26 PM, Jim Tivy wrote:
>
>     Hello
>
>     This is not a direct Protege question but involves IRIs. I have
>     alot of individual documents that I wish to track as Individuals
>     in OWL.  At first I thought I could generate unique IRIs with
>     meaningful names embedded in the IRI.  Now I am thinking I want to
>     generate unique numbers programmatically to accomplish the need
>     for unique IRIs and to retain the ability to change the name of
>     the Individual without deleting and adding it again. There is  GUI
>     to add these individuals so I can generate a next integer Id in
>     the GUI code.
>
>     I was curious, however, what people on this group consider best
>     practice for this problem of uniqifying IRIs and avoiding the
>     embedding of possibly changing semantic information in those IRIs.
>
>     All the examples seem to show IRIs with cute names, like .../John
>     and ../Mary.  My individuals will also have Name and Description
>     properties, so I will recognize them in the GUI by their name and
>     description properties.
>
>     cheers
>
>     Jim
>
>
>
>
>     _______________________________________________
>
>     protege-discussion mailing list
>
>     protege-discussion at lists.stanford.edu  <mailto:protege-discussion at lists.stanford.edu>
>
>     https://mailman.stanford.edu/mailman/listinfo/protege-discussion
>
>       
>
>     Instructions for unsubscribing:http://protege.stanford.edu/doc/faq.html#01a.03
>
>
>
> _______________________________________________
> protege-discussion mailing list
> protege-discussion at lists.stanford.edu
> https://mailman.stanford.edu/mailman/listinfo/protege-discussion
>
> Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/protege-discussion/attachments/20121109/6b3cf399/attachment.html>


More information about the protege-discussion mailing list