[Obi-instrument-branch] MSI NMR and Chromatography terms for OBI
Daniel Schober
I have added around 150 device terms from the MSI NMR and Chromatography
CVs into the instrument branch. Find the list of terms in the attachment.
I used the following namespaces:
http://msi-ontology.sourceforge.net/ontology/NMR.owl#
http://msi-ontology.sourceforge.net/ontology/CHROM.owl#
I have left a few Helper classes in the file for now, but we can
certainly remove them after discussion.
I am away next Tuesday, but feel free to have a peek and comment.
Best,
Daniel Schober
--
__________________________________________________________________________________________
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/
Melanie Courtot
I just had a look at the imported terms and have a few comments:
- regarding namespaces: these will be updated to OBI during the next release process. So for example <owl:Class rdf:about="http://msi-ontology.sourceforge.net/ontology/CHROM.owl#msi_01238"> will become <owl:Class rdf:about="http://purl.obofoundry.org/obo/OBI_xxxxxxx">. If this is not the desired behavior these terms should be imported using the MIREOT system and placed into external.owl and externalDerived.owl
- regarding metadata: if we look for example at _NMR device, all the metadata fields are there but half of them are empty. Some I guess on purpose (editor_note and alternative_term), but for example there is no definition source. I would suggest to not add empty annotation fields to the terms if possible.
- I don't remember how we decided to deal with the fact of asserting classes under the define class "device". This still throws a warning during release process, and if we are adding more classes we might want to address this. Maybe we could add a restriction has_function to these classes?
Thanks for dealing with the mass import Daniel.
I won't be able to attend instrument calls before the 18th of November.
Cheers,
Melanie
Dear Instrumenteers,
I have added around 150 device terms from the MSI NMR and Chromatography CVs into the instrument branch. Find the list of terms in the attachment.
I used the following namespaces:
http://msi-ontology.sourceforge.net/ontology/NMR.owl#
http://msi-ontology.sourceforge.net/ontology/CHROM.owl#
I have left a few Helper classes in the file for now, but we can certainly remove them after discussion.
I am away next Tuesday, but feel free to have a peek and comment.
Best,
Daniel Schober
--
__________________________________________________________________________________________
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)
frank gibson
I have had a quick peak as suggested :) There are a few dodgy
assertions there for example "a chart recorder is a chromatography,
device" ? Infact if you really need the term chromatography_device, it
may be suited to defined classes described something like:
chromatography_device = device utilized in a chromatography process
more comments below
On Thu, Oct 23, 2008 at 7:31 PM, Melanie Courtot <mcou...@bccrc.ca> wrote:
> Hi,
>
> I just had a look at the imported terms and have a few comments:
>
> - regarding namespaces: these will be updated to OBI during the next release
> process. So for example <owl:Class
> rdf:about="http://msi-ontology.sourceforge.net/ontology/CHROM.owl#msi_01238">
> will become <owl:Class
> rdf:about="http://purl.obofoundry.org/obo/OBI_xxxxxxx">. If this is not the
> desired behavior these terms should be imported using the MIREOT system and
> placed into external.owl and externalDerived.owl
>
> - regarding metadata: if we look for example at _NMR device, all the
> metadata fields are there but half of them are empty. Some I guess on
> purpose (editor_note and alternative_term), but for example there is no
> definition source. I would suggest to not add empty annotation fields to the
> terms if possible.
>
> - I don't remember how we decided to deal with the fact of asserting classes
> under the define class "device". This still throws a warning during release
> process, and if we are adding more classes we might want to address this.
> Maybe we could add a restriction has_function to these classes?
So really the only justification of having the class device sit where
it is, is multi user management. It stops device terms getting mixed
in with other materials. Ideally it should not be there - and yes you
are correct everything we call a device should have a function
restriction. If you can handle a flatter list under material, I have
no objections :)
>
> Thanks for dealing with the mass import Daniel.
Yes thanks
> I won't be able to attend instrument calls before the 18th of November.
Maybe we should revise are schedule and update the calendar - Daniel
you indicated you would not be here next week, are there any more
calls you cant make?
Frank
>
> Cheers,
> Melanie
>
> On 23-Oct-08, at 7:13 AM, Daniel Schober wrote:
>
> Dear Instrumenteers,
> I have added around 150 device terms from the MSI NMR and Chromatography CVs
> into the instrument branch. Find the list of terms in the attachment.
> I used the following namespaces:
> http://msi-ontology.sourceforge.net/ontology/NMR.owl#
> http://msi-ontology.sourceforge.net/ontology/CHROM.owl#
> I have left a few Helper classes in the file for now, but we can certainly
> remove them after discussion.
> I am away next Tuesday, but feel free to have a peek and comment.
> Best,
> Daniel Schober
>
> --
> __________________________________________________________________________________________
>
> 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)
>
> ---
> Mélanie Courtot
> TFL- BCCRC
> 675 West 10th Avenue
> Vancouver, BC
> V5Z 1L3, Canada
>
>
>
>
> -------------------------------------------------------------------------
> 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
>
>
--
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
-------------------------------------------------------------------------
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
frank gibson
I have just noticed you also managed to assert classes under the
defined class instrument :(
Frank
>> Dear Instrumenteers,
>> I have added around 150 device terms from the MSI NMR and Chromatography CVs
>> into the instrument branch. Find the list of terms in the attachment.
>> I used the following namespaces:
>> http://msi-ontology.sourceforge.net/ontology/NMR.owl#
>> http://msi-ontology.sourceforge.net/ontology/CHROM.owl#
>> I have left a few Helper classes in the file for now, but we can certainly
>> remove them after discussion.
>> I am away next Tuesday, but feel free to have a peek and comment.
>> Best,
>> Daniel Schober
>>
>> --
>> __________________________________________________________________________________________
>>
>> 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)
>>
frank gibson
Frank
>> Dear Instrumenteers,
>> I have added around 150 device terms from the MSI NMR and Chromatography CVs
>> into the instrument branch. Find the list of terms in the attachment.
>> I used the following namespaces:
>> http://msi-ontology.sourceforge.net/ontology/NMR.owl#
>> http://msi-ontology.sourceforge.net/ontology/CHROM.owl#
>> I have left a few Helper classes in the file for now, but we can certainly
>> remove them after discussion.
>> I am away next Tuesday, but feel free to have a peek and comment.
>> Best,
>> Daniel Schober
>>
>> --
>> __________________________________________________________________________________________
>>
>> 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)
>>
Daniel Schober
I have assigned the primitive MSI devices under OBI device (defined class) due to practical reasons and I don't want to be forced to assign axioms to all device-subclasses for the moment. This can be done later anyway. I can't see what would hinder us to assign single parenthood of primitive classes under defined classes when these assertions are trivial; and in fact that is what is done in other branches too.
I assume as long as the asserted (single-parent) is_a hierarchy is correct, we should not run into problems. The 'untangling' principles only state you should not assert multiple parenthood (which we don't). If we would run into issues the reasoner would make us aware anyway.
Regarding a general OBI policy, I could only find vague statements at https://wiki.cbil.upenn.edu/obiwiki/index.php/DefinedClasses
The policies discussed there are to
1) allow defined classes only under root
2) allow no explicit class assertions under defined classes
but I miss discussions on the justifications for these.
By the way, at the moment pellet reclassifies 'chromatography device' as an 'instrument' solely because we asserted it under a defined class ('device'). Its the is_manufactured_by and is_output_of restrictions that are inherited form 'device' onto 'chromatography device' and make the reasoner aware that it is an instrument (the latter two are N&S for 'instrument'.
On a side note the present restrictions for 'chromatography device' as they stand at the moment are not sufficient. The same restrictions would apply e.g. for an 'electrophoresis apparatus'. This is a good example of a correct and desired classification that is not a proof for correct class definitions ;-)
Cheers, Daniel.
PS: What worries me is that of the over 10000 mails on the protege-owl list only 1 email mentions normalization/untangling :-[ .
Cambridge CB10 1SD, UK Room: A3-141 (extension building) Project page: www.ebi.ac.uk/net-project
Alan Ruttenberg
> Hi Frank,
> I have assigned the primitive MSI devices under OBI device (defined class)
> due to practical reasons and I don't want to be forced to assign axioms to
> all device-subclasses for the moment. This can be done later anyway. I can't
> see what would hinder us to assign single parenthood of primitive classes
> under defined classes when these assertions are trivial; and in fact that is
> what is done in other branches too.
The problems have been noted with the other branches as well. That
they haven't been fixed is a problem.
> I assume as long as the asserted (single-parent) is_a hierarchy is correct,
> we should not run into problems.
Suppose I have a class A == B U C
Now assert D < A
We have now a situation where one can not look at the classified class
tree and easily see which classes' definitions one must read in order
to understand D (namely one must look at B and C)
This is exactly the situation that one tries to avoid by using single
inheritance class tree.
> The 'untangling' principles only state you
> should not assert multiple parenthood (which we don't). If we would run
> into issues the reasoner would make us aware anyway.
Suppose D is primitive and we say that it is cats. Suppose B are fish
and C are dogs. There is a problem here, and the reasoner will not
tell you about it.
> Regarding a general OBI policy, I could only find vague statements at
> https://wiki.cbil.upenn.edu/obiwiki/index.php/DefinedClasses
I believe the write up and annotations to discussions are anything but vague.
> The policies discussed there are to
> 1) allow defined classes only under root
> 2) allow no explicit class assertions under defined classes
> but I miss discussions on the justifications for these.
Obviously the page was clear enough for you to discern the policy ;-)
I believe the problems are documented in the discussions however
hopefully the above will make things clearer.
> By the way, at the moment pellet reclassifies 'chromatography device' as an
> 'instrument' solely because we asserted it under a defined class ('device').
> Its the is_manufactured_by and is_output_of restrictions that are
> inherited form 'device' onto 'chromatography device' and make the reasoner
> aware that it is an instrument (the latter two are N&S for 'instrument'.
> On a side note the present restrictions for 'chromatography device' as they
> stand at the moment are not sufficient. The same restrictions would apply
> e.g. for an 'electrophoresis apparatus'. This is a good example of a correct
> and desired classification that is not a proof for correct class definitions
> ;-)
> Cheers, Daniel.
>
>
> PS: What worries me is that of the over 10000 mails on the protege-owl list
> only 1 email mentions normalization/untangling :-[ .
Why does this worry you?
-Alan
Daniel Schober
Try it out: Move chromatography device under material entity and do a pellet classification. Thereby you still retain the measuring_function or synthesizing_function restrictions, and only loose the manufactured by restrictions from device.
You will see that the chromatography device will not be classified under instruments any longer.
All N&S instrument conditions need to be fulfilled, but then are not (loss of is_manufactured_by and is_output_of restrictions that were previously inherited form 'device' onto 'chromatography device').
Regarding the binning under defined classes I had a chat with Frank that might be of interest to the general instrument branch as well:
[16:51:45] Frank Gibson says: is moving the classes under instrument to be under device acceptable?
[16:52:35] daniel_stoertebeker says: no strong feelings about this... but what is the advantage?
[16:53:39] Frank Gibson says: well, we agreed that an instrument was any device that had a measure or a synthesizing function
[16:54:06] Frank Gibson says: an acquisition computer doesn' t have either
[17:09:44] daniel_stoertebeker says: This hinds to the fact that the N&S conditions are not correct/complete. At the current OBI state I would tend to rely on human judgment before altering the asserted hierarchy . So why don't we just add the new restrictions of this acquisition computer that we have not captured by the present instrument restrictions? I would think that even a data collection is a measurement function, so it would still be correct under instrument.
[17:11:43] Frank Gibson says: I would prefer if they were just moved under device for now - adding appropriate function will get them inferred under instrument - if we also want to expand what instrument means that is fine - but we need to be careful it does mean something different from device
[17:30:28] daniel_stoertebeker says: how about instrument has_parameter parameter valueRole. This is what an instrument has and a device not.
[17:31:57] daniel_stoertebeker says: Why moving them to a more unspecific class and hereby getting also rid of examples for instrument class justification. We can add further restrictions anytime later.
Cheers, Daniel.
frank gibson wrote:
Hi Daniel, On Mon, Nov 3, 2008 at 3:50 PM, Daniel Schober <sch...@ebi.ac.uk> wrote:
Hi Frank, I have assigned the primitive MSI devices under OBI device (defined class) due to practical reasons and I don't want to be forced to assign axioms to all device-subclasses for the moment.
That's fine - only because we are using the defined class device as a branch separator - so it is easy to identify device terms from material terms - this is the only exception. However, you also asserted classes under the class instrument - which is not OK This can be done later anyway. I can'tsee what would hinder us to assign single parenthood of primitive classes under defined classes when these assertions are trivial; and in fact that is what is done in other branches too. I assume as long as the asserted (single-parent) is_a hierarchy is correct, we should not run into problems. The 'untangling' principles only state you should not assert multiple parenthood (which we don't). If we would run into issues the reasoner would make us aware anyway. Regarding a general OBI policy, I could only find vague statements at https://wiki.cbil.upenn.edu/obiwiki/index.php/DefinedClasses
The policies discussed there are to 1) allow defined classes only under root 2) allow no explicit class assertions under defined classes but I miss discussions on the justifications for these.
I have commented on this before, the summary of my comments are near the end of the wiki page. I will give you the response that I get from Alan when I think certain policies are wrong - "Its been decided."
By the way, at the moment pellet reclassifies 'chromatography device' as an 'instrument' solely because we asserted it under a defined class ('device'). Its the is_manufactured_by and is_output_of restrictions that are inherited form 'device' onto 'chromatography device' and make the reasoner aware that it is an instrument (the latter two are N&S for 'instrument'.
This is incorrect. It is having the function of measuring_function or synthesizing_function that allows classes to be inferred as instruments. The restrictions is_manufactured_by and is_output_of allow them to be inferred artifact_objects
On a side note the present restrictions for 'chromatography device' as they stand at the moment are not sufficient. The same restrictions would apply e.g. for an 'electrophoresis apparatus'. This is a good example of a correct and desired classification that is not a proof for correct class definitions ;-)
Yes that is correct, they are only neccessary conditions. I think we could probably say that for alot of other instruments as well - Its all we know at the moment :) and they still are true statements. Moving the NMR classes currently asserted under instrument to be under device, would be a step forward in the right direction.... FrankCheers, Daniel. PS: What worries me is that of the over 10000 mails on the protege-owl list only 1 email mentions normalization/untangling :-[ . frank gibson wrote: Hi, I have just noticed you also managed to assert classes under the defined class instrument :( Frank On Fri, Oct 24, 2008 at 3:31 PM, frank gibson <Frank....@ncl.ac.uk>
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/
------------------------------------------------------------------------- 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
-- __________________________________________________________________________________________ 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
Daniel Schober
Try it out: Move chromatography device under material entity and do a pellet classification. Thereby you still retain the measuring_function or synthesizing_function restrictions, and only loose the manufactured by restrictions from device.
You will see that the chromatography device will not be classified under instruments any longer.
All N&S instrument conditions need to be fulfilled, but then are not (loss of is_manufactured_by and is_output_of restrictions that were previously inherited form 'device' onto 'chromatography device').
Cheers, Daniel. PS: What worries me is that of the over 10000 mails on the protege-owl list only 1 email mentions normalization/untangling :-[ . frank gibson wrote: Hi, I have just noticed you also managed to assert classes under the defined class instrument :( Frank On Fri, Oct 24, 2008 at 3:31 PM, frank gibson <Frank....@ncl.ac.uk>
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/
------------------------------------------------------------------------- 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
-- __________________________________________________________________________________________ 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
frank gibson
Frank
> 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/
>
>
frank gibson
On Mon, Nov 3, 2008 at 5:50 PM, Daniel Schober <sch...@ebi.ac.uk> wrote:
> No, Frank it is not incorrect.
> Try it out: Move chromatography device under material entity and do a pellet
> classification. Thereby you still retain the measuring_function or
> synthesizing_function restrictions, and only loose the manufactured by
> restrictions from device.
> You will see that the chromatography device will not be classified under
> instruments any longer.
> All N&S instrument conditions need to be fulfilled, but then are not (loss
> of is_manufactured_by and is_output_of restrictions that were previously
> inherited form 'device' onto 'chromatography device').
Yes, of course. I had assumed you were asking what made a device an
instrument, rather than what makes a material an instrument.
>
> Regarding the binning under defined classes I had a chat with Frank that
> might be of interest to the general instrument branch as well:
>
> [16:51:45] Frank Gibson says: is moving the classes under instrument to be
> under device acceptable?
> [16:52:35] daniel_stoertebeker says: no strong feelings about this... but
> what is the advantage?
> [16:53:39] Frank Gibson says: well, we agreed that an instrument was any
> device that had a measure or a synthesizing function
> [16:54:06] Frank Gibson says: an acquisition computer doesn' t have either
> [17:09:44] daniel_stoertebeker says: This hinds to the fact that the N&S
> conditions are not correct/complete. At the current OBI state I would tend
> to rely on human judgment before altering the asserted hierarchy . So why
> don't we just add the new restrictions of this acquisition computer that we
> have not captured by the present instrument restrictions? I would think that
> even a data collection is a measurement function, so it would still be
> correct under instrument.
> [17:11:43] Frank Gibson says: I would prefer if they were just moved under
> device for now - adding appropriate function will get them inferred under
> instrument - if we also want to expand what instrument means that is fine -
> but we need to be careful it does mean something different from device
> [17:30:28] daniel_stoertebeker says: how about instrument has_parameter
> parameter valueRole. This is what an instrument has and a device not.
> [17:31:57] daniel_stoertebeker says: Why moving them to a more unspecific
> class and hereby getting also rid of examples for instrument class
> justification. We can add further restrictions anytime later.
We want to be in a position where the reasoner deals with the
hierarchy as far as possible rather than human assertion. The way the
device branch exists at the moment is that everything we believe to be
a device is asserted under the class device. From this knowledge the
reasoner infers which of these are instruments. If you believe there
are devices that you believe to be instruments and they are not
inferred as such, then I would reccommend the following step-by-step
process.
1. Remove the classes asserted under instrument and assert them under
device instead.
2. State everything you know to be true (functions/parts etc)
3. Classify the taxonomy of the ontology
4. See which devices are classified under instrument - if you are
happy then that is the end - if not move next point.
5. Identify which piece of knowledge (restriction) is required on
instrument to allow you to infer the devices you think are
instruments.
6. Classify to determine if this has worked.
7. Repeat until you are satisfied (with the inference, that is)
8. Also be aware of devices that may get classified as instruments
that you believe not to be instruments and adjust accordingly
I hope this helps
Cheers
Frank
>
> Cheers, Daniel.
>
>
>
>
> frank gibson wrote:
>