[Obi-instrument-branch] core terms - meeting
Melanie Courtot
We reviewed core terms yesterday during the dev call, in preparation
for the meeting. The instrument branch is behind, in the sense that we
didn't solve issues presented by those.
I don't know who will do the talk in Vancouver, but in the current
situation I don;t have much more to say than "we know we have issues
and will work on them" which doesn't match the objective of core terms
ready by the workshop.
Suggestions?
Melanie
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Obi-instrument-branch mailing list
Obi-instru...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/obi-instrument-branch
Frank Gibson
I am not sure there are really any issues. We have a good definition
for a device, we have decided that and instrument is any device that
produces data, and a platform is a combination of multiple devices and
software. The key issues that are stopping us from progressing, which
are cross branch issues and are scheduled for discussion at the
meeting are
1) the (MSI) namespace issue
2) The device_setting classes and relations
I can do the presentation of the core representational units
Frank
--
Frank Gibson, PhD
http://peanutbutter.wordpress.com/
Ryan Brinkman
Melanie Courtot
under our SVN yesterday, and the MSI terms have now been assigned an
OBI ID, as has been approved by the coordinators.
The namespace discussion during workshop should allow us to
officialize the formalization of the policy that Susanna and Philippe
are preparing.
Other issues mentioned during dev call included how to proceed with
the function/process branches, formalizing difference between
instrument/device (in good way), and restriction on platform (is a
platform always 2 or more devices/instruments for example)
Thanks,
Melanie
---
Mélanie Courtot
TFL- BCCRC
675 West 10th Avenue
Vancouver, BC
V5Z 1L3, Canada
Frank Gibson
> FYI - as I did tell Frank this morning, I did commit the newids files under
> our SVN yesterday, and the MSI terms have now been assigned an OBI ID, as
> has been approved by the coordinators.
>
> The namespace discussion during workshop should allow us to officialize the
> formalization of the policy that Susanna and Philippe are preparing.
excellent
> Other issues mentioned during dev call included how to proceed with the
> function/process branches,
This is an outstanding BFO issue, in the sense that do funtions exist,
or are they actually just processes
formalizing difference between instrument/device
> (in good way),
This is closed. An instrument is a device that produces data
and restriction on platform (is a platform always 2 or more
> devices/instruments for example)
this is how it is described in the definition, collection of more that
one devices and software. However the has_part relation is transitive,
meaning you can't add cardinality to it. So this item is also closed.
Lets try and not get hung-up about these classes which are purely used
for classification and lets try and get back to ontology building -
describing what we actually know about each instrument.
Frank
Melanie Courtot
On 30-Jan-09, at 12:58 AM, Frank Gibson wrote:
> On Thu, Jan 29, 2009 at 7:54 PM, Melanie Courtot
> <mcou...@gmail.com> wrote:
>> FYI - as I did tell Frank this morning, I did commit the newids
>> files under
>> our SVN yesterday, and the MSI terms have now been assigned an OBI
>> ID, as
>> has been approved by the coordinators.
>>
>> The namespace discussion during workshop should allow us to
>> officialize the
>> formalization of the policy that Susanna and Philippe are preparing.
>
> excellent
>
>> Other issues mentioned during dev call included how to proceed with
>> the
>> function/process branches,
>
> This is an outstanding BFO issue, in the sense that do funtions exist,
> or are they actually just processes
We need to know how to move forward on those, in coordination with the
process branch.
>
>
> formalizing difference between instrument/device
>> (in good way),
>
> This is closed. An instrument is a device that produces data
>
>
> and restriction on platform (is a platform always 2 or more
>> devices/instruments for example)
>
> this is how it is described in the definition, collection of more that
> one devices and software. However the has_part relation is transitive,
> meaning you can't add cardinality to it. So this item is also closed.
As it has been a recurring question, maybe we should consider adding
it in our owl-full file.
>
>
> Lets try and not get hung-up about these classes which are purely used
> for classification and lets try and get back to ontology building -
> describing what we actually know about each instrument.
The above comments were meant to reflect things people were wondering
about during the dev call, and that we should explicit clearly when
presenting our core set during the workshop.
Melanie