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 02:23:10 PST 2009


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



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


More information about the bioontology-support mailing list