Hi Dirk,
Larisa will contact the editors to see whether we can update the
figures. If not, nothing in urgency.
Timothy reviewed the figures in JBMS papers and found some problems.
Below I list the issues as I understood.
1. There are relations between classes and instances. So, Alan suggest
we'd explain it like:
"In this and subsequent figures, links between classes other than is_a
represent all-some relations. Links between instance and class other
than instance_of represent that the relation is to some (unspecified)
instance of the class."
2. Figure 2, A "is_a" relation shown in an individual "mouse" to a class
"organism" which should be "instance_of" because "is_a" is a relation
between a class to it's super class.
3. Figure 3, relation between 'planning' and 'plan specification' is not
correct. (Details check Alan's email.)
4. Not all instances indicated they are instance_of which classes. (I
don't think it is a big issue for the JBMS paper. But should be avoided
in the future.)
There are other issues related to how we decided which should be
individuals and which should be classes. I think the individuals/classes
chosen limited by the current release of OBI. You can understand it
because when you made your use case you don't have any choice on it.
Hope it is helpful.
Jie
Dirk Derom wrote:
> Hi all,
>
> Just started reading these messages. Got lost in what is needed (and
> possible given the urgency) for the figures.
>
> Can someone summarize what has to be changed to the figures (if
> anything at all at this point)? I don't have a lot of time currently,
> but will try to finish asap.
>
> Cheers,
>
> D
>
> 2010/2/24 Jie Zheng <jiezheng@...
> <mailto:jiezheng@...>>
>
> Hi Timothy,
>
> Thanks a lot for your comments. I added some comments as I understand.
> Please see them in-line.
>
> Timothy Danford wrote:
> > Hi Jie,
> >
> > Thank you for the invitation to comment further on the figures. I
> > understand that these suggestions are very last minute, so take them
> > or leave them as your schedule allows.
> >
> > I would suggest that there are several other small features of the
> > figures that I found to be confusing.
> >
> > (1) As Alan suggested, I think the decision to make a particular box
> > an individual (dotted border) or a class is completely opaque.
> > Looking at the first figure, why are "neuron" and "spike train
> datum"
> > classes, while the "single unit recorder," "Japanese macaque
> monkey,"
> > and "light on tangent screen" all individuals? The same question is
> > relevant for all three figures. I'd suggest that, at a minimum,
> > someone should consider making *all* the boxes with pictures in
> them,
> > in all three figures, into individuals.
> >
> >
> All the instances shown in the figures are not in OBI yet. The
> paper is
> focusing on modeling the process using OBI. However, OBI is not rich
> enough now for representing all use cases in the paper. For
> simplification, all the terms not included in OBI, we used them as
> individual. They could be classes.
>
> Some classes were added just for the use case (Figure 1) because
> otherwise it is impossible to represent it in OBI. Even though, it
> didn't do well in the view of neuron scientist. We tried it to
> make some
> compromise for it.
> > (2) I think that the use of the "evaluant role" in Figure 3 is
> really
> > confusing. All three figures have assays in them, and (as I
> > understand the OBI documents), all assays realize evaluant roles
> that
> > inhere in some input to the assay. Why is the yeast the only
> > indicated bearer of the evaluant role in any of the three
> figures? Is
> > it not important for the other two figures? For that matter, the
> > assay in Figure 3 is the only assay in any of the figures that had
> > *two* specified inputs. I spent a fair bit of time on my own trying
> > to figure out why one input to that assay was shown as bearing an
> > evaluant role, but not the other. Maybe this could be made clear in
> > some text or caption to the paper.
> >
> Three use cases were provided by three scientists who are working in
> different areas. So, they emphasized different parts when they modeled
> their use cases. The evaluent role is realized by 'analyte assay'. As
> you found, in figure 2, 'organism' (mouse) bearer_of 'evaluent
> role' in
> 'survival assessment'. For the figure 3, I'd like to explain the assay
> and then you can understand why we added yeast bearer_of 'evaluent
> role'. The assay was used to monitor the growth of yeast in the
> presence
> of different metabolite. So, both yeast and metabolite are
> specified_input of the assay. Metabolite is the nutrient for yeast
> so it
> is bearer_of nutrient role. How many yeast at the different time
> in the
> present of metabolite were measured in the assay shown in optical
> density reading. So, 'yeast' is bearer_of 'evaluent_role'. For
> this use
> case, both 'yeast' and 'metabolite' are important and should be
> modeled.
> Due to limitation of current release OBI, the figure is too simple
> to be
> understand in some way. It could be made clearer in the text as
> you said.
>
> > I understand that there were decisions made about how to draw these
> > figures at some point in the paper writing process -- and I insist
> > that I'm not trying to criticize or second-guess those decisions.
> >
> > But I would like to say that many of my and Jonathan's suggestions
> > about these figures stem from what I take to be a basic confusion
> > about the way such figures could be drawn, and what they could
> > represent. In my mind, figures like these could fulfill one of two
> > roles. Either the figure:
> >
> > (A) is a guide to the existing OBI classes and properties
> which are
> > relevant to each of the different problem domains, or
> >
> > (B) is a guide to the curator, describing what someone who is
> > *using* OBI would try to say in order to describe an actual
> experiment
> > as it was carried out.
> >
> > Studying these figures, I can't help but feel that these two
> possible
> > roles for the figures have been combined in a confusing way. As an
> > example of what I mean, take the box on the right side of Figure 3,
> > "automated investigation of the enzyme EC2.6.1.39". This individual
> > is an 'instance_of' a 'hypothesis driven investigation', which
> > 'has_specified_output' some 'conclusion textual entity.' The
> > individual 'hypothesis has been confirmed... [etc.]' is an
> instance of
> > this last class.
> >
> > Clearly, the figure does not fulfill Role (A), since individuals
> like
> > 'automated investigation of enzyme EC2.6.1.39' and 'hypothesis has
> > been confirmed...' are part of the description of a *particular*
> > investigation carried out by the Robot Scientist, and not part
> of OBI
> > in general. One could imagine an "OBI-ified" Robot Scientist as
> > reporting its results by asserting the existence of these
> individuals,
> > and their class memberships, as part of its output.
> >
> > At the same time, the figure doesn't fulfill Role (B) either,
> since it
> > seems to say that "all 'hypothesis driven investigations' have the
> > relation 'has_specified_output' to some 'conclusion textual entity'"
> > -- but that's an axiom of OBI itself, which I can read directly from
> > the definition of an 'investigation'. It's good that the figure
> shows
> > me this, as knowing this axiom would be useful to me if I were
> > designing a properly-OBI-ified Robot-Scientist to output its results
> > in OBI-compliant format. But it isn't something that the Robot
> > Scientist would have to, or want to, assert on its own.
> >
> > Furthermore, mixing classes and individuals like this makes it
> unclear
> > what the relationship between the 'automated investigation'
> individual
> > and the 'hypothesis has been confirmed' individual *should* be.
> I've
> > read King et al.'s "Robot Scientist" papers, so *I* know that the
> > second individual is the specified_output of the first. But that's
> > not shown in the figure -- all that I know from the figure is that a
> > model in which the one is the output of the other is
> satisfactory to,
> > but not required by, the class relationships in the figure.
> Maybe the
> > hypothesis confirmation is the output of some other, unspecified
> > investigation...?
> >
> >
> The relation between class 'hypothesis driven investigation' and
> 'conclusion textual entity' is all_some. So, it holds true to all
> their
> instances. For me, it is quite straightforward.
> > I think similar criticisms could be made of all three figures --
> maybe
> > they're trying to do too much, to function both as "a guide to OBI"
> > and "an example of curation," but it ends up all very confusing to
> > someone (like me) who's willing to read OWL and OBO files and
> who just
> > wants to know how to write out *actual* descriptions of actual
> assays,
> > investigations, and material transformations that were used to
> produce
> > antibodies and to test them against potential antigens.
> >
> > I apologize for the length of this email, and if these comments are
> > out of line then I further apologize.
> >
> > Thank you,
> >
> > Timothy Danford
> >
> >
> >
> >
> For something you mentioned in the email, I need time to digest and
> think. So no more comments on it.
>
> Thanks,
>
> Jie
>
> >
> >> -----Original Message-----
> >> From: Jie Zheng [mailto:jiezheng@...
> <mailto:jiezheng@...>]
> >> Sent: Tue 2/23/2010 12:06 PM
> >> To: Alan Ruttenberg
> >> Cc: Larisa Soldatova; Jonathan Rees; OBI Developers; Danford,
> Timothy William;
> >> Yongqun He
> >> Subject: Re: [Obi-devel] OBI figures in JMBS papers
> >>
> >> Hi Alan,
> >>
> >> I totally agree with you about planning and plan specification. If
> >> possible, I think we should fix it. The figure3 was redrawn by
> Dirk for
> >> making consistent representation. He used a free software,
> OmniGraffle,
> >> for Mac. I think anyone who have Mac can download the software
> >> (http://www.omnigroup.com/applications/OmniGraffle/) and fix
> the figure.
> >> The editable figure is in SVN under the directory:
> >>
> https://obi.svn.sourceforge.net/svnroot/obi/trunk/docs/papers/JBMS_2009/automate
> >> d
> >> functional genomics investigation use case
> >>
> >> Thanks Tim and Jonathan for reviewing the figures.
> >>
> >> Jie
> >>
> >> Alan Ruttenberg wrote:
> >>
> >>> On review and further discussion with Tim there are other issues.
> >>> In the vaccination trial the representation of instance versus
> class
> >>> is not clear - why is Mouse a class but VacX an instance.
> >>> Also, it isn't true that there is an all-some between mouse
> and target
> >>> of material of addition role or between influenza virus and
> material
> >>> to be added role.
> >>> In the robot scientist there is a link
> >>>
> >>> planning is_realized_by plan specification.
> >>>
> >>> That's incorrect, and I don't think it is what is intended. I
> think
> >>> what is trying to be said is that
> >>>
> >>> a) There is a design process in which the robot creates a plan
> specification
> >>> b) A realization of the concretization of that plan
> specification is
> >>> the automated investigation
> >>>
> >>> If Larisa confirms someone can fix the figure to say so.
> >>>
> >>> Where are the source for the diagrams - what was the drawing
> too used.
> >>> I'm encouraging Tim and Jonathan to directly contribute to the
> >>> discussion so I don't have to be intermediary. They are perfect
> >>> reviewers as they are reading this paper to really understand
> OBI so
> >>> that it can be applied in my project. The errors are confusing
> them
> >>> and I think the figures should be amended until they sign off
> saying
> >>> that they make sense.
> >>>
> >>> I'll try to participate further during the day.
> >>> -Alan
> >>>
> >>> On Tue, Feb 23, 2010 at 10:39 AM, Larisa Soldatova
> <lss@... <mailto:lss@...>> wrote:
> >>>
> >>>
> >>>> Hi All,
> >>>> the caption for Fig.1 will be changed as Jie proposed (see
> below). Please
> >>>> send me your corrections as soon as possible. I am going to
> contact the
> >>>> Editors in 24h and ask if we can make this update.
> >>>> Thank you,
> >>>> Larisa
> >>>>
> >>>> Figure 1. OBI modeling of a single trial in the neuroscience
> study.
> >>>>
> >>>> Processes in this experimental trial are shown in bold
> (e.g., presentation
> >>>> of stimulus, neural activity in the caudate nucleus,
> stimulating monkey with
> >>>> light source), while terms for objects or roles (e.g., Macaca
> fuscata, study
> >>>> subject role, racellular electrophysiology recording) are
> shown in regular
> >>>> font with a black border, and relationships are shown in
> italics with no
> >>>> border (e.g., is_realized_by, has_specific_input).
> >>>>
> >>>> [add here: In
> >>>> this and subsequent figures, links between classes other than
> is_a
> >>>> represent all-some relations. Links between instance and
> class other
> >>>>
> >>>> than instance_of represent that the relation is to some
> (unspecified)
> >>>>
> >>>> instance of the class.]
> >>>>
> >>>> Diagrams with a dashed border such as those for the single
> unit recorder,
> >>>> the Japanese macace monkey, stimulating monkey with light
> source, or light
> >>>> on tangent screen indicate that those are instances of the
> ontological
> >>>> classes.
> >>>>
> >>>> Hi Larisa and all,
> >>>>
> >>>> I checked the figures again today. There are still some
> relations between
> >>>> class and instance left in the figures because the relation
> is not true as
> >>>> all-some. If possible, I'd like to take Alan's proposed
> action. However, add
> >>>> the explanation either in the text or in the legend for each
> figure.
> >>>>
> >>>> Proposed action: In the first figure caption add something
> like: "In
> >>>> this and subsequent figures, links between classes other than
> is_a
> >>>> represent all-some relations. Links between instance and
> class other
> >>>> than instance_of represent that the relation is to some
> (unspecified)
> >>>> instance of the class."
> >>>>
> >>>> Can we add this as one agenda item on next Monday's call?
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Jie
> >>>>
> >>>> Larisa Soldatova wrote:
> >>>>
> >>>> Hi Alan and All,
> >>>>
> >>>> I agree that it would be better to make those changes in
> figures. I believe
> >>>> that the Editors would accept new files, but it is not
> guaranteed.
> >>>>
> >>>> I suggest that we made those changes as soon as possible and
> no later than
> >>>> Monday, 22; and send new files to the Editors.
> >>>>
> >>>> Thank you,
> >>>>
> >>>> Larisa
> >>>>
> >>>>
> >>>> On 19 Feb 2010, at 00:10, Alan Ruttenberg wrote:
> >>>>
> >>>>
> >>>>
> >>>> Jonathan Rees, my colleague at Science Commons, had some good
> comments
> >>>>
> >>>> after reading the JBMS paper. The errors he points out are
> serious
> >>>>
> >>>> enough that I believe they should be corrected before
> publication.
> >>>>
> >>>> I've included Jonathan's comments, my response, and a
> proposed repair
> >>>>
> >>>> to the paper in each case.
> >>>>
> >>>>
> >>>> ---------- Forwarded message ----------
> >>>>
> >>>> From: Alan Ruttenberg <alanruttenberg@...
> <mailto:alanruttenberg@...>>
> >>>>
> >>>> Date: 2010/2/18
> >>>>
> >>>> Subject: Re: OBI figures
> >>>>
> >>>> To: Jonathan Rees <jar@...
> <mailto:jar@...>>
> >>>>
> >>>> Cc: "Danford, Timothy William" <TDANFORD@...
> <mailto:TDANFORD@...>>
> >>>>
> >>>>
> >>>> On Thu, Feb 18, 2010 at 10:57 PM, Jonathan Rees
> <jar@... <mailto:jar@...>
> >>>>
> >>>>
> >>>> wrote:
> >>>>
> >>>> Re
> >>>>
> >>>>
> >>
> http://obi.svn.sourceforge.net/viewvc/obi/trunk/docs/papers/JBMS_2009/JBMS2009_O
> >> BI-Final.pdf?revision=2678
> >>
> >>>> Figure 1: if you introduce an extra instance on each
> >>>>
> >>>> arc that connects an instance to a class (except not on
> instance_of
> >>>>
> >>>> arcs), and keep straight the fact that the same relation can
> be used
> >>>>
> >>>> between individuals and between classes (all/some lifting),
> it might
> >>>>
> >>>> make sense.
> >>>>
> >>>>
> >>>>
> >>>> The convention of using the same relation between classes and
> between
> >>>>
> >>>> instances is current practice, as is having relations between
> classes
> >>>>
> >>>> be interpreted as all-some, but should be clarified, I agree.
> Assuming
> >>>>
> >>>> that convention, and that the only relation between instances and
> >>>>
> >>>> classes is instance_of, I think there is only one node
> missing - that
> >>>>
> >>>> for the instance of subject study role. If we explain that
> >>>>
> >>>> instance-class relations (i r c) other than instance of
> represent i
> >>>>
> >>>> type (r some c) then we don't need that either.
> >>>>
> >>>> Proposed action: In the first figure caption add something
> like: "In
> >>>>
> >>>> this and subsequent figures, links between classes other than
> is_a
> >>>>
> >>>> represent all-some relations. Links between instance and
> class other
> >>>>
> >>>> than instance_of represent that the relation is to some
> (unspecified)
> >>>>
> >>>> instance of the class."
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> Figure 2: I think you can make sense of this by assuming
> *all* nodes
> >>>>
> >>>> are classes, and all arcs are all-some class relations.
> >>>>
> >>>> The only exception are the two putative instances, which
> don't make
> >>>>
> >>>> sense. If you change 'instance_of' to 'is_a' and alter the
> caption
> >>>>
> >>>> accordingly then it all makes sense (I think). To leave the
> instances
> >>>>
> >>>> as instances would require more significant surgery.
> >>>>
> >>>>
> >>>>
> >>>> I agree.
> >>>>
> >>>> Proposed action:
> >>>>
> >>>> 1) Change the two instance_of links to is_a links.
> >>>>
> >>>> 2) Remove the underlines.
> >>>>
> >>>> 3) Amend the caption text by removing "Two underlined terms
> are instances"
> >>>>
> >>>> 4) Use string quotes for "75%"
> >>>>
> >>>>
> >>>>
> >>>> Figure 3: If you change the color of every large box from blue to
> >>>>
> >>>> green
> >>>>
> >>>>
> >>>>
> >>>> Agreed.
> >>>>
> >>>>
> >>>>
> >>>> introduce an individual (green box) on the 'bearer_of' arc
> >>>>
> >>>> ending at 'netrient role',
> >>>>
> >>>>
> >>>>
> >>>> Also fix typo netrient -> nutrient.
> >>>>
> >>>> and similarly for bearer_of evaluant_role,
> >>>>
> >>>> I favor not introducing these instances and instead
> explaining as I
> >>>>
> >>>> suggested above, how instance -> class relations links should be
> >>>>
> >>>> understood.
> >>>>
> >>>> Proposed action: Change the large boxes from blue to green.
> >>>>
> >>>> s/netrient/nutrient/
> >>>>
> >>>>
> >>>>
> >>>> and if you equate the image of the tray of vials with the
> large bottom
> >>>>
> >>>> box '3 process: assay',
> >>>>
> >>>>
> >>>>
> >>>> That appears to be the intent. To make this clear the image
> should be
> >>>>
> >>>> moved into box 3.
> >>>>
> >>>> and change 'is_a' ending at 'hypothesis driven investigation' to
> >>>> 'instance_of',
> >>>>
> >>>> Agreed.
> >>>>
> >>>>
> >>>>
> >>>> and recognize as above that relations between individuals are
> sometimes
> >>>> lifted to relations between classes
> >>>>
> >>>>
> >>>>
> >>>> Explained that above. Class-class relations are understood in
> this way.
> >>>>
> >>>>
> >>>>
> >>>> and understand that graphical nesting of boxes doesn't mean
> anything at
> >>>> all,
> >>>>
> >>>>
> >>>>
> >>>> The outer boxes represent the process instances and
> containment is
> >>>>
> >>>> used to gather participants and relations to their types. I don't
> >>>>
> >>>> think that's problematic.
> >>>>
> >>>> Proposed actions:
> >>>>
> >>>> 1) Change the large boxes from blue to green.
> >>>>
> >>>> 2) s/netrient/nutrient/
> >>>>
> >>>> 3) change 'is_a' ending at 'hypothesis driven investigation' to
> >>>> 'instance_of'
> >>>>
> >>>> 4) Close boxes 2 and 3 and move the image of the test tubes to be
> >>>>
> >>>> contained in box 3.
> >>>>
> >>>>
> >>>> Thanks for taking the time to write up your observations!
> >>>>
> >>>> -Alan
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>
> ------------------------------------------------------------------------------
> >>
> >>>> Download Intel® Parallel Studio Eval
> >>>>
> >>>> Try the new software tools for yourself. Speed compiling,
> find bugs
> >>>>
> >>>> proactively, and fine-tune applications for parallel performance.
> >>>>
> >>>> See why Intel Parallel Studio got high marks during beta.
> >>>>
> >>>> http://p.sf.net/sfu/intel-sw-dev
> >>>>
> >>>> _______________________________________________
> >>>>
> >>>> Obi-devel mailing list
> >>>>
> >>>> Obi-devel@...
> <mailto:Obi-devel@...>
> >>>>
> >>>> https://lists.sourceforge.net/lists/listinfo/obi-devel
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>
> >>
> >>
> >> The information in this e-mail is intended only for the person
> to whom it is
> >> addressed. If you believe this e-mail was sent to you in error
> and the e-mail
> >> contains patient information, please contact the Partners
> Compliance HelpLine at
> >> http://www.partners.org/complianceline . If the e-mail was sent
> to you in error
> >> but does not contain patient information, please contact the
> sender and properly
> >> dispose of the e-mail.
> >>
> >>
> >>
>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Obi-devel mailing list
> Obi-devel@...
> <mailto:Obi-devel@...>
> https://lists.sourceforge.net/lists/listinfo/obi-devel
>
>
|