[Obi-devel] Wiki quick-id file
Dirk Derom
Past few days I've been working on the OBI Quick ID process page (http://obi-ontology.org/page/Quick_id). It has become a quite lengthy and detailed description on how to add a term to OBI. I took myself as a reference on what one would need to fully grasp what and how to add in the obi-quick-id.owl file.
In short
======
The Quick ID should allow anyone interested and with no or a small background to add terms using the Quick ID. Therefore the document both describes the concept behind Quick Term (introduction, glossary) as it is a description of the actual process of adding a term. I thought this was usefull, because the connection between BFO, OBI and Quick Term was not immediatly obvious to me. The very concept of top-level ontologies is quite remarkable (at least for a novice like me) and so is the Quick ID process. Ow well, I thought of explaining it all so one is able to at least conceptually know how it all works.
This seemed necessary to me, because now (and most certainly later on, as soon as it gains momentum) we would like to build a hgihly accessible ontology, with the lowest learning curve possible. Writing it all out and adding enough detail, sounded reasonable to me.
There is still some content missing (such as how to check its consistency, a short glossary and the way to actually add your terms to the OBI SVN), but that really will not take long to write out (and other general edits). I nevertheless decided to send an email, since I think it might be a good time to get some feedback about it. And also since I have some questions regarding other missing content (such as the 'information that describes a material entity', see further in this post).
Some Questions
=============
- Due to the lengthy (possibly not really wiki like) it might be useful to create subpages. If so, I would take each first level heading (How to use this document, Introduction to Quick Term...) as a separate page (and change the title off course, since the current ones are ok for a TOC, but not as a url).
- Frank initially added a structure to the doc with the following distinction: add a term as a process, material entitty or information about an entitiy. I've been looking for the 'information about a material entity', but only found a reference in an older owl file where an assay was described as a "An assay is a process with the objective to create as an output information about a material entity (bearing evaluant role)". I found some classes which might be 'about' a material entity. But since I was not sure, I thought of asking it to those with more background knowledge. So: where the following classes what you had in mind Frank?
1. 'information content entity' (entity ->continuant -> dependent continuant -> generacally dependent continuant -> information content entity)
2. 'quality' and its subclasses (entity ->continuant -> dependent continuant -> specifically dependent continuant -> quality)
Once I'm sure about its classes, I will start writing out this still missing part in the tutorial.
- Wouldn't it be useful to create a separate mailinglist for the Quick ID. This might become useful when the Quick ID process is getting more and more attention, and when people will have specific questions regarding the Quick ID process. It seems to me that adding those to one of the existing mailinglists is not a good idea, since these questions are very specific in the first place and if not the admin/mod can always forward to others. If one needs an admin/mod (someone keeping track of the list and tries to reply quickly to new threads) I would not mind doing so.
About the syntax and HTML tags used in the doc:
======================================
I had to tweak (and clean up) the syntax (add some HTML) because I had a hard time trying to add additional templates/features on the wiki. Or I used them incorrectly (quite possible) or they are not installed (no idea on how that works on the back-end). The HTML I added:
- undefined lists (ul/li stuff) because wiki does not handle <br> all too well (or at least I couldn't get it working) and the HTML is more easy to control
- the span tag to create internal anchors which are not headings
- I had to use quite a few tables, mostly when I used the screenshots, since I could get the text wrap around the embedded image.
- I used a lot of <br> (I'm used to HTML), possible should remove those (if you guys do not like those)
Some questions:
- Does wikimedia allow for external css files? This would be handy for tables.
- Could someone tell me whether it is (with the current installation) possible to use the 'frame' attribute (I did not succeed to e.g. change its color, which I thought indicated that the frame attribute is not enabled)
- Is it possible that floating the image is not working properly and how to add some a border to the image (so that the text does not 'touch' the image).
Adding terms myself
================
I will be adding terms the following days. I did not yet add any, since I was mainly figuring out how to do that and at the same time writing out the doc.
Hope it comes failry close to what was expexted and obviously any comment is more than welcome.
And before I forget: a very good 2009 to you all!
Cheers,
Dirk
Melanie Courtot
Hi all,
Past few days I've been working on the OBI Quick ID process page (http://obi-ontology.org/page/Quick_id). It has become a quite lengthy and detailed description on how to add a term to OBI. I took myself as a reference on what one would need to fully grasp what and how to add in the obi-quick-id.owl file.
In short
======
The Quick ID should allow anyone interested and with no or a small background to add terms using the Quick ID. Therefore the document both describes the concept behind Quick Term (introduction, glossary) as it is a description of the actual process of adding a term. I thought this was usefull, because the connection between BFO, OBI and Quick Term was not immediatly obvious to me. The very concept of top-level ontologies is quite remarkable (at least for a novice like me) and so is the Quick ID process. Ow well, I thought of explaining it all so one is able to at least conceptually know how it all works.
This seemed necessary to me, because now (and most certainly later on, as soon as it gains momentum) we would like to build a hgihly accessible ontology, with the lowest learning curve possible. Writing it all out and adding enough detail, sounded reasonable to me.
There is still some content missing (such as how to check its consistency, a short glossary and the way to actually add your terms to the OBI SVN), but that really will not take long to write out (and other general edits). I nevertheless decided to send an email, since I think it might be a good time to get some feedback about it. And also since I have some questions regarding other missing content (such as the 'information that describes a material entity', see further in this post).
Some Questions
=============
- Due to the lengthy (possibly not really wiki like) it might be useful to create subpages. If so, I would take each first level heading (How to use this document, Introduction to Quick Term...) as a separate page (and change the title off course, since the current ones are ok for a TOC, but not as a url).
- Frank initially added a structure to the doc with the following distinction: add a term as a process, material entitty or information about an entitiy. I've been looking for the 'information about a material entity', but only found a reference in an older owl file where an assay was described as a "An assay is a process with the objective to create as an output information about a material entity (bearing evaluant role)". I found some classes which might be 'about' a material entity. But since I was not sure, I thought of asking it to those with more background knowledge. So: where the following classes what you had in mind Frank?
1. 'information content entity' (entity ->continuant -> dependent continuant -> generacally dependent continuant -> information content entity)
2. 'quality' and its subclasses (entity ->continuant -> dependent continuant -> specifically dependent continuant -> quality)
Once I'm sure about its classes, I will start writing out this still missing part in the tutorial.
- Wouldn't it be useful to create a separate mailinglist for the Quick ID. This might become useful when the Quick ID process is getting more and more attention, and when people will have specific questions regarding the Quick ID process. It seems to me that adding those to one of the existing mailinglists is not a good idea, since these questions are very specific in the first place and if not the admin/mod can always forward to others. If one needs an admin/mod (someone keeping track of the list and tries to reply quickly to new threads) I would not mind doing so.
About the syntax and HTML tags used in the doc:
======================================
I had to tweak (and clean up) the syntax (add some HTML) because I had a hard time trying to add additional templates/features on the wiki. Or I used them incorrectly (quite possible) or they are not installed (no idea on how that works on the back-end). The HTML I added:
- undefined lists (ul/li stuff) because wiki does not handle <br> all too well (or at least I couldn't get it working) and the HTML is more easy to control
- the span tag to create internal anchors which are not headings
- I had to use quite a few tables, mostly when I used the screenshots, since I could get the text wrap around the embedded image.
- I used a lot of <br> (I'm used to HTML), possible should remove those (if you guys do not like those)
Some questions:
- Does wikimedia allow for external css files? This would be handy for tables.
- Could someone tell me whether it is (with the current installation) possible to use the 'frame' attribute (I did not succeed to e.g. change its color, which I thought indicated that the frame attribute is not enabled)
- Is it possible that floating the image is not working properly and how to add some a border to the image (so that the text does not 'touch' the image).
Adding terms myself
================
I will be adding terms the following days. I did not yet add any, since I was mainly figuring out how to do that and at the same time writing out the doc.
Hope it comes failry close to what was expexted and obviously any comment is more than welcome.
And before I forget: a very good 2009 to you all!
Cheers,
Dirk
------------------------------------------------------------------------------
_______________________________________________
Obi-devel mailing list
Obi-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/obi-devel
Dirk Derom
But isn't that intrinsically part of OBI as such? Meaning: OBI currently does not hold a massive amount of terms, and lots should be added. Quickly adding (lots of) terms (from my perspective) seems to be inevitable in quite a few cases: t might not encourage participation if one has to wait before he/she can add the terms used in his/her DB and one can expect that (at least in the beginning when OBI is not a standard) at a certain time some DB and tool developers will be adding their terms (and preferably all in once).
Word indeed is dubious, and I must say that the definitions are not always as clear as I would like them to. Which brings me to another topic I did not yet suggested: a determination table for the BFO classes. Wiki does not allow any fancy coding so it should be something like 'Does it have ...? Yes (go to question 3), No (go to question 4). Might be useful as opposed of going through all the different definitions. Probably another page too.
Mailinglists are useful, but indeed not always the best solution. I always found them hard to manage to be honest. So I do understand your point about not creating another one, and even more when we would reduce the upload.
Dev call sounds good indeed.
--
Kind regards,
Dirk Derom.
--------------------------------------------------------
Check one of the following websites:
-> Neuroinformatics:
http://www.metaneva.org/
-> Graphic Design:
http://sarahverroken.com/
http://sarahverroken.blogspot.com/
Melanie Courtot
I see your point Melanie on adding terms to OBI and indeed various scenarios are possible. Adding lots of terms at once, indeed might introduce a very big load on the developers for the reasons you mentioned.
But isn't that intrinsically part of OBI as such? Meaning: OBI currently does not hold a massive amount of terms, and lots should be added. Quickly adding (lots of) terms (from my perspective) seems to be inevitable in quite a few cases: t might not encourage participation if one has to wait before he/she can add the terms used in his/her DB and one can expect that (at least in the beginning when OBI is not a standard) at a certain time some DB and tool developers will be adding their terms (and preferably all in once).
Word indeed is dubious, and I must say that the definitions are not always as clear as I would like them to. Which brings me to another topic I did not yet suggested: a determination table for the BFO classes. Wiki does not allow any fancy coding so it should be something like 'Does it have ...? Yes (go to question 3), No (go to question 4). Might be useful as opposed of going through all the different definitions. Probably another page too.
Mailinglists are useful, but indeed not always the best solution. I always found them hard to manage to be honest. So I do understand your point about not creating another one, and even more when we would reduce the upload.
Dev call sounds good indeed.
Frank Gibson
out the process and the documentation for submitting terms, which is
missing for OBI and which is essential, there is no need to get hung
up about place_holders and things like that. Any terms that are
submitted will be correctly defined and accompanied by the appropriate
metadata, unlike the classes under the placeholders currently in OBI.
The objective is to create documentation describing the process which
can then be reviewed by all the developers when we feel we have
covered everything.
Comments in line
On Sat, Jan 3, 2009 at 7:45 AM, Melanie Courtot <mcou...@gmail.com> wrote:
>
> On 2-Jan-09, at 8:35 PM, Dirk Derom wrote:
>
> I see your point Melanie on adding terms to OBI and indeed various scenarios
> are possible. Adding lots of terms at once, indeed might introduce a very
> big load on the developers for the reasons you mentioned.
>
> I am concerned about adding them directly under the roots process and
> material entity. That's why I was suggesting a way to mark them, or having a
> placeholder for them. I don't think any of those solution are ideal, a
> marker would need to be at the label level (for identification in the
> hierarchy and/or when building restrictions), and using placeholders would
> force us to have several of them (at least one placeholder per branch on top
> of the already existing ones)
> I like the Data Transformation branch approach: there is only one
> placeholder, _unclassified, which contains all classes that have not yet
> been completely curated. Once they are curated by the branch, they are moved
> to their respective place. On the editing side it is very easy to see where
> the work is, and at the same time we know that the branch structure outside
> of the placeholder is pretty stable.
You need not be concerned about placing terms under the roots of
process and material_entity, If they are processes and materials then
this is the correct place for them. The difference is that quick terms
will be correctly defined and be accompanied by the required metadata,
unlike the terms under placeholders. The reasoner will work out the
hierarchy
>
> But isn't that intrinsically part of OBI as such? Meaning: OBI currently
> does not hold a massive amount of terms, and lots should be added. Quickly
> adding (lots of) terms (from my perspective) seems to be inevitable in quite
> a few cases: t might not encourage participation if one has to wait before
> he/she can add the terms used in his/her DB and one can expect that (at
> least in the beginning when OBI is not a standard) at a certain time some DB
> and tool developers will be adding their terms (and preferably all in once).
Yes, the current OBI methodology is slow, inefficient and
unsustainable. Producing these documents should document the process,
thereby educating term submissions and taking some of the load of
developers
> I agree that we will need to add lots of terms to OBI if we expect it to
> completely cover several areas (or even just one ;) )
one area would be nice, one experiment would also be good :)
> I think that in order to do so, the first step will be working on the core
> terms as suggested by Bjoern. This will give us a solid core upon which to
> build: identifying the central pivotal ones and providing good definitions,
> examples, use cases and having inter branches understanding on what they are
> and how to use them we will most probably make it easier for people to
> identify where their terms would fit the best.
So this may develop over time. The first instance, (starting point) is
to document the procedure where we can identify where a term fits
under BFO, e.g process, material entity etc and supply enough
information on a class that a reasoner can build the hierarchy, - This
is what we are trying to do with the quick term document, - which is
still in flux
> I think the second step will indeed be the quick ids proposal, and a
> mechanism allowing us to do so is in my opinion definitively the best way to
> go.
> The point I was raising was that I don't think we should allow everybody to
> submit huge amount of terms and commit them into the OBI files without
> checking on them first.
"Traditional" approaches are using a tracker system,
> having curators review the submission and include it in the official
> resource.
> On the OBI side we don't have a team of curators, so I was suggesting that
> the minimum would be to have at least one person reviewing the
> submission (whether the submission comes from external people or an other
> OBI developer).
Yes, the purpose of this exercise is for me and Dirk to work together
on producing the document to describe the process, not nessecarialy to
add hundreds of terms in the first pass, but add some (checked by me)
to iron out the process
> In addition our SVN is currently writable only by OBI developers, and
> I wouldn't encourage changing that to a full open access.
agreed
> I believe a bit of wait is inevitable and expected: for example when OBI
> developers are asking for addition in other resources (PATO, SO, CHEBI to
> cite some) we know that they won't appear immediately.
yes, we have not got that far in documenting the process yet
> In my opinion the quick-id proposal is there to give us the assurance we can
> process them in a timely fashion, and we would commit to that.
> The immediate counter-argument is that we would need to make sure one of the
> OBI developers actually takes care of them.
agreed
>
> Word indeed is dubious, and I must say that the definitions are not always
> as clear as I would like them to. Which brings me to another topic I did not
> yet suggested: a determination table for the BFO classes. Wiki does not
> allow any fancy coding so it should be something like 'Does it have ...? Yes
> (go to question 3), No (go to question 4). Might be useful as opposed of
> going through all the different definitions. Probably another page too.
>
> I like that idea, if you're up for it we could give it a try together?
> (taking that discussion offline)
This is the point of the documentation process!
>
> Mailinglists are useful, but indeed not always the best solution. I always
> found them hard to manage to be honest. So I do understand your point about
> not creating another one, and even more when we would reduce the upload.
No more mailing lists - we are (should be) building one ontology
>
> Dev call sounds good indeed.
>
> We did commit on using the next dev calls to identify and work on the core
> terms, so maybe we can see if others have advice on the list, and hopefully
> progress here first?
Yes, these core terms are the focus of the dev calls until Vancouver.
The quick id stuff is just being documented in parallel - open - on
the wiki, but should not be a distraction from the core terms
[snip]
. For example, I am not sure "word" should
>> be positioned under material entity.
no it should not.
>> I'm also cautious of the idea of adding a bunch of terms "suddenly" to a
>> branch. I would maybe suggest using a branch placeholder: if for example I
>> drop in 50 new terms under material entity it will be difficult for editors
>> to know how to deal with them. On the other hand, adding multiple
>> placeholders doesn't seem a very good idea either.
no placeholders, just correctly defined terms, and asserted under BFO
>> I also would suggest a way to identify quick id terms: we said that as
>> they are not part of the release, we won't use them for example in
>> restrictions.
I think there maybe some confusion here, if the have and id the are
part of the release, no?
But If I were now to add a restriction in let's say the
>> Instrument file using in a restriction one of the quick id terms I have no
>> immediate way to know that it was a quick id term. This will most probably
>> result in inconsistency trouble during release process.
Not sure what you mean here, maybe its just your wording, we may be
jumping ahead of ourselves, the first the we are trying to do is
document how we can define and include a class. We are not dealing
with restrictions yet
>>
>> On 2-Jan-09, at 7:01 PM, Dirk Derom wrote:
>>
>> Hi all,
>>
[snip]
>>
>> Some Questions
>> =============
>> - Due to the lengthy (possibly not really wiki like) it might be useful to
>> create subpages. If so, I would take each first level heading (How to use
>> this document, Introduction to Quick Term...) as a separate page (and change
>> the title off course, since the current ones are ok for a TOC, but not as a
>> url).
Thats possible, however the document is still being drafted, although
not ideal it is probably better to leave it as a single page and the
break it down (or use something other than a wiki) to format it.
[snip]
>>
>> - Frank initially added a structure to the doc with the following
>> distinction: add a term as a process, material entitty or information about
>> an entitiy. I've been looking for the 'information about a material entity',
>> but only found a reference in an older owl file where an assay was described
>> as a "An assay is a process with the objective to create as an output
>> information about a material entity (bearing evaluant role)". I found some
>> classes which might be 'about' a material entity. But since I was not sure,
>> I thought of asking it to those with more background knowledge. So: where
>> the following classes what you had in mind Frank?
>> I would think that Frank was trying to separate between process, material
>> entity and DENRIE/IAO. DENRIE/IAO contain all "information" related terms.
>> For example: datum, image... We may consider adding word there.
>> A bit more of background information: originally OBI built the DENRIE
>> (digital entities and non-realizable entities) branch. As the OBI developers
>> thought that the scope of this branch was wider than just OBI, it has been
>> decided to outsource it to IAO (the information artifact ontology,
>> at http://code.google.com/p/information-artifact-ontology/) If you browse
>> OBI currently, you will see that most of the classes under information
>> content entity are imported from IAO.
This was just a starting point, the first step in dertermining what
you class is, a process, a material or something else - information. I
did not create a section in the wiki page for information yet, only
process and material, with the idea of getting those correct first -
guess I am not working fast enough :)
>>
>> 1. 'information content entity' (entity ->continuant -> dependent
>> continuant -> generacally dependent continuant -> information content
>> entity)
>> 2. 'quality' and its subclasses (entity ->continuant -> dependent
>> continuant -> specifically dependent continuant -> quality)
>> Once I'm sure about its classes, I will start writing out this still
>> missing part in the tutorial.
Patience :) lets get process and material correct first
>> - Wouldn't it be useful to create a separate mailinglist for the Quick ID.
>> This might become useful when the Quick ID process is getting more and more
>> attention, and when people will have specific questions regarding the Quick
>> ID process. It seems to me that adding those to one of the existing
>> mailinglists is not a good idea, since these questions are very specific in
>> the first place and if not the admin/mod can always forward to others. If
>> one needs an admin/mod (someone keeping track of the list and tries to reply
>> quickly to new threads) I would not mind doing so.
No more mailing lists, quick_id is just a process for creating OBI IDs
its part of OBI
[snip]
>>
>> Would you mind giving us a bit of time to review before starting to add
>> terms?
I will do this, as decided in the last dev call, doing this helps
build the documentation
[snip]
Nice work Dirk, still plenty to do - baby steps :)
Cheers
Frank
Melanie Courtot
Thanks for the reply, my comments inline too.
On 5-Jan-09, at 8:48 AM, Frank Gibson wrote:
> This has been a useful discussion, in general we are trying to work
> out the process and the documentation for submitting terms, which is
> missing for OBI and which is essential, there is no need to get hung
> up about place_holders and things like that. Any terms that are
> submitted will be correctly defined and accompanied by the appropriate
> metadata, unlike the classes under the placeholders currently in OBI.
> The objective is to create documentation describing the process which
> can then be reviewed by all the developers when we feel we have
> covered everything.
I totally support the idea of documenting and reviewing extensively
the proposal before going further.
Can you walk me through an example?
Let's consider the classes you added in obi-quick-id, for example the
first one, intra cellular electrophysiology recording.
It is currently asserted directly under process, and has no additional
restriction. So the reasoner won't position it anywhere else than
where it currently is.
If we were to add for example 200 terms like that, you can imagine
that from the editing point of view it becomes difficult for editors
to sort out things. That's what I meant with placeholders. If we were
to imagine a placeholder "_unclassified" it would be immediately
obvious that those class need to have restriction added to get
properly classified by the reasoner.
As said previously I don't really like the idea of placeholders
either, I am just worried about being able to work as a human editor
with a file I can manage in Protege.
>
>
>
>>
>> But isn't that intrinsically part of OBI as such? Meaning: OBI
>> currently
>> does not hold a massive amount of terms, and lots should be added.
>> Quickly
>> adding (lots of) terms (from my perspective) seems to be inevitable
>> in quite
>> a few cases: t might not encourage participation if one has to wait
>> before
>> he/she can add the terms used in his/her DB and one can expect that
>> (at
>> least in the beginning when OBI is not a standard) at a certain
>> time some DB
>> and tool developers will be adding their terms (and preferably all
>> in once).
>
> Yes, the current OBI methodology is slow, inefficient and
> unsustainable. Producing these documents should document the process,
> thereby educating term submissions and taking some of the load of
> developers
>
come on, were not that bad ;)
>
>
>
>> I agree that we will need to add lots of terms to OBI if we expect
>> it to
>> completely cover several areas (or even just one ;) )
>
> one area would be nice, one experiment would also be good :)
>
>
>> I think that in order to do so, the first step will be working on
>> the core
>> terms as suggested by Bjoern. This will give us a solid core upon
>> which to
>> build: identifying the central pivotal ones and providing good
>> definitions,
>> examples, use cases and having inter branches understanding on what
>> they are
>> and how to use them we will most probably make it easier for people
>> to
>> identify where their terms would fit the best.
>
> So this may develop over time. The first instance, (starting point) is
> to document the procedure where we can identify where a term fits
> under BFO, e.g process, material entity etc and supply enough
> information on a class that a reasoner can build the hierarchy, - This
> is what we are trying to do with the quick term document, - which is
> still in flux
>
Could we clarify here? Is it just saying : this is a process, this is
a material or do we try to go further?
If we stay high-level (process/material), everybody will be able to
classify its submission. If we want to get more specific it will
become very complicated for external users to know how to proceed. We
have been working with OBI for a while now, and are still sometimes
uncertain about some things.
I think we should aim at keeping things simple for the submitter,
while we can indeed suggest a first high-level classification I would
be reluctant asking for a detailed one.
>
>> I think the second step will indeed be the quick ids proposal, and a
>> mechanism allowing us to do so is in my opinion definitively the
>> best way to
>> go.
>> The point I was raising was that I don't think we should allow
>> everybody to
>> submit huge amount of terms and commit them into the OBI files
>> without
>> checking on them first.
> "Traditional" approaches are using a tracker system,
>> having curators review the submission and include it in the official
>> resource.
>> On the OBI side we don't have a team of curators, so I was
>> suggesting that
>> the minimum would be to have at least one person reviewing the
>> submission (whether the submission comes from external people or an
>> other
>> OBI developer).
>
>
> Yes, the purpose of this exercise is for me and Dirk to work together
> on producing the document to describe the process, not nessecarialy to
> add hundreds of terms in the first pass, but add some (checked by me)
> to iron out the process
>
Ok - we already have 2 of them in the obi-quick-id file you created,
what about starting with those? What would be the next steps for those
2 classes?
My misundertanding, I thought you were documenting how to add quickly
terms to OBI, I didn't understand that you would include a full
description of BFO and the OBI structure.
Great, I let you take care of that then :)
cf example above, I assume the 2 terms you added are correctly defined.
>
>
>>> I also would suggest a way to identify quick id terms: we said
>>> that as
>>> they are not part of the release, we won't use them for example in
>>> restrictions.
>
> I think there maybe some confusion here, if the have and id the are
> part of the release, no?
There is no correlation between having an ID and being part of the
release.
- example 1: top level defined placeholders
_defined_material has the OBI ID OBI_0000233, and it doesn't appear in
ther release version of OBI. These top-level placeholders are removed
programatically. They appear in Protege because if was deemed easier
from an editing point of view to have a placeholder to hold our
defined classes.
- example 2: we discussed already the option of removing uncurated
classes from the release. Those would have an OBI ID and wouldn't
appear in the released file.
My understanding after discussion of the quick-id proposal was that we
would "store" the quick-id terms in that file, but that they wouldn't
be distributed as part of our release as long as they are not curated.
They would get an ID, which would never be deleted, so that external
users could start using that ID, but we wouldn't be distributing them
as long as not cleaned up. So the process would be user X submits
file, file reviewed by OBI dev Y, incorporated into the quick-id file
by OBI dev Y (initial submission could be owl, but we could also
imagine an excel template that would leverage Jason's tool and would
probably be more user-friendly). Script ran to assign OBI IDs to those
terms (doing necessary operations to ensure consistency with release
processes), OBI dev Y sends back to user X the list of terms and their
OBI IDs.
Probably something worth clarifying too.
>
>
> But If I were now to add a restriction in let's say the
>>> Instrument file using in a restriction one of the quick id terms I
>>> have no
>>> immediate way to know that it was a quick id term. This will most
>>> probably
>>> result in inconsistency trouble during release process.
>
> Not sure what you mean here, maybe its just your wording, we may be
> jumping ahead of ourselves, the first the we are trying to do is
> document how we can define and include a class. We are not dealing
> with restrictions yet
>
Taking the example again: you added the process intra cellular
physiology recording.
Now imagine I add the class "electrode" in the instrument file, and I
add a restriction on the electrode class saying it is_device_for intra
cellular physiology recording.
If intra cellular physiology recording doesn't make it into the
release, we'll run into trouble.
On the other hand, if the quick ids make it into the release, it would
be good to make sure they are hierarchically well positioned, as we
are adding disjoints during the release process. One possible example
is the "rat" one, if rat were added under material entity, and we were
adding disjoints under material entity, we would end up with a
situation were rat would be disjoint of organism for example.
Again, not saying there is a perfect option, just that we should be
aware of potential issues and discuss the process.
[snip]
>
>>>
>>> Would you mind giving us a bit of time to review before starting
>>> to add
>>> terms?
>
> I will do this, as decided in the last dev call, doing this helps
> build the documentation
>
>
The last dev call decided on the creation of the quick-id documentation:
"AI for Frank create document about the QuickIDs proposal, liaise with
Alan and Melanie (others who want to be involved are welcome and
should let us know)
Frank will add in document information about understanding in which
branch things go (e.g. is it a quality, process....) to help guide the
submission."
If you say that adding more terms helps the documentation process,
fine, but I would like a decision from the group about what to include
or not in the release. Please keep in mind that with the MSI terms,
the quick id ones, the disjoints and inferred superclasses this is a
complex process, eating more and more time, and that it won't be
sustainable much longer to have specific rules and file management.
Thanks,
Melanie
> [snip]
>
>
> Nice work Dirk, still plenty to do - baby steps :)
>
>
> Cheers
>
> Frank
---
Mélanie Courtot
TFL- BCCRC
675 West 10th Avenue
Vancouver, BC
V5Z 1L3, Canada
------------------------------------------------------------------------------
Frank Gibson
As we are running the risk of writing the documentation here via
email, I would suggest ending this thread and encourage you to add any
issues you have to the end of the wiki page. The process involves
first identify how new (unfamiliar) users can determine if the term
they want to submit is either a process or a material as I think the
distinction is relatively intuative without requireing a knowledge of
BFO. When this stage is completed, (including things like identifiying
if it would be better places in another resource such as Chebi) then
we can move on to deal with relations and BFO:dependent_continuants,
which in itself needs some work. The documentation is in a draft
stage, its not completed and is expected to change.
Thanks
Frank
On Mon, Jan 5, 2009 at 10:10 PM, Melanie Courtot <mcou...@gmail.com> wrote:
> Hi Frank,
>
> Thanks for the reply, my comments inline too.
>
> On 5-Jan-09, at 8:48 AM, Frank Gibson wrote:
>
>> This has been a useful discussion, in general we are trying to work
>> out the process and the documentation for submitting terms, which is
>> missing for OBI and which is essential, there is no need to get hung
>> up about place_holders and things like that. Any terms that are
>> submitted will be correctly defined and accompanied by the appropriate
>> metadata, unlike the classes under the placeholders currently in OBI.
>> The objective is to create documentation describing the process which
>> can then be reviewed by all the developers when we feel we have
>> covered everything.
>
> I totally support the idea of documenting and reviewing extensively
> the proposal before going further.
>
>>
>>
> Can you walk me through an example?
>
> Let's consider the classes you added in obi-quick-id, for example the
> first one, intra cellular electrophysiology recording.
> It is currently asserted directly under process, and has no additional
> restriction. So the reasoner won't position it anywhere else than
> where it currently is.
>
> If we were to add for example 200 terms like that, you can imagine
> that from the editing point of view it becomes difficult for editors
> to sort out things. That's what I meant with placeholders. If we were
> to imagine a placeholder "_unclassified" it would be immediately
> obvious that those class need to have restriction added to get
> properly classified by the reasoner.
>
> As said previously I don't really like the idea of placeholders
> either, I am just worried about being able to work as a human editor
> with a file I can manage in Protege.
>
>
>>
>>
>>
>>>
>>> But isn't that intrinsically part of OBI as such? Meaning: OBI
>>> currently
>>> does not hold a massive amount of terms, and lots should be added.
>>> Quickly
>>> adding (lots of) terms (from my perspective) seems to be inevitable
>>> in quite
>>> a few cases: t might not encourage participation if one has to wait
>>> before
>>> he/she can add the terms used in his/her DB and one can expect that
>>> (at
>>> least in the beginning when OBI is not a standard) at a certain
>>> time some DB
>>> and tool developers will be adding their terms (and preferably all
>>> in once).
>>
>> Yes, the current OBI methodology is slow, inefficient and
>> unsustainable. Producing these documents should document the process,
>> thereby educating term submissions and taking some of the load of
>> developers
>>
>
> come on, were not that bad ;)
>
>>
>>
>>
>>> I agree that we will need to add lots of terms to OBI if we expect
>>> it to
>>> completely cover several areas (or even just one ;) )
>>
>> one area would be nice, one experiment would also be good :)
>>
>>
>>> I think that in order to do so, the first step will be working on
>>> the core
>>> terms as suggested by Bjoern. This will give us a solid core upon
>>> which to
>>> build: identifying the central pivotal ones and providing good
>>> definitions,
>>> examples, use cases and having inter branches understanding on what
>>> they are
>>> and how to use them we will most probably make it easier for people
>>> to
>>> identify where their terms would fit the best.
>>
>> So this may develop over time. The first instance, (starting point) is
>> to document the procedure where we can identify where a term fits
>> under BFO, e.g process, material entity etc and supply enough
>> information on a class that a reasoner can build the hierarchy, - This
>> is what we are trying to do with the quick term document, - which is
>> still in flux
>>
>
> Could we clarify here? Is it just saying : this is a process, this is
> a material or do we try to go further?
>
> If we stay high-level (process/material), everybody will be able to
> classify its submission. If we want to get more specific it will
> become very complicated for external users to know how to proceed. We
> have been working with OBI for a while now, and are still sometimes
> uncertain about some things.
>
> I think we should aim at keeping things simple for the submitter,
> while we can indeed suggest a first high-level classification I would
> be reluctant asking for a detailed one.
>
>>
>>> I think the second step will indeed be the quick ids proposal, and a
>>> mechanism allowing us to do so is in my opinion definitively the
>>> best way to
>>> go.
>>> The point I was raising was that I don't think we should allow
>>> everybody to
>>> submit huge amount of terms and commit them into the OBI files
>>> without
>>> checking on them first.
>> "Traditional" approaches are using a tracker system,
>>> having curators review the submission and include it in the official
>>> resource.
>>> On the OBI side we don't have a team of curators, so I was
>>> suggesting that
>>> the minimum would be to have at least one person reviewing the
>>> submission (whether the submission comes from external people or an
>>> other
>>> OBI developer).
>>
>>
>> Yes, the purpose of this exercise is for me and Dirk to work together
>> on producing the document to describe the process, not nessecarialy to
>> add hundreds of terms in the first pass, but add some (checked by me)
>> to iron out the process
>>
>
> Ok - we already have 2 of them in the obi-quick-id file you created,
> what about starting with those? What would be the next steps for those
> 2 classes?
>
>>
> My misundertanding, I thought you were documenting how to add quickly
> terms to OBI, I didn't understand that you would include a full
> description of BFO and the OBI structure.
>
> Great, I let you take care of that then :)
>
>>
>>
>>
>>>
> cf example above, I assume the 2 terms you added are correctly defined.
>
>>
>>
>>>> I also would suggest a way to identify quick id terms: we said
>>>> that as
>>>> they are not part of the release, we won't use them for example in
>>>> restrictions.
>>
>> I think there maybe some confusion here, if the have and id the are
>> part of the release, no?
>
>> But If I were now to add a restriction in let's say the
>>>> Instrument file using in a restriction one of the quick id terms I
>>>> have no
>>>> immediate way to know that it was a quick id term. This will most
>>>> probably
>>>> result in inconsistency trouble during release process.
>>
>> Not sure what you mean here, maybe its just your wording, we may be
>> jumping ahead of ourselves, the first the we are trying to do is
>> document how we can define and include a class. We are not dealing
>> with restrictions yet
>>
>
> Taking the example again: you added the process intra cellular
> physiology recording.
> Now imagine I add the class "electrode" in the instrument file, and I
> add a restriction on the electrode class saying it is_device_for intra
> cellular physiology recording.
>
> If intra cellular physiology recording doesn't make it into the
> release, we'll run into trouble.
>
> On the other hand, if the quick ids make it into the release, it would
> be good to make sure they are hierarchically well positioned, as we
> are adding disjoints during the release process. One possible example
> is the "rat" one, if rat were added under material entity, and we were
> adding disjoints under material entity, we would end up with a
> situation were rat would be disjoint of organism for example.
>
> Again, not saying there is a perfect option, just that we should be
> aware of potential issues and discuss the process.
>
> [snip]
>
>>
>>>>
>>>> Would you mind giving us a bit of time to review before starting
>>>> to add
>>>> terms?
>>
>> I will do this, as decided in the last dev call, doing this helps
>> build the documentation
>>
>>
>
> The last dev call decided on the creation of the quick-id documentation:
> "AI for Frank create document about the QuickIDs proposal, liaise with
> Alan and Melanie (others who want to be involved are welcome and
> should let us know)
> Frank will add in document information about understanding in which
> branch things go (e.g. is it a quality, process....) to help guide the
> submission."
>
> If you say that adding more terms helps the documentation process,
> fine, but I would like a decision from the group about what to include
> or not in the release. Please keep in mind that with the MSI terms,
> the quick id ones, the disjoints and inferred superclasses this is a
> complex process, eating more and more time, and that it won't be
> sustainable much longer to have specific rules and file management.
>
> Thanks,
> Melanie
>
>
>> [snip]
>>
>>
>> Nice work Dirk, still plenty to do - baby steps :)
>>
>>
>> Cheers
>>
>> Frank
>
> ---
> Mélanie Courtot
> TFL- BCCRC
> 675 West 10th Avenue
> Vancouver, BC
> V5Z 1L3, Canada
>
>
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Obi-devel mailing list
> Obi-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/obi-devel
>
--
Frank Gibson, PhD
http://peanutbutter.wordpress.com/
Melanie Courtot
Ok - I thought there was a request for comments on the list, but
adding issues on the wiki page is fine by me too.
Cheers,
Melanie
------------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
James Malone
Dirk, MC, thanks for thoughts, I'd like to have a read of the proposal
when there's a working draft, Dirk could you please email the list when
this is ready as I think this is important for the future on-going
development of OBI? I think enabling people to add terms and get IDs
for those terms with *relative* ease is important. That said, we must
surely have one process to follow which is either:
a) every term is manually curated by an OBI developer and eventually
gets added in if appropriate and after discussion or
b) it's not and people can add terms into the ontology as quickly as
they like (assuming some min metadata), get an OBI ID, review will be
ongoing in an ad hoc fashion and presumably the 'bad terms' will be
weeded out over time by the community (and OBI developers).
These are two very distinct approaches and I don't see why we would do
a) if we are going to also accept b) as a submission process. I think
we need to think very carefully about this. That said, I am totally
sympathetic to Dirk et al's needs for getting terms in quickly (I also
find this need presses upon me) but we need to be clear on what the
process is for OBI. Largely, I think it has been a) so far; b)
represents an ontology development paradigm shift as far as I'm
concerned (though I'm ambivalent as to which is better).
Cheers,
James
PS I should add that unclassified is used in data transformation not as
a 'quick ID policy' but rather because those terms needed to be
re-curated so we moved them from their existing parent. I would not
advocate this as a way to continue large scale development per se :)
--
European Bioinformatics Institute,
Wellcome Trust Genome Campus,
Hinxton,
Cambridge, CB10 1SD,
United Kingdom
Tel: + 44 (0) 1223 494 676
Fax: + 44 (0) 1223 492 468