Proposal to add a property to include an alphanumeric term identifier
Trish Whetzel
I have received a few requests to add a property to BRO terms to include a term identifier that is alphanumerical. The motivation for these requests is so that others that use BRO can more easily track the terms. While the URI does serve as an identifier, since we are currently using the human readable term name (plus underscores) as the URI, these values can change over time and users of BRO would prefer to track the terms directly with an immutable identifier rather than navigating through a deprecated term to find it's replacement. Are there any objections to adding this property?
Trish
Melanie Courtot
Did you consider using the alphanumerical IDs directly as URIs? This may be a bit more work right now, but may ease maintaining long term, especially if you already anticipate label changes.
If you were to choose this, you could for example add the current human label based URI as a property for backward compatibility if that would make it easier to transition.
As you know, we faced similar issues and documented an ID policy for the OBO Foundry, available at http://www.obofoundry.org/id-policy.shtml - in case it may be helpful.
Cheers,
Melanie
---
Mélanie Courtot
MSFHR/PCIRN trainee, TFL- BCCRC
675 West 10th Avenue
Vancouver, BC
V5Z 1L3, Canada
anita bandrowski
I have no objection, rather I am a vehement supporter.
However as we embark on this , should these classes be submitted to OBI and should the ids be brought back from OBI?
It seems like this would make sense as we then have less mapping to do in the future.
Regards,
anita
Anita Bandrowski, Ph.D.
NIF Project Lead
UCSD 858-822-3629
http://neuinfo.org
9500 Gillman Dr.#0446
la Jolla, CA 92093-0446
Trish Whetzel
So it sounds like there is agreement to add alphanumeric identifiers to BRO terms. However, whether to add these as the URI or into another property is not clear. Can some BRO folks on the list comment on their preferences on swapping out the human readable URIs for alphanumeric identifiers and whether they will be able to update existing code as needed?
Thanks,
Trish
Alan Ruttenberg
> Thanks Melanie. We have discussed swapping out the human readable URIs with
> alphanumeric identifiers, however there is some concern about breaking
> existing code. For long-term maintenance of BRO, adding the alphanumeric
> identifier as the URI would be easier since based on past work with OBI and
> the Protege team, there are built-in mechanisms in Protege to automatically
> generate these alphanumeric identifiers when they are the URI for the term.
> Adding in the current human label based URI as a property for backward
> compatibility sounds like a good way to ease the transition.
>
> So it sounds like there is agreement to add alphanumeric identifiers to BRO
> terms. However, whether to add these as the URI or into another property is
> not clear. Can some BRO folks on the list comment on their preferences on
> swapping out the human readable URIs for alphanumeric identifiers and
> whether they will be able to update existing code as needed?
Not a BRO developer, but I will offer that best practice would be to
put the part that doesn't ever change in the URI and the thing that
might change into the label - see http://www.w3.org/Provider/Style/URI
by Tim Berners-Lee, published back in 1998.
Regards,
Alan
Timothy Cook
<alanrut...@gmail.com> wrote:
> Not a BRO developer, but I will offer that best practice would be to
> put the part that doesn't ever change in the URI and the thing that
> might change into the label - see http://www.w3.org/Provider/Style/URI
> by Tim Berners-Lee, published back in 1998.
>
Not a BRO developer either. But I will suggest generating a UUID for
each entry to be certain that it is unique and never changes.
http://en.wikipedia.org/wiki/Universally_unique_identifier
Cheers,
Tim
--
================
Timothy Cook, MSc
Project Lead - Multi-Level Healthcare Information Modeling
http://www.mlhim.org
LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook
Skype ID == timothy.cook
Academic.Edu Profile: http://uff.academia.edu/TimothyCook
You may get my Public GPG key from popular keyservers or
from this link http://timothywayne.cook.googlepages.com/home
Melanie Courtot
In to context of OBO Foundry we have been using the policy documented at http://www.obofoundry.org/id-policy.shtml. We use a unique IDSPACE per resource (e.g., OBI for Ontology for Biomedical Investigations), and append a unique numerical identifier, resulting in term IDs such as OBI_1234567. Our URIs are PURL based, such as http://purl.obolibrary.org/obo/OBI_1234567. We found that this system gave us the best of both world: by relying on the combination of (i) IDSPACE and numerical IDs and (ii) PURLs we get unique and stable identifiers, and having a common URI format allows us to build common tools to assign/check IDs automatically [1] or for dereferencing [2]; which wouldn't be easily feasible with UUIDs.
Do you think there would be extra benefits by choosing UUIDs?
Cheers,
Melanie
[1] http://obi.svn.sourceforge.net/viewvc/obi/trunk/src/tools/build/new-newids.lisp
[2] http://purl.obolibrary.org/obo/OBI_0000070
---
Timothy Cook
Apologies for taking this long to reply.
No I do not see a benefit to using UUIDs instead. It seems you have a
very workable system of assignment and since it is a centrally located
service no need to change.
Cheers,
Tim