[Obi-instrument-branch] branch calls - mini use case
Melanie Courtot
Shall we try and resume our branch call next week?
I would like to go through the branch and clean up for example editor
notes that have been addressed (cf email about release on obi-dev)
I would also like to propose the mini use case for our branch (cf Bjoern's
email on obi-dev), maybe along the lines of "a flow cytometer manufactured
by BD is used to count the number of cells positive for CD8"
(e.g.
http://www.scq.ubc.ca/flow-cytometry-a-technology-to-count-and-sort-cells/)
Without considering all those details of course, but it would be nice to
start for example by adding the manufacturer and create relations between
instrument and manufacturer, then add the function of the instrument
(links with protocol application branch) and finally links with
Biomaterial to represent the samples.
How does that sound?
Melanie
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Obi-instrument-branch mailing list
Obi-instru...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/obi-instrument-branch
Daniel Schober
Yes, that sounds good lets start the calls next week.
I am also ready to put the nmr and Chrom CV terms into OBI.
I will do this via Jasons Greenbaums xl2owl tool
(http://70.167.3.46/~jgbaum/cgi-bin/xl2owl.cgi ). I will leave the IDs
as they were in the original NMR and Chrom sources for the moment.
I will proceed on a per branch basis and successively lock the branches
which I work on. I will start this process with the instrument branch
first to see how it goes.
Do you want to have a look at the spreadsheet with the terms beforehand ?
Regarding the use case, I agree to start with Flow cytometers cell count
function rather than cell sorting.
I assume we need to come up with relations from device to device part,
device-function, instrument parameter, software, protocol application
and protocol. What I would like to know is how we tackle 'parameters' of
instruments, because I assume the users would be interested to see the
settings of an instrument in a specific protocoll. We don't have
'parameter' itself in OBI right now, but i assume it would be something
as a 'datum' , or the role of a datum ?
We then will also need to resolve the issue of how modeling the parts on
an instrument will actually help us modeling its function and if this is
feasible/realistic (see latest thread ' not completely defined classes'
on this list.
Cheers,
Daniel Schober.
Melanie Courtot wrote:
--
__________________________________________________________________________________________
Dr. Daniel Schober
NET Project - Ontologist
The European Bioinformatics Institute email: sch...@ebi.ac.uk
EMBL Outstation - Hinxton direct: +44 (0)1223 494410
Wellcome Trust Genome Campus fax: +44 (0)1223 494 468
Cambridge CB10 1SD, UK Room: A3-141 (extension building)
Project page: www.ebi.ac.uk/net-project
Personal page: http://www.ebi.ac.uk/Information/Staff/person_maint.php?s_person_id=734
Former home page: http://www.bioinf.mdc-berlin.de/%7Eschober/
Philippe Rocca-Serra
Hello Daniel, OBI developers
In keeping with Daniel question about 'instrument' parameter, maybe we
need to write use case detailing how OBI may be used in replacement of
other resources and we would certainly
for instance PSI-CV has things like:
PSI:1000028: Detector Resolution
I guess that owing to the way OBI is build, PSI:1000028 would be
decomposed (possibly) as
property/quality:resolution /about_of/ instrument:detector /has_role/
parameter_role
we probably have many cases like this: column temperature, scan time,
compound concentration...(well sounds familiar)
and then what ?
Should we store this statement in OBI precomposed terms files for a
series of domain using those 'composition' ?
Obviously, we have the quick term thing, but managing all these
compositions might prove very expensive unless we can demonstrate a
significant gain. At the moment, I have some doubts
Cheers
Philippe
Alan Ruttenberg
Here's my current thought - comments and review solicited:
The general class of setting is something like information that is
about a entity relating to the functioning of the instrument. Settings
are machine "objectives", in that in the normal operation of the
machine is to make the setting obtain, actually.
So, for detector resolution, there is a) a quality of the detector and
b) instrument setting about some detector resolution quality of the
instrument.
Measurements and settings would seem to share important aspects - a
measurement of the thing the setting is about should be approximately
equal, in some sense, to the setting.
However, this connection to measurement does raise an issue of
multiple inheritance - perhaps a conflict between objective and
measurement.
Werner, if you are listening, have you made any progress on "magnitudes"?
-Alan
Melanie Courtot
My comments inline.
> Hello instrumenteers,
> Yes, that sounds good lets start the calls next week.
> I am also ready to put the nmr and Chrom CV terms into OBI.
> I will do this via Jasons Greenbaums xl2owl tool
> (http://70.167.3.46/~jgbaum/cgi-bin/xl2owl.cgi ). I will leave the IDs
> as they were in the original NMR and Chrom sources for the moment.
> I will proceed on a per branch basis and successively lock the branches
> which I work on. I will start this process with the instrument branch
> first to see how it goes.
> Do you want to have a look at the spreadsheet with the terms beforehand ?
>
I completely trust your judgement to import only terms that are
appropriate in the instrument branch, so if you are happy with the list I
would say go ahead.
However if you are touching other branches as well I would maybe send an
email on obi-dev to warn relevant people? For example if you wish to add
information to the Biomaterial file I would be happy to review this with
the Biomaterial branch, as we have been working a lot on the hierarchy of
the branch recently. One option would be for you to send the new OWL file
that you produce and we could test it beforehand?
One remark though: if the terms already have a non-OBI ID, this one will
get overwritten when we are doing the next release, to be replaced by
OBI_xxxxxxx. If it is wished to keep a trace of the original ID, you may
consider adding an editor_note or a definition_source with this old ID.
> Regarding the use case, I agree to start with Flow cytometers cell count
> function rather than cell sorting.
> I assume we need to come up with relations from device to device part,
> device-function, instrument parameter, software, protocol application
> and protocol. What I would like to know is how we tackle 'parameters' of
> instruments, because I assume the users would be interested to see the
> settings of an instrument in a specific protocol. We don't have
> 'parameter' itself in OBI right now, but i assume it would be something
> as a 'datum' , or the role of a datum ?
> We then will also need to resolve the issue of how modeling the parts on
> an instrument will actually help us modeling its function and if this is
> feasible/realistic (see latest thread ' not completely defined classes'
> on this list.
Regarding the use case, I know that there are lots of things to be solved,
for example parameters as you mention. I was hoping to do this on a step
by step basis, starting for example with saying "flow cytometer
has_manufacturer BD" which will already require us to deal with
manufacturer and the manufacturing process, and then add layers of
complexity after each step is completed. We can then address the function
and parts, and later the parameters setting etc.
Does that sound reasonable?
Of course we can start discussing the parameters issue which will not be
trivial: as far as I remember, the idea was using PATO, to say instrument
has_quality voltage which itself has_unit x and has_magnitude y.
The biomaterial branch is working on representing concentration, so that
may help us as well (biomaterial has quality concentration which has unit
x and magnitude y)
Thanks,
Melanie
frank gibson
have proposed to represent a measurement. Is that measurement proposal
written up somewhere or is it still floating around emails?
Typically a setting will have a value, a unit and a _setting_
The setting part will be similar to whatever we use for measurement -
which I can not remember...
Frank
On Wed, Oct 8, 2008 at 4:58 PM, Alan Ruttenberg
<alanrut...@gmail.com> wrote:
> I've been thinking that settings belong in information.
>
> Here's my current thought - comments and review solicited:
>
> The general class of setting is something like information that is
> about a entity relating to the functioning of the instrument. Settings
> are machine "objectives", in that in the normal operation of the
> machine is to make the setting obtain, actually.
>
> So, for detector resolution, there is a) a quality of the detector and
> b) instrument setting about some detector resolution quality of the
> instrument.
>
> Measurements and settings would seem to share important aspects - a
> measurement of the thing the setting is about should be approximately
> equal, in some sense, to the setting.
>
> However, this connection to measurement does raise an issue of
> multiple inheritance - perhaps a conflict between objective and
> measurement.
>
> Werner, if you are listening, have you made any progress on "magnitudes"?
>
> -Alan
>
> On Wed, Oct 8, 2008 at 8:14 AM, Philippe Rocca-Serra <ro...@ebi.ac.uk> wrote:
>>
--
Frank Gibson
Research Associate
Room 2.19, Devonshire Building
School of Computing Science,
Newcastle University,
Newcastle upon Tyne, NE1 7RU
United Kingdom
Telephone: +44-191-246-4933
Fax: +44-191-246-4905
https://homepages.cs.ncl.ac.uk/frank.gibson