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

Alan Ruttenberg alanruttenberg at gmail.com
Thu Dec 24 07:37:40 PST 2009


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
>
>



More information about the bioontology-support mailing list