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    

[bioontology-support] [Obo-unit] Proposal to change UO to a representation of instances

Trish Whetzel whetzel at stanford.edu
Thu Dec 24 13:55:13 PST 2009


Yes, that is a known issue. Just to clarify, is presenting the value  
for the id field as OBI_000046, without the prefix ok?

Trish


On Dec 24, 2009, at 7:45 AM, Alan Ruttenberg wrote:

> I miswrote "obi:" instead of "obo:". Substance of the comment still  
> stands.
> -Alan
>
> On Thu, Dec 24, 2009 at 10:37 AM, Alan Ruttenberg
> <alanruttenberg at gmail.com> wrote:
>> Hi Trish,
>>
>> That returns:
>>
>> <success>
>>  <accessedResource>/bioportal/virtual/ontology/1123/ 
>> obo:OBI_0000462</accessedResource>
>>  <accessDate>2009-12-24 07:32:59.258 PST</accessDate>
>>  <data>
>>    <classBean>
>>      <id>obo:OBI_0000462</id>
>>      <fullId>http://purl.obolibrary.org/obo/OBI_0000462</fullId>
>>      <label>Affymetrix</label>
>>      <type>Individual</type>
>>      <relations/>
>>    </classBean>
>>  </data>
>> </success>
>>
>> The ID field should either be removed, or another field in which
>> prefixes are defined be added. A prefix like "obi:" standing in
>> isolation is meaningless, and the string obi:OBI_0000462 similarly  
>> has
>> no meaning (nor should it) in any system that I am aware of.
>>
>>
>> -Alan
>>
>> On Thu, Dec 24, 2009 at 5:23 AM, Trish Whetzel  
>> <whetzel at stanford.edu> wrote:
>>> Regarding access to instance terms via BioPortal web services,  
>>> this is
>>> possible using the Term
>>> services: http://www.bioontology.org/wiki/index.php/BioPortal_REST_services#Term_services 
>>> .
>>> For example, using the service to access a term from the latest  
>>> ontology
>>> version from OBI for the term "Affymetrix" the web service  
>>> signature is:
>>> http://rest.bioontology.org/bioportal/virtual/ontology/1123/obo:OBI_0000462 
>>> .
>>>  There is a tracker item to modify the output of the Term service  
>>> for
>>> Individuals so that more information about the term is returned.  
>>> I'll check
>>> on the timeframe for this when everyone is back from the Winter  
>>> break.
>>> Trish
>>>
>>> On Dec 21, 2009, at 8:27 AM, Alan Ruttenberg wrote:
>>>
>>> On Mon, Dec 21, 2009 at 10:26 AM, Philippe Rocca-Serra <rocca at ebi.ac.uk 
>>> >
>>> wrote:
>>>
>>> On a side note, switching to instances would disrupt access/ 
>>> visibility
>>>
>>> from resource browsers such as NCBO Bioportal or EBI's OLS.
>>>
>>> I have just checked with Bioportal (looking for 'Affymetrix' which  
>>> is
>>>
>>> represented as an instance, or individual, in OBI) .
>>>
>>> Bioportal web interface finds the entry but tells the following:  
>>> "Sorry,
>>>
>>> Affymetrix is not browsable because it is a individual".
>>>
>>> It may be that the web service returns a different message though.
>>>
>>> In our case, this would have a negative impact .
>>>
>>> Our tool, ISAcreator (http://isatab.sourceforge.net/isacreator.html)
>>>
>>> accesses both Bioportal and OLS and allows users to select ontology
>>>
>>> classes (e.g Units from UO) to annotate experiments.
>>>
>>> We can file a feature request to Bioportal in order to gauge how  
>>> long it
>>>
>>> may take before instance terms can served and browsed.
>>>
>>> Yes, I suggest you do. And OLS.
>>> ccing Trish so that it is on her radar.
>>>
>>> -Alan
>>>
>>>
>>>
>>> Cheers
>>>
>>> Philippe
>>>
>>>
>>>
>>> George Gkoutos wrote:
>>>
>>> On 19 Dec 2009, at 00:53, Chris Mungall wrote:
>>>
>>>
>>> On Dec 18, 2009, at 12:20 PM, Alan Ruttenberg wrote:
>>>
>>>
>>> On 12/17/09, Chris Mungall <cjm at berkeleybop.org> wrote:
>>>
>>> On Dec 17, 2009, at 3:55 AM, Robert Hoehndorf wrote:
>>>
>>>
>>>  CM> I'm neutral, I don't use UO in any application. I'm not
>>>
>>>  CM> actually sure if there are any users of UO out there?
>>>
>>> Me, potentially, though I am not sure what you consider to be a
>>>
>>> "use". Formalization of categories in other ontologies using the
>>>
>>> unit-categories would be my goal, not sure if this is considered
>>>
>>> "use".
>>>
>>> potential use is different from current actual use. I was attempting
>>>
>>> to solicit feedback from actual users to make sure anything we do
>>>
>>> doesn't break systems in production. For example, it's typical
>>>
>>> practice to announce obsoletions a few weeks in advance to give
>>>
>>> people
>>>
>>> time to prepare. If you're a potential user then your fairly
>>>
>>> insulated
>>>
>>> from the damaging effects of any changes.
>>>
>>>
>>> As it happens, I remember UO *is* in active use by one fairly large
>>>
>>> and important project I'm involved with, so we should proceed
>>>
>>> carefully with any changes. If we do switch to instances we may have
>>>
>>> to have some hack whereby the current .obo file keeps using classes,
>>>
>>> which would be an unfortunate mismatch.
>>>
>>> Could we get some examples of use in this project?
>>>
>>> It *would* be an unfortunate mismatch. I might suggest that OBO edit
>>>
>>> needs to be adjusted so it can handle instances if it is to remain a
>>>
>>> viable option for use for developing foundry ontologies.
>>>
>>> I don't like the idea of keeping something a certain way just  
>>> because
>>>
>>> the tooling isn't up to snuff. It's reasonable to have a transition
>>>
>>> period.
>>>
>>> I agree that it's an unacceptable reason for keeping the ontology a
>>>
>>> certain way and I'm happy to switch to using Protege to edit UO. My
>>>
>>> point was that there are downstream users who may be affected by
>>>
>>> switching the underlying representation. We could insulate them by
>>>
>>> having a system in place whereby the .obo file that people are using
>>>
>>> remains fundamentally unchanged. I don't think this is the best
>>>
>>> solution, I'm just trying to lay out some of the options and costs.
>>>
>>> Another option is the transition period - we announce that the
>>>
>>> representation will change to instances and give people a reasonably
>>>
>>> amount of time to insulate themselves from any changes. I presume  
>>> you
>>>
>>> want to go with the less radical solution on overriding OBO policy  
>>> and
>>>
>>> not obsoleting existing IDs despite the fact that we are changing  
>>> the
>>>
>>> meaning. I don't think this is a good way to earning popularity,
>>>
>>> breaking production systems for what people perceive to be  
>>> meaningless
>>>
>>> philosophical distinctions, but if this is required for  
>>> compatibility
>>>
>>> with OBI, then we should do it.
>>>
>>> Personally I'm not enthusiastic about the change - at the PATO  
>>> meeting
>>>
>>> in Cambridge in 2006 we decided the units were classes, so for
>>>
>>> example, "kg" is instantiated whenever there is a 1-kg weighing
>>>
>>> entity. This seems at least to me to be simple, intuitive,
>>>
>>> unproblematic and avoids the extra indirection of information  
>>> content
>>>
>>> entities.
>>>
>>>
>>>
>>> that was my understanding as well. We should obviously try to
>>>
>>> accommodate the usage of UO within the OBI community and I am  
>>> happy to
>>>
>>> edit in Protege although I wonder whether we could have a conversion
>>>
>>> script or something like that. In any case, I think we should not be
>>>
>>> obsoleting existing IDs.
>>>
>>>
>>> My current feeling is that if IAO/OBI wish to use unit instances the
>>>
>>> safest thing may be to use different IDs - perhaps we could have a
>>>
>>> system whereby the numeric local part of the ID is synchronized.
>>>
>>> Useless. The numeric local part has no status in any of our systems
>>>
>>> and I would chastise a programmer that assumed it did.
>>>
>>> I was just suggesting some kind of skolemization mechanism to auto-
>>>
>>> generate the ID and having the relationship formally captured.
>>>
>>>
>>> If we go this route we will have duplicated effort, IMO. I don't  
>>> want
>>>
>>> to see that happen cause I think that fundamentally the unit
>>>
>>> representatins are used in the same way.
>>>
>>> I agree it's not perfect but it seems the best solution to me.
>>>
>>>
>>> -Alan
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> This SF.Net email is sponsored by the Verizon Developer Community
>>>
>>> Take advantage of Verizon's best-in-class app development support
>>>
>>> A streamlined, 14 day to market process makes app distribution fast
>>>
>>> and easy
>>>
>>> Join now and get one step closer to millions of Verizon customers
>>>
>>> http://p.sf.net/sfu/verizon-dev2dev
>>>
>>> _______________________________________________
>>>
>>> Obo-unit mailing list
>>>
>>> Obo-unit at lists.sourceforge.net
>>>
>>> https://lists.sourceforge.net/lists/listinfo/obo-unit
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> This SF.Net email is sponsored by the Verizon Developer Community
>>>
>>> Take advantage of Verizon's best-in-class app development support
>>>
>>> A streamlined, 14 day to market process makes app distribution  
>>> fast and easy
>>>
>>> Join now and get one step closer to millions of Verizon customers
>>>
>>> http://p.sf.net/sfu/verizon-dev2dev
>>>
>>> _______________________________________________
>>>
>>> Obo-unit mailing list
>>>
>>> Obo-unit at lists.sourceforge.net
>>>
>>> https://lists.sourceforge.net/lists/listinfo/obo-unit
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> This SF.Net email is sponsored by the Verizon Developer Community
>>>
>>> Take advantage of Verizon's best-in-class app development support
>>>
>>> A streamlined, 14 day to market process makes app distribution  
>>> fast and easy
>>>
>>> Join now and get one step closer to millions of Verizon customers
>>>
>>> http://p.sf.net/sfu/verizon-dev2dev
>>>
>>> _______________________________________________
>>>
>>> Obo-unit mailing list
>>>
>>> Obo-unit at lists.sourceforge.net
>>>
>>> https://lists.sourceforge.net/lists/listinfo/obo-unit
>>>
>>>
>>> Trish Whetzel, PhD
>>> Outreach Coordinator
>>> The National Center for Biomedical Ontology
>>> Ph: 650-721-2378
>>> whetzel at stanford.edu
>>> http://www.bioontology.org
>>>
>>>
>>

Trish Whetzel, PhD
Outreach Coordinator
The National Center for Biomedical Ontology
Ph: 650-721-2378
whetzel at stanford.edu
http://www.bioontology.org



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/bioontology-support/attachments/20091224/7cfc8d96/attachment.html>


More information about the bioontology-support mailing list