OBI

Hi, Alan,

The link you gave to JMBS paper is not the version that Larisa submitted 
in January. The figures have been changed, made consistent 
representation and all relations were linked either class to class or 
instance to instance. I attached the final version Larisa sent to me. 
She mentioned she had problem with svn. It may be the reason that she 
didn't commit the final version. All the figures were committed and I 
have sent email about it in the middle of January.

Could you please check whether the figures submitted in January is fine?

Thanks,

Jie

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@...>
> Date: 2010/2/18
> Subject: Re: OBI figures
> To: Jonathan Rees <jar@...>
> Cc: "Danford, Timothy William" <TDANFORD@...>
>
>
> On Thu, Feb 18, 2010 at 10:57 PM, Jonathan Rees <jar@...> wrote:
>   
>> Re http://obi.svn.sourceforge.net/viewvc/obi/trunk/docs/papers/JBMS_2009/JBMS2009_OBI-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&#174; 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@...
> https://lists.sourceforge.net/lists/listinfo/obi-devel
>

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@...>
> Date: 2010/2/18
> Subject: Re: OBI figures
> To: Jonathan Rees <jar@...>
> Cc: "Danford, Timothy William" <TDANFORD@...>
>
>
> On Thu, Feb 18, 2010 at 10:57 PM, Jonathan Rees <jar@... 
> > wrote:
>> Re http://obi.svn.sourceforge.net/viewvc/obi/trunk/docs/papers/JBMS_2009/JBMS2009_OBI-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

please ignore my previous message, I did not see Jie's one. She is  
right!

Larisa

> 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@...>
>> Date: 2010/2/18
>> Subject: Re: OBI figures
>> To: Jonathan Rees <jar@...>
>> Cc: "Danford, Timothy William" <TDANFORD@...>
>>
>>
>> On Thu, Feb 18, 2010 at 10:57 PM, Jonathan Rees <jar@...
>>> wrote:
>>> Re http://obi.svn.sourceforge.net/viewvc/obi/trunk/docs/papers/JBMS_2009/JBMS2009_OBI-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&#174; 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@...
> https://lists.sourceforge.net/lists/listinfo/obi-devel

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@...>
>> Date: 2010/2/18
>> Subject: Re: OBI figures
>> To: Jonathan Rees <jar@...>
>> Cc: "Danford, Timothy William" <TDANFORD@...>
>>
>>
>> On Thu, Feb 18, 2010 at 10:57 PM, Jonathan Rees <jar@... 
>>     
>>> wrote:
>>> Re http://obi.svn.sourceforge.net/viewvc/obi/trunk/docs/papers/JBMS_2009/JBMS2009_OBI-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&#174; 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@...
> https://lists.sourceforge.net/lists/listinfo/obi-devel
>

Jie,

ok, we can talk about that on the call.

Thanks,
Larisa


> 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@...>
>>> Date: 2010/2/18
>>> Subject: Re: OBI figures
>>> To: Jonathan Rees <jar@...>
>>> Cc: "Danford, Timothy William" <TDANFORD@...>
>>>
>>>
>>> On Thu, Feb 18, 2010 at 10:57 PM, Jonathan Rees <jar@...
>>>> wrote:
>>>> Re http://obi.svn.sourceforge.net/viewvc/obi/trunk/docs/papers/JBMS_2009/JBMS2009_OBI-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&#174; 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@...
>> https://lists.sourceforge.net/lists/listinfo/obi-devel
>>
>

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@...>
>>> Date: 2010/2/18
>>> Subject: Re: OBI figures
>>> To: Jonathan Rees <jar@...>
>>> Cc: "Danford, Timothy William" <TDANFORD@...>
>>>
>>>
>>> On Thu, Feb 18, 2010 at 10:57 PM, Jonathan Rees <jar@...
>>>> wrote:
>>>> Re http://obi.svn.sourceforge.net/viewvc/obi/trunk/docs/papers/JBMS_2009/JBMS2009_OBI-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&#174; 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@...
>> https://lists.sourceforge.net/lists/listinfo/obi-devel
>>
>

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@...> 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@...>
>
> Date: 2010/2/18
>
> Subject: Re: OBI figures
>
> To: Jonathan Rees <jar@...>
>
> Cc: "Danford, Timothy William" <TDANFORD@...>
>
>
> On Thu, Feb 18, 2010 at 10:57 PM, Jonathan Rees <jar@...
>
>
> wrote:
>
> Re
> http://obi.svn.sourceforge.net/viewvc/obi/trunk/docs/papers/JBMS_2009/JBMS2009_OBI-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&#174; 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@...
>
> https://lists.sourceforge.net/lists/listinfo/obi-devel
>
>
>
>
>

Forwarded to the list by me until TIm gets subscribed.
-Alan


---------- Forwarded message ----------
From: Danford, Timothy William <TDANFORD@...>
Date: Tue, Feb 23, 2010 at 11:43 AM
Subject: RE: [Obi-devel] OBI figures in JMBS papers
To: Larisa Soldatova <lss@...>, Jie Zheng <jiezheng@...>
Cc: Alan Ruttenberg <alanruttenberg@...>, Jonathan Rees
<jar@...>, OBI Developers
<obi-devel@...>, Yongqun He <yongqunh@...>


Hi Larisa,

My name is Timothy -- I've been working with Jonathan and Alan at Science
Commons, and Alan included me on his original email forward Jonathan's comments
about the figures from the OBI JBMS paper.

I had three additional comments that you may (or may not) find useful:

(1) In Figure 3, it looks like there's a mistake on the left side (at least in
the version I saw).  The figure has an "is_realized_by" arrow between a
'planning' class and a 'plan specification' class.  However, my reading of OBI
is that (a) this should be "realizes" (in other words, the arrow is going in the
wrong direction) and (b) there should be another individual between the planning
process and the plan specification.  The 'planning' process is a 'planned
process', which should realize something that is a concretization of
('is_concretization_of') a plan specification.

(2) In Figure 2, I'm confused as to why the syringe has two *separate* injection
functions that are realized by the two different processes (pathogen challenge
and vaccination), but the mouse individual has a *single* 'target of material
addition role' that is jointly realized by both processes.  Shouldn't there be
two 'target of material addition role' boxes, one for each process to realize?

(3) In the latest version of the figures I saw, several individuals seem to not
be linked to any class through an 'instance_of' arrow -- for example, the
Influenza Virus individual in figure 2, and the metabolite individual in figure
3.  Should those have classes indicated?

Thank you for reading these comments, and for creating the figures overall.
Alan forwarded an earlier version of the paper to me, and it's been very useful
and enlightening to read through it.

Best,

Timothy Danford



Timothy Danford
Bioinformatics Engineer, Neurology Research, MGH
tdanford@...



-----Original Message-----
From: Larisa Soldatova [mailto:lss@...]
Sent: Tue 2/23/2010 10:39 AM
To: Jie Zheng
Cc: Alan Ruttenberg; Jonathan Rees; OBI Developers; Danford, Timothy William;
Yongqun He
Subject: Re: [Obi-devel] OBI figures in JMBS papers

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@...>
>>> Date: 2010/2/18
>>> Subject: Re: OBI figures
>>> To: Jonathan Rees <jar@...>
>>> Cc: "Danford, Timothy William" <TDANFORD@...>
>>>
>>>
>>> On Thu, Feb 18, 2010 at 10:57 PM, Jonathan Rees <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@...
>> 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.

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/automated 
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@...> 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@...>
>>
>> Date: 2010/2/18
>>
>> Subject: Re: OBI figures
>>
>> To: Jonathan Rees <jar@...>
>>
>> Cc: "Danford, Timothy William" <TDANFORD@...>
>>
>>
>> On Thu, Feb 18, 2010 at 10:57 PM, Jonathan Rees <jar@...
>>
>>
>> wrote:
>>
>> Re
>> http://obi.svn.sourceforge.net/viewvc/obi/trunk/docs/papers/JBMS_2009/JBMS2009_OBI-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&#174; 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@...
>>
>> https://lists.sourceforge.net/lists/listinfo/obi-devel
>>
>>
>>
>>
>>
>>

Hi Timothy,

Thanks you very much for carefully reviewing the figures in JBMS paper. 
I was working on making consistent representation of the figures. So, I 
will try to add some comments on the issues you mentioned. See the 
comments inline.

Danford, Timothy William wrote:
> Hi Larisa, 
>
> My name is Timothy -- I've been working with Jonathan and Alan at Science
> Commons, and Alan included me on his original email forward Jonathan's comments
> about the figures from the OBI JBMS paper.  
>
> I had three additional comments that you may (or may not) find useful: 
>
> (1) In Figure 3, it looks like there's a mistake on the left side (at least in
> the version I saw).  The figure has an "is_realized_by" arrow between a
> 'planning' class and a 'plan specification' class.  However, my reading of OBI
> is that (a) this should be "realizes" (in other words, the arrow is going in the
> wrong direction) and (b) there should be another individual between the planning
> process and the plan specification.  The 'planning' process is a 'planned
> process', which should realize something that is a concretization of
> ('is_concretization_of') a plan specification.
You are right. It may be easily fixed by changing the relation to: 
'planning' has_specified_output 'plan specification'.
>   
>
> (2) In Figure 2, I'm confused as to why the syringe has two *separate* injection
> functions that are realized by the two different processes (pathogen challenge
> and vaccination), but the mouse individual has a *single* 'target of material
> addition role' that is jointly realized by both processes.  Shouldn't there be
> two 'target of material addition role' boxes, one for each process to realize? 
>
>   
When I looked at the figure, I think it is OK. I thought it may due to 
easily draw the figures since class 'injection function' was added just 
before we submitted the paper. I did the same thing when I drew the 
diagram for making it easily to be read. However, I don't know whether 
it is correct way to do. In the figure2, actually 'host role' in the 
same situation.
> (3) In the latest version of the figures I saw, several individuals seem to not
> be linked to any class through an 'instance_of' arrow -- for example, the
> Influenza Virus individual in figure 2, and the metabolite individual in figure
> 3.  Should those have classes indicated?  
>   
It may be better in Figure 3, add 'metabolite C00449' is instance_of 
'molecular entity'. In Figure2, add 'Influenza Virus' is instance_of  
'Virus'. As you pointed out in another email. In the Figure 2, we should 
change instance 'mouse' is_a  'organism' to 'mouse' is instance_of 
'organism or individual 'mouse' is instance_of 'Mus musculus' and 'Mus 
musculus' is_a 'organism'.
> Thank you for reading these comments, and for creating the figures overall.
> Alan forwarded an earlier version of the paper to me, and it's been very useful
> and enlightening to read through it. 
>
> Best,
>
> Timothy Danford
>
>
>
> Timothy Danford
> Bioinformatics Engineer, Neurology Research, MGH
> tdanford@...
>   
Thanks,

Jie
>
>
> -----Original Message-----
> From: Larisa Soldatova [mailto:lss@...]
> Sent: Tue 2/23/2010 10:39 AM
> To: Jie Zheng
> Cc: Alan Ruttenberg; Jonathan Rees; OBI Developers; Danford, Timothy William;
> Yongqun He
> Subject: Re: [Obi-devel] OBI figures in JMBS papers
>  
> 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@...>
>>>> Date: 2010/2/18
>>>> Subject: Re: OBI figures
>>>> To: Jonathan Rees <jar@...>
>>>> Cc: "Danford, Timothy William" <TDANFORD@...>
>>>>
>>>>
>>>> On Thu, Feb 18, 2010 at 10:57 PM, Jonathan Rees <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@...
>>> 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.
>
>

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.

(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.

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...?

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




> -----Original Message-----
> From: Jie Zheng [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@...> 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@...>
>>>
>>> Date: 2010/2/18
>>>
>>> Subject: Re: OBI figures
>>>
>>> To: Jonathan Rees <jar@...>
>>>
>>> Cc: "Danford, Timothy William" <TDANFORD@...>
>>>
>>>
>>> On Thu, Feb 18, 2010 at 10:57 PM, Jonathan Rees <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@...
>>>
>>> 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.
>
>

Hi All,

thank you to Timothy for reviewing our paper. Unfortunately it might be
too late. I really can not predict how the editors would react on a
request to make several changes. I hoped that we can try to change
captions of figures (1 file). But if we need to change the figures (they
are in separate files) we have to request to change all our submission.
Maybe it is better to wait for proofs and try to do it on that stage.



>> (1) In Figure 3, ...
> You are right. It may be easily fixed by changing the relation to:
> 'planning' has_specified_output 'plan specification'.

OK, I will do that tomorrow (It is already late in UK)


>> (3) In the latest version of the figures I saw, several individuals seem
>> to not
>> be linked to any class through an 'instance_of' arrow -- for example,
>> the
>> Influenza Virus individual in figure 2, and the metabolite individual in
>> figure
>> 3.  Should those have classes indicated?
>>
> It may be better in Figure 3, add 'metabolite C00449' is instance_of
> 'molecular entity'. In Figure2, add 'Influenza Virus' is instance_of
> 'Virus'. As you pointed out in another email. In the Figure 2, we should
> change instance 'mouse' is_a  'organism' to 'mouse' is instance_of
> 'organism or individual 'mouse' is instance_of 'Mus musculus' and 'Mus
> musculus' is_a 'organism'.

The figures show only fragments, we can not include all relations into
diagrams as they are already complicated and we were criticized for that.
I would refrain from making such sort of changes at this stage. There is
nothing wrong with those relations, and short-cuts are logically correct.
But we definitely should take this point of view (what relations to show
in figures) into account for the main OBI paper.

Larisa

Hi Larisa,

Agree with you. If we can change the relation between 'planning' and 
'plan specification' should be good enough now.

Thanks a lot for making the modification on figure/legend and trying to 
make it taken by the editors.

Jie

lss@... wrote:
>  Hi All,
>
> thank you to Timothy for reviewing our paper. Unfortunately it might be
> too late. I really can not predict how the editors would react on a
> request to make several changes. I hoped that we can try to change
> captions of figures (1 file). But if we need to change the figures (they
> are in separate files) we have to request to change all our submission.
> Maybe it is better to wait for proofs and try to do it on that stage.
>
>
>
>   
>>> (1) In Figure 3, ...
>>>       
>> You are right. It may be easily fixed by changing the relation to:
>> 'planning' has_specified_output 'plan specification'.
>>     
>
> OK, I will do that tomorrow (It is already late in UK)
>
>
>   
>>> (3) In the latest version of the figures I saw, several individuals seem
>>> to not
>>> be linked to any class through an 'instance_of' arrow -- for example,
>>> the
>>> Influenza Virus individual in figure 2, and the metabolite individual in
>>> figure
>>> 3.  Should those have classes indicated?
>>>
>>>       
>> It may be better in Figure 3, add 'metabolite C00449' is instance_of
>> 'molecular entity'. In Figure2, add 'Influenza Virus' is instance_of
>> 'Virus'. As you pointed out in another email. In the Figure 2, we should
>> change instance 'mouse' is_a  'organism' to 'mouse' is instance_of
>> 'organism or individual 'mouse' is instance_of 'Mus musculus' and 'Mus
>> musculus' is_a 'organism'.
>>     
>
> The figures show only fragments, we can not include all relations into
> diagrams as they are already complicated and we were criticized for that.
> I would refrain from making such sort of changes at this stage. There is
> nothing wrong with those relations, and short-cuts are logically correct.
> But we definitely should take this point of view (what relations to show
> in figures) into account for the main OBI paper.
>
> Larisa
>

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@...]
>> 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@...> 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@...>
>>>>
>>>> Date: 2010/2/18
>>>>
>>>> Subject: Re: OBI figures
>>>>
>>>> To: Jonathan Rees <jar@...>
>>>>
>>>> Cc: "Danford, Timothy William" <TDANFORD@...>
>>>>
>>>>
>>>> On Thu, Feb 18, 2010 at 10:57 PM, Jonathan Rees <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@...
>>>>
>>>> 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.
>>
>>
>>

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@...>

> 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@...]
> >> 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@...>
> 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@...>
> >>>>
> >>>> Date: 2010/2/18
> >>>>
> >>>> Subject: Re: OBI figures
> >>>>
> >>>> To: Jonathan Rees <jar@...>
> >>>>
> >>>> Cc: "Danford, Timothy William" <TDANFORD@...>
> >>>>
> >>>>
> >>>> On Thu, Feb 18, 2010 at 10:57 PM, Jonathan Rees <
> 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@...
> >>>>
> >>>> 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&#174; 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@...
> https://lists.sourceforge.net/lists/listinfo/obi-devel
>

Hi All,

I plan to ask the Editors today if it is possible to make changes in  
the submitted a month ago final version.
If the answer is positive (and I am not sure in it at all), I suggest  
that we put the updated figures online and provide links to them in  
the paper's text. We can explain that the figures in the paper reflect  
our vision in November 2009, but the on-line figures correspond to the  
latest state. In this way, we always can make changes if we need to  
(and something tells me that we will).

Larisa



> 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@...>  
> 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@...>
>>
>> Date: 2010/2/18
>>
>> Subject: Re: OBI figures
>>
>> To: Jonathan Rees <jar@...>
>>
>> Cc: "Danford, Timothy William" <TDANFORD@...>
>>
>>
>> On Thu, Feb 18, 2010 at 10:57 PM, Jonathan Rees <jar@...
>>
>>
>> wrote:
>>
>> Re
>> http://obi.svn.sourceforge.net/viewvc/obi/trunk/docs/papers/JBMS_2009/JBMS2009_OBI-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&#174; 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@...
>>
>> https://lists.sourceforge.net/lists/listinfo/obi-devel
>>
>>
>>
>>
>>

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&#174; 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
>
>

Hi All,

I got a reply from the Editors. The permitted to make changes in the  
figures if we do it quickly.

I will update fig. 3 as proposed. It would be great if someone can  
take care about other figures: I have very heavy teaching load now and  
cannot do anything extra.

I wish to have your opinion on my suggestion to figures online and  
give links to them in the paper.

Thank you,
Larisa


> Hi Larisa,
>
> Agree with you. If we can change the relation between 'planning' and  
> 'plan specification' should be good enough now.
>
> Thanks a lot for making the modification on figure/legend and trying  
> to make it taken by the editors.
>
> Jie
>
> lss@... wrote:
>> Hi All,
>>
>> thank you to Timothy for reviewing our paper. Unfortunately it  
>> might be
>> too late. I really can not predict how the editors would react on a
>> request to make several changes. I hoped that we can try to change
>> captions of figures (1 file). But if we need to change the figures  
>> (they
>> are in separate files) we have to request to change all our  
>> submission.
>> Maybe it is better to wait for proofs and try to do it on that stage.
>>
>>
>>
>>
>>>> (1) In Figure 3, ...
>>>>
>>> You are right. It may be easily fixed by changing the relation to:
>>> 'planning' has_specified_output 'plan specification'.
>>>
>>
>> OK, I will do that tomorrow (It is already late in UK)
>>
>>
>>
>>>> (3) In the latest version of the figures I saw, several  
>>>> individuals seem
>>>> to not
>>>> be linked to any class through an 'instance_of' arrow -- for  
>>>> example,
>>>> the
>>>> Influenza Virus individual in figure 2, and the metabolite  
>>>> individual in
>>>> figure
>>>> 3.  Should those have classes indicated?
>>>>
>>>>
>>> It may be better in Figure 3, add 'metabolite C00449' is instance_of
>>> 'molecular entity'. In Figure2, add 'Influenza Virus' is instance_of
>>> 'Virus'. As you pointed out in another email. In the Figure 2, we  
>>> should
>>> change instance 'mouse' is_a  'organism' to 'mouse' is instance_of
>>> 'organism or individual 'mouse' is instance_of 'Mus musculus' and  
>>> 'Mus
>>> musculus' is_a 'organism'.
>>>
>>
>> The figures show only fragments, we can not include all relations  
>> into
>> diagrams as they are already complicated and we were criticized for  
>> that.
>> I would refrain from making such sort of changes at this stage.  
>> There is
>> nothing wrong with those relations, and short-cuts are logically  
>> correct.
>> But we definitely should take this point of view (what relations to  
>> show
>> in figures) into account for the main OBI paper.
>>
>> Larisa
>>
>

Hi All,

I think we don't need to make any modification for Figure 1 except 
adding Alan proposed text.

In Figure2, add 'Influenza Virus' is instance_of  'Virus'. We should 
change instance 'mouse' is_a  'organism' to 'mouse' is instance_of 
'organism or individual 'mouse' is instance_of 'Mus musculus' and 'Mus 
musculus' is_a 'organism'. Figure2 was drawn using Visio, I cannot help 
to modify it. Oliver, can you update it?

Could someone else check any other changes we should make in the figures?

Thanks,

Jie



Larisa Soldatova wrote:
> Hi All,
>
> I got a reply from the Editors. The permitted to make changes in the 
> figures if we do it quickly.
>
> I will update fig. 3 as proposed. It would be great if someone can 
> take care about other figures: I have very heavy teaching load now and 
> cannot do anything extra.
>
> I wish to have your opinion on my suggestion to figures online and 
> give links to them in the paper.
>
> Thank you,
> Larisa
>
>
>> Hi Larisa,
>>
>> Agree with you. If we can change the relation between 'planning' and 
>> 'plan specification' should be good enough now.
>>
>> Thanks a lot for making the modification on figure/legend and trying 
>> to make it taken by the editors.
>>
>> Jie
>>
>> lss@... wrote:
>>> Hi All,
>>>
>>> thank you to Timothy for reviewing our paper. Unfortunately it might be
>>> too late. I really can not predict how the editors would react on a
>>> request to make several changes. I hoped that we can try to change
>>> captions of figures (1 file). But if we need to change the figures 
>>> (they
>>> are in separate files) we have to request to change all our submission.
>>> Maybe it is better to wait for proofs and try to do it on that stage.
>>>
>>>
>>>
>>>
>>>>> (1) In Figure 3, ...
>>>>>
>>>> You are right. It may be easily fixed by changing the relation to:
>>>> 'planning' has_specified_output 'plan specification'.
>>>>
>>>
>>> OK, I will do that tomorrow (It is already late in UK)
>>>
>>>
>>>
>>>>> (3) In the latest version of the figures I saw, several 
>>>>> individuals seem
>>>>> to not
>>>>> be linked to any class through an 'instance_of' arrow -- for example,
>>>>> the
>>>>> Influenza Virus individual in figure 2, and the metabolite 
>>>>> individual in
>>>>> figure
>>>>> 3.  Should those have classes indicated?
>>>>>
>>>>>
>>>> It may be better in Figure 3, add 'metabolite C00449' is instance_of
>>>> 'molecular entity'. In Figure2, add 'Influenza Virus' is instance_of
>>>> 'Virus'. As you pointed out in another email. In the Figure 2, we 
>>>> should
>>>> change instance 'mouse' is_a  'organism' to 'mouse' is instance_of
>>>> 'organism or individual 'mouse' is instance_of 'Mus musculus' and 'Mus
>>>> musculus' is_a 'organism'.
>>>>
>>>
>>> The figures show only fragments, we can not include all relations into
>>> diagrams as they are already complicated and we were criticized for 
>>> that.
>>> I would refrain from making such sort of changes at this stage. 
>>> There is
>>> nothing wrong with those relations, and short-cuts are logically 
>>> correct.
>>> But we definitely should take this point of view (what relations to 
>>> show
>>> in figures) into account for the main OBI paper.
>>>
>>> Larisa
>>>
>>

On Thu, Feb 25, 2010 at 9:11 AM, Jie Zheng <jiezheng@...> wrote:
> Hi All,
>
> I think we don't need to make any modification for Figure 1 except adding
> Alan proposed text.

I think we probably to. At least part_of -> has_part if we represent
these as class-class relations.
But I am inclined to remove the class/instance distinction altogether
as has been suggested and include explanatory text. We'll see what it
turns out to be - will offer it up for review when I have something.

>
> In Figure2, add 'Influenza Virus' is instance_of  'Virus'. We should change
> instance 'mouse' is_a  'organism' to 'mouse' is instance_of 'organism or
> individual 'mouse' is instance_of 'Mus musculus' and 'Mus musculus' is_a
> 'organism'. Figure2 was drawn using Visio, I cannot help to modify it.
> Oliver, can you update it?
>
> Could someone else check any other changes we should make in the figures?
>
> Thanks,
>
> Jie
>
>
>
> Larisa Soldatova wrote:
>>
>> Hi All,
>>
>> I got a reply from the Editors. The permitted to make changes in the
>> figures if we do it quickly.
>>
>> I will update fig. 3 as proposed. It would be great if someone can take
>> care about other figures: I have very heavy teaching load now and cannot do
>> anything extra.
>>
>> I wish to have your opinion on my suggestion to figures online and give
>> links to them in the paper.
>>
>> Thank you,
>> Larisa
>>
>>
>>> Hi Larisa,
>>>
>>> Agree with you. If we can change the relation between 'planning' and
>>> 'plan specification' should be good enough now.
>>>
>>> Thanks a lot for making the modification on figure/legend and trying to
>>> make it taken by the editors.
>>>
>>> Jie
>>>
>>> lss@... wrote:
>>>>
>>>> Hi All,
>>>>
>>>> thank you to Timothy for reviewing our paper. Unfortunately it might be
>>>> too late. I really can not predict how the editors would react on a
>>>> request to make several changes. I hoped that we can try to change
>>>> captions of figures (1 file). But if we need to change the figures (they
>>>> are in separate files) we have to request to change all our submission.
>>>> Maybe it is better to wait for proofs and try to do it on that stage.
>>>>
>>>>
>>>>
>>>>
>>>>>> (1) In Figure 3, ...
>>>>>>
>>>>> You are right. It may be easily fixed by changing the relation to:
>>>>> 'planning' has_specified_output 'plan specification'.
>>>>>
>>>>
>>>> OK, I will do that tomorrow (It is already late in UK)
>>>>
>>>>
>>>>
>>>>>> (3) In the latest version of the figures I saw, several individuals
>>>>>> seem
>>>>>> to not
>>>>>> be linked to any class through an 'instance_of' arrow -- for example,
>>>>>> the
>>>>>> Influenza Virus individual in figure 2, and the metabolite individual
>>>>>> in
>>>>>> figure
>>>>>> 3.  Should those have classes indicated?
>>>>>>
>>>>>>
>>>>> It may be better in Figure 3, add 'metabolite C00449' is instance_of
>>>>> 'molecular entity'. In Figure2, add 'Influenza Virus' is instance_of
>>>>> 'Virus'. As you pointed out in another email. In the Figure 2, we
>>>>> should
>>>>> change instance 'mouse' is_a  'organism' to 'mouse' is instance_of
>>>>> 'organism or individual 'mouse' is instance_of 'Mus musculus' and 'Mus
>>>>> musculus' is_a 'organism'.
>>>>>
>>>>
>>>> The figures show only fragments, we can not include all relations into
>>>> diagrams as they are already complicated and we were criticized for
>>>> that.
>>>> I would refrain from making such sort of changes at this stage. There is
>>>> nothing wrong with those relations, and short-cuts are logically
>>>> correct.
>>>> But we definitely should take this point of view (what relations to show
>>>> in figures) into account for the main OBI paper.
>>>>
>>>> Larisa
>>>>
>>>
>
>

Hi Jie,
I have updated Figure 2 as you instructed. The updated figure is committed to the SVN. Please check it out and let me know if more changes are needed.
Thanks!
Oliver

>>> Jie Zheng <jiezheng@...> 2/25/2010 9:11 AM >>>
Hi All,

I think we don't need to make any modification for Figure 1 except 
adding Alan proposed text.

In Figure2, add 'Influenza Virus' is instance_of  'Virus'. We should 
change instance 'mouse' is_a  'organism' to 'mouse' is instance_of 
'organism or individual 'mouse' is instance_of 'Mus musculus' and 'Mus 
musculus' is_a 'organism'. Figure2 was drawn using Visio, I cannot help 
to modify it. Oliver, can you update it?

Could someone else check any other changes we should make in the figures?

Thanks,

Jie



Larisa Soldatova wrote:
> Hi All,
>
> I got a reply from the Editors. The permitted to make changes in the 
> figures if we do it quickly.
>
> I will update fig. 3 as proposed. It would be great if someone can 
> take care about other figures: I have very heavy teaching load now and 
> cannot do anything extra.
>
> I wish to have your opinion on my suggestion to figures online and 
> give links to them in the paper.
>
> Thank you,
> Larisa
>
>
>> Hi Larisa,
>>
>> Agree with you. If we can change the relation between 'planning' and 
>> 'plan specification' should be good enough now.
>>
>> Thanks a lot for making the modification on figure/legend and trying 
>> to make it taken by the editors.
>>
>> Jie
>>
>> lss@... wrote:
>>> Hi All,
>>>
>>> thank you to Timothy for reviewing our paper. Unfortunately it might be
>>> too late. I really can not predict how the editors would react on a
>>> request to make several changes. I hoped that we can try to change
>>> captions of figures (1 file). But if we need to change the figures 
>>> (they
>>> are in separate files) we have to request to change all our submission.
>>> Maybe it is better to wait for proofs and try to do it on that stage.
>>>
>>>
>>>
>>>
>>>>> (1) In Figure 3, ...
>>>>>
>>>> You are right. It may be easily fixed by changing the relation to:
>>>> 'planning' has_specified_output 'plan specification'.
>>>>
>>>
>>> OK, I will do that tomorrow (It is already late in UK)
>>>
>>>
>>>
>>>>> (3) In the latest version of the figures I saw, several 
>>>>> individuals seem
>>>>> to not
>>>>> be linked to any class through an 'instance_of' arrow -- for example,
>>>>> the
>>>>> Influenza Virus individual in figure 2, and the metabolite 
>>>>> individual in
>>>>> figure
>>>>> 3.  Should those have classes indicated?
>>>>>
>>>>>
>>>> It may be better in Figure 3, add 'metabolite C00449' is instance_of
>>>> 'molecular entity'. In Figure2, add 'Influenza Virus' is instance_of
>>>> 'Virus'. As you pointed out in another email. In the Figure 2, we 
>>>> should
>>>> change instance 'mouse' is_a  'organism' to 'mouse' is instance_of
>>>> 'organism or individual 'mouse' is instance_of 'Mus musculus' and 'Mus
>>>> musculus' is_a 'organism'.
>>>>
>>>
>>> The figures show only fragments, we can not include all relations into
>>> diagrams as they are already complicated and we were criticized for 
>>> that.
>>> I would refrain from making such sort of changes at this stage. 
>>> There is
>>> nothing wrong with those relations, and short-cuts are logically 
>>> correct.
>>> But we definitely should take this point of view (what relations to 
>>> show
>>> in figures) into account for the main OBI paper.
>>>
>>> Larisa
>>>
>>


**********************************************************
Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues

Hi Oliver,

Thanks a lot for updating the figure 2.

I looked the updated figure. You have changed all the issues I mentioned.

Here are two additional issues were addressed in the previous email 
discussion with Timothy and Alan. You may consider whether we should 
change it or not.
1. There are two 'injection function' linked to 'syringe' which is 
realized by 'vaccination' and 'pathogen challenge' processes. However, 
others like, 'host role', 'target of material addition role' only shown 
once in the figure. Did two 'injection function' classes mean differently?
2. 'material to be added role' inheres_in 'vaccine', 'VacX' is 
instance_of 'vaccine'. Are all instances of 'vaccine' bearer_of 
'material to be added role' or  only some of 'vaccine' instance, such as 
'VacX', bearer_of 'material to be added role'?  I think the one  shown 
in figure represent the first meaning. If in the text description means 
the second option, we may need to change the figure.

Since I don't have much time working on it, the changes I pointed out 
were what I thought we should make. Hope somebody else can check out 
whether anything else need to be updated.

Thanks,

Jie


Yongqun He wrote:
> Hi Jie,
> I have updated Figure 2 as you instructed. The updated figure is 
> committed to the SVN. Please check it out and let me know if more 
> changes are needed.
> Thanks!
> Oliver
>
> >>> Jie Zheng <jiezheng@...> 2/25/2010 9:11 AM >>>
> Hi All,
>
> I think we don't need to make any modification for Figure 1 except
> adding Alan proposed text.
>
> In Figure2, add 'Influenza Virus' is instance_of  'Virus'. We should
> change instance 'mouse' is_a  'organism' to 'mouse' is instance_of
> 'organism or individual 'mouse' is instance_of 'Mus musculus' and 'Mus
> musculus' is_a 'organism'. Figure2 was drawn using Visio, I cannot help
> to modify it. Oliver, can you update it?
>
> Could someone else check any other changes we should make in the figures?
>
> Thanks,
>
> Jie
>
>
>
> Larisa Soldatova wrote:
> > Hi All,
> >
> > I got a reply from the Editors. The permitted to make changes in the
> > figures if we do it quickly.
> >
> > I will update fig. 3 as proposed. It would be great if someone can
> > take care about other figures: I have very heavy teaching load now and
> > cannot do anything extra.
> >
> > I wish to have your opinion on my suggestion to figures online and
> > give links to them in the paper.
> >
> > Thank you,
> > Larisa
> >
> >
> >> Hi Larisa,
> >>
> >> Agree with you. If we can change the relation between 'planning' and
> >> 'plan specification' should be good enough now.
> >>
> >> Thanks a lot for making the modification on figure/legend and trying
> >> to make it taken by the editors.
> >>
> >> Jie
> >>
> >> lss@... wrote:
> >>> Hi All,
> >>>
> >>> thank you to Timothy for reviewing our paper. Unfortunately it 
> might be
> >>> too late. I really can not predict how the editors would react on a
> >>> request to make several changes. I hoped that we can try to change
> >>> captions of figures (1 file). But if we need to change the figures
> >>> (they
> >>> are in separate files) we have to request to change all our 
> submission.
> >>> Maybe it is better to wait for proofs and try to do it on that stage.
> >>>
> >>>
> >>>
> >>>
> >>>>> (1) In Figure 3, ...
> >>>>>
> >>>> You are right. It may be easily fixed by changing the relation to:
> >>>> 'planning' has_specified_output 'plan specification'.
> >>>>
> >>>
> >>> OK, I will do that tomorrow (It is already late in UK)
> >>>
> >>>
> >>>
> >>>>> (3) In the latest version of the figures I saw, several
> >>>>> individuals seem
> >>>>> to not
> >>>>> be linked to any class through an 'instance_of' arrow -- for 
> example,
> >>>>> the
> >>>>> Influenza Virus individual in figure 2, and the metabolite
> >>>>> individual in
> >>>>> figure
> >>>>> 3.  Should those have classes indicated?
> >>>>>
> >>>>>
> >>>> It may be better in Figure 3, add 'metabolite C00449' is instance_of
> >>>> 'molecular entity'. In Figure2, add 'Influenza Virus' is instance_of
> >>>> 'Virus'. As you pointed out in another email. In the Figure 2, we
> >>>> should
> >>>> change instance 'mouse' is_a  'organism' to 'mouse' is instance_of
> >>>> 'organism or individual 'mouse' is instance_of 'Mus musculus' and 
> 'Mus
> >>>> musculus' is_a 'organism'.
> >>>>
> >>>
> >>> The figures show only fragments, we can not include all relations into
> >>> diagrams as they are already complicated and we were criticized for
> >>> that.
> >>> I would refrain from making such sort of changes at this stage.
> >>> There is
> >>> nothing wrong with those relations, and short-cuts are logically
> >>> correct.
> >>> But we definitely should take this point of view (what relations to
> >>> show
> >>> in figures) into account for the main OBI paper.
> >>>
> >>> Larisa
> >>>
> >>
>
>
> **********************************************************
> Electronic Mail is not secure, may not be read every day, and should 
> not be used for urgent or sensitive issues

Attached is an alternative arrangement of the neuroscience use case
for consideration. I have made the following changes:

Each box now represents an individual, either explicitly named, or
not. All links in the diagram are to be understood as relations
between instances. Some are inferred, some explicitly asserted.

Explicitly named instances have typographically distinguished names -
they are suffixed with a number, and in monospace font. Their type is
noted as "instance of <class name>".

Un-named instances simply have their class name in the box. All class
names are bold face.

I have added some participation and realization relations that exist
but were not stated, that I hope clarify some relationships.

I realize this may be more changes than were expected, but this seems
like the simplest change that avoids the confusion of having to
explain how to interpret a mixture of  class-class and
instance-instance relations in the same diagram.

If this approach to diagramming addressed the issue of clarity, and is
considered acceptable to the other authors, I can have a go at
adjusting the other two figures to follow the same style, and to add a
couple of sentences explaining how to read the figures.

Jonathan, Tim, could you comment on whether this approach addresses
your concerns about clarity?
Co-authors, could you weigh in on whether we should go with this
approach or have another go at it.

Thanks,

-Alan



On Thu, Feb 25, 2010 at 7:14 PM, jie zheng <jiezheng@...> wrote:
> Hi Oliver,
>
> Thanks a lot for updating the figure 2.
>
> I looked the updated figure. You have changed all the issues I mentioned.
>
> Here are two additional issues were addressed in the previous email
> discussion with Timothy and Alan. You may consider whether we should change
> it or not.
> 1. There are two 'injection function' linked to 'syringe' which is realized
> by 'vaccination' and 'pathogen challenge' processes. However, others like,
> 'host role', 'target of material addition role' only shown once in the
> figure. Did two 'injection function' classes mean differently?
> 2. 'material to be added role' inheres_in 'vaccine', 'VacX' is instance_of
> 'vaccine'. Are all instances of 'vaccine' bearer_of 'material to be added
> role' or  only some of 'vaccine' instance, such as 'VacX', bearer_of
> 'material to be added role'?  I think the one  shown in figure represent the
> first meaning. If in the text description means the second option, we may
> need to change the figure.
>
> Since I don't have much time working on it, the changes I pointed out were
> what I thought we should make. Hope somebody else can check out whether
> anything else need to be updated.
>
> Thanks,
>
> Jie
>
>
> Yongqun He wrote:
>>
>> Hi Jie,
>> I have updated Figure 2 as you instructed. The updated figure is committed
>> to the SVN. Please check it out and let me know if more changes are needed.
>> Thanks!
>> Oliver
>>
>> >>> Jie Zheng <jiezheng@...> 2/25/2010 9:11 AM >>>
>> Hi All,
>>
>> I think we don't need to make any modification for Figure 1 except
>> adding Alan proposed text.
>>
>> In Figure2, add 'Influenza Virus' is instance_of  'Virus'. We should
>> change instance 'mouse' is_a  'organism' to 'mouse' is instance_of
>> 'organism or individual 'mouse' is instance_of 'Mus musculus' and 'Mus
>> musculus' is_a 'organism'. Figure2 was drawn using Visio, I cannot help
>> to modify it. Oliver, can you update it?
>>
>> Could someone else check any other changes we should make in the figures?
>>
>> Thanks,
>>
>> Jie
>>
>>
>>
>> Larisa Soldatova wrote:
>> > Hi All,
>> >
>> > I got a reply from the Editors. The permitted to make changes in the
>> > figures if we do it quickly.
>> >
>> > I will update fig. 3 as proposed. It would be great if someone can
>> > take care about other figures: I have very heavy teaching load now and
>> > cannot do anything extra.
>> >
>> > I wish to have your opinion on my suggestion to figures online and
>> > give links to them in the paper.
>> >
>> > Thank you,
>> > Larisa
>> >
>> >
>> >> Hi Larisa,
>> >>
>> >> Agree with you. If we can change the relation between 'planning' and
>> >> 'plan specification' should be good enough now.
>> >>
>> >> Thanks a lot for making the modification on figure/legend and trying
>> >> to make it taken by the editors.
>> >>
>> >> Jie
>> >>
>> >> lss@... wrote:
>> >>> Hi All,
>> >>>
>> >>> thank you to Timothy for reviewing our paper. Unfortunately it might
>> >>> be
>> >>> too late. I really can not predict how the editors would react on a
>> >>> request to make several changes. I hoped that we can try to change
>> >>> captions of figures (1 file). But if we need to change the figures
>> >>> (they
>> >>> are in separate files) we have to request to change all our
>> >>> submission.
>> >>> Maybe it is better to wait for proofs and try to do it on that stage.
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>>> (1) In Figure 3, ...
>> >>>>>
>> >>>> You are right. It may be easily fixed by changing the relation to:
>> >>>> 'planning' has_specified_output 'plan specification'.
>> >>>>
>> >>>
>> >>> OK, I will do that tomorrow (It is already late in UK)
>> >>>
>> >>>
>> >>>
>> >>>>> (3) In the latest version of the figures I saw, several
>> >>>>> individuals seem
>> >>>>> to not
>> >>>>> be linked to any class through an 'instance_of' arrow -- for
>> >>>>> example,
>> >>>>> the
>> >>>>> Influenza Virus individual in figure 2, and the metabolite
>> >>>>> individual in
>> >>>>> figure
>> >>>>> 3.  Should those have classes indicated?
>> >>>>>
>> >>>>>
>> >>>> It may be better in Figure 3, add 'metabolite C00449' is instance_of
>> >>>> 'molecular entity'. In Figure2, add 'Influenza Virus' is instance_of
>> >>>> 'Virus'. As you pointed out in another email. In the Figure 2, we
>> >>>> should
>> >>>> change instance 'mouse' is_a  'organism' to 'mouse' is instance_of
>> >>>> 'organism or individual 'mouse' is instance_of 'Mus musculus' and
>> >>>> 'Mus
>> >>>> musculus' is_a 'organism'.
>> >>>>
>> >>>
>> >>> The figures show only fragments, we can not include all relations into
>> >>> diagrams as they are already complicated and we were criticized for
>> >>> that.
>> >>> I would refrain from making such sort of changes at this stage.
>> >>> There is
>> >>> nothing wrong with those relations, and short-cuts are logically
>> >>> correct.
>> >>> But we definitely should take this point of view (what relations to
>> >>> show
>> >>> in figures) into account for the main OBI paper.
>> >>>
>> >>> Larisa
>> >>>
>> >>
>>
>>
>> **********************************************************
>> Electronic Mail is not secure, may not be read every day, and should not
>> be used for urgent or sensitive issues
>
>

Now it is really attached.
-Alan

On Thu, Feb 25, 2010 at 9:49 PM, Alan Ruttenberg
<alanruttenberg@...> wrote:
> Attached is an alternative arrangement of the neuroscience use case
> for consideration. I have made the following changes:
>
> Each box now represents an individual, either explicitly named, or
> not. All links in the diagram are to be understood as relations
> between instances. Some are inferred, some explicitly asserted.
>
> Explicitly named instances have typographically distinguished names -
> they are suffixed with a number, and in monospace font. Their type is
> noted as "instance of <class name>".
>
> Un-named instances simply have their class name in the box. All class
> names are bold face.
>
> I have added some participation and realization relations that exist
> but were not stated, that I hope clarify some relationships.
>
> I realize this may be more changes than were expected, but this seems
> like the simplest change that avoids the confusion of having to
> explain how to interpret a mixture of  class-class and
> instance-instance relations in the same diagram.
>
> If this approach to diagramming addressed the issue of clarity, and is
> considered acceptable to the other authors, I can have a go at
> adjusting the other two figures to follow the same style, and to add a
> couple of sentences explaining how to read the figures.
>
> Jonathan, Tim, could you comment on whether this approach addresses
> your concerns about clarity?
> Co-authors, could you weigh in on whether we should go with this
> approach or have another go at it.
>
> Thanks,
>
> -Alan
>
>
>
> On Thu, Feb 25, 2010 at 7:14 PM, jie zheng <jiezheng@...> wrote:
>> Hi Oliver,
>>
>> Thanks a lot for updating the figure 2.
>>
>> I looked the updated figure. You have changed all the issues I mentioned.
>>
>> Here are two additional issues were addressed in the previous email
>> discussion with Timothy and Alan. You may consider whether we should change
>> it or not.
>> 1. There are two 'injection function' linked to 'syringe' which is realized
>> by 'vaccination' and 'pathogen challenge' processes. However, others like,
>> 'host role', 'target of material addition role' only shown once in the
>> figure. Did two 'injection function' classes mean differently?
>> 2. 'material to be added role' inheres_in 'vaccine', 'VacX' is instance_of
>> 'vaccine'. Are all instances of 'vaccine' bearer_of 'material to be added
>> role' or  only some of 'vaccine' instance, such as 'VacX', bearer_of
>> 'material to be added role'?  I think the one  shown in figure represent the
>> first meaning. If in the text description means the second option, we may
>> need to change the figure.
>>
>> Since I don't have much time working on it, the changes I pointed out were
>> what I thought we should make. Hope somebody else can check out whether
>> anything else need to be updated.
>>
>> Thanks,
>>
>> Jie
>>
>>
>> Yongqun He wrote:
>>>
>>> Hi Jie,
>>> I have updated Figure 2 as you instructed. The updated figure is committed
>>> to the SVN. Please check it out and let me know if more changes are needed.
>>> Thanks!
>>> Oliver
>>>
>>> >>> Jie Zheng <jiezheng@...> 2/25/2010 9:11 AM >>>
>>> Hi All,
>>>
>>> I think we don't need to make any modification for Figure 1 except
>>> adding Alan proposed text.
>>>
>>> In Figure2, add 'Influenza Virus' is instance_of  'Virus'. We should
>>> change instance 'mouse' is_a  'organism' to 'mouse' is instance_of
>>> 'organism or individual 'mouse' is instance_of 'Mus musculus' and 'Mus
>>> musculus' is_a 'organism'. Figure2 was drawn using Visio, I cannot help
>>> to modify it. Oliver, can you update it?
>>>
>>> Could someone else check any other changes we should make in the figures?
>>>
>>> Thanks,
>>>
>>> Jie
>>>
>>>
>>>
>>> Larisa Soldatova wrote:
>>> > Hi All,
>>> >
>>> > I got a reply from the Editors. The permitted to make changes in the
>>> > figures if we do it quickly.
>>> >
>>> > I will update fig. 3 as proposed. It would be great if someone can
>>> > take care about other figures: I have very heavy teaching load now and
>>> > cannot do anything extra.
>>> >
>>> > I wish to have your opinion on my suggestion to figures online and
>>> > give links to them in the paper.
>>> >
>>> > Thank you,
>>> > Larisa
>>> >
>>> >
>>> >> Hi Larisa,
>>> >>
>>> >> Agree with you. If we can change the relation between 'planning' and
>>> >> 'plan specification' should be good enough now.
>>> >>
>>> >> Thanks a lot for making the modification on figure/legend and trying
>>> >> to make it taken by the editors.
>>> >>
>>> >> Jie
>>> >>
>>> >> lss@... wrote:
>>> >>> Hi All,
>>> >>>
>>> >>> thank you to Timothy for reviewing our paper. Unfortunately it might
>>> >>> be
>>> >>> too late. I really can not predict how the editors would react on a
>>> >>> request to make several changes. I hoped that we can try to change
>>> >>> captions of figures (1 file). But if we need to change the figures
>>> >>> (they
>>> >>> are in separate files) we have to request to change all our
>>> >>> submission.
>>> >>> Maybe it is better to wait for proofs and try to do it on that stage.
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>>> (1) In Figure 3, ...
>>> >>>>>
>>> >>>> You are right. It may be easily fixed by changing the relation to:
>>> >>>> 'planning' has_specified_output 'plan specification'.
>>> >>>>
>>> >>>
>>> >>> OK, I will do that tomorrow (It is already late in UK)
>>> >>>
>>> >>>
>>> >>>
>>> >>>>> (3) In the latest version of the figures I saw, several
>>> >>>>> individuals seem
>>> >>>>> to not
>>> >>>>> be linked to any class through an 'instance_of' arrow -- for
>>> >>>>> example,
>>> >>>>> the
>>> >>>>> Influenza Virus individual in figure 2, and the metabolite
>>> >>>>> individual in
>>> >>>>> figure
>>> >>>>> 3.  Should those have classes indicated?
>>> >>>>>
>>> >>>>>
>>> >>>> It may be better in Figure 3, add 'metabolite C00449' is instance_of
>>> >>>> 'molecular entity'. In Figure2, add 'Influenza Virus' is instance_of
>>> >>>> 'Virus'. As you pointed out in another email. In the Figure 2, we
>>> >>>> should
>>> >>>> change instance 'mouse' is_a  'organism' to 'mouse' is instance_of
>>> >>>> 'organism or individual 'mouse' is instance_of 'Mus musculus' and
>>> >>>> 'Mus
>>> >>>> musculus' is_a 'organism'.
>>> >>>>
>>> >>>
>>> >>> The figures show only fragments, we can not include all relations into
>>> >>> diagrams as they are already complicated and we were criticized for
>>> >>> that.
>>> >>> I would refrain from making such sort of changes at this stage.
>>> >>> There is
>>> >>> nothing wrong with those relations, and short-cuts are logically
>>> >>> correct.
>>> >>> But we definitely should take this point of view (what relations to
>>> >>> show
>>> >>> in figures) into account for the main OBI paper.
>>> >>>
>>> >>> Larisa
>>> >>>
>>> >>
>>>
>>>
>>> **********************************************************
>>> Electronic Mail is not secure, may not be read every day, and should not
>>> be used for urgent or sensitive issues
>>
>>
>

My comments range from the trivial to almost-as-trivial, so take them or leave
them as you have time or energy.  

(1) Is typographic weight still meaningful?  In the previous figures, I believe
you were using bold font for the names of processes, but here you seem to have
started using it for the names of all classes.  Is there a reason that 'neuron'
is in bold, or that 'study subject role' appears not to be? 

In general I'd argue that typographic weights like this are hard to distinguish,
and I'd guess that they're doubly so to people for whom Latin scripts were not
their first writing system.  Using fonts or styles or typographic weights to
make subtle but crucial distinctions in figures could be confusing to some
people (would color work better?) but if you all (OBI) have already made a
decision to use these in a specific way then I'm already late to the party
here...

(2) If all of these boxes represent individuals now, should I take boxes like
'study subject role' and 'Caudate nucleus' to be some (anonymous) individual of
those classes?   Do you think that there's significant value in having names
like, 'light on tangent screen-21' and 'spike train datum-14' on some, but not
all, of the boxes?  Jonathan's suggestion here was that "the position of the box
in the figure functions as a kind of unique name itself," and I've come around
to that point of view as well.  What if you just erased all the names, and added
some piece of text to the caption: "each box is an individual, labeled with the
name of the class to which it belongs" or something along those lines?

(3) Is there any reason that the neuron doesn't bear an evaluant role in this
figure?  

I think those are really my only questions to a figure like this, and they're
all pretty minor.  

- Timothy



Timothy Danford
Bioinformatics Engineer, Neurology Research, MGH
tdanford@...

-----Original Message-----
From: Alan Ruttenberg [mailto:alanruttenberg@...]
Sent: Thu 2/25/2010 9:49 PM
To: jie zheng
Cc: Yongqun He; Larisa Soldatova; Jonathan Rees; OBI Developers; Danford,
Timothy William
Subject: Re: URGENT: [Obi-devel] OBI figures in JMBS papers
 
Attached is an alternative arrangement of the neuroscience use case
for consideration. I have made the following changes:

Each box now represents an individual, either explicitly named, or
not. All links in the diagram are to be understood as relations
between instances. Some are inferred, some explicitly asserted.

Explicitly named instances have typographically distinguished names -
they are suffixed with a number, and in monospace font. Their type is
noted as "instance of <class name>".

Un-named instances simply have their class name in the box. All class
names are bold face.

I have added some participation and realization relations that exist
but were not stated, that I hope clarify some relationships.

I realize this may be more changes than were expected, but this seems
like the simplest change that avoids the confusion of having to
explain how to interpret a mixture of  class-class and
instance-instance relations in the same diagram.

If this approach to diagramming addressed the issue of clarity, and is
considered acceptable to the other authors, I can have a go at
adjusting the other two figures to follow the same style, and to add a
couple of sentences explaining how to read the figures.

Jonathan, Tim, could you comment on whether this approach addresses
your concerns about clarity?
Co-authors, could you weigh in on whether we should go with this
approach or have another go at it.

Thanks,

-Alan



On Thu, Feb 25, 2010 at 7:14 PM, jie zheng <jiezheng@...> wrote:
> Hi Oliver,
>
> Thanks a lot for updating the figure 2.
>
> I looked the updated figure. You have changed all the issues I mentioned.
>
> Here are two additional issues were addressed in the previous email
> discussion with Timothy and Alan. You may consider whether we should change
> it or not.
> 1. There are two 'injection function' linked to 'syringe' which is realized
> by 'vaccination' and 'pathogen challenge' processes. However, others like,
> 'host role', 'target of material addition role' only shown once in the
> figure. Did two 'injection function' classes mean differently?
> 2. 'material to be added role' inheres_in 'vaccine', 'VacX' is instance_of
> 'vaccine'. Are all instances of 'vaccine' bearer_of 'material to be added
> role' or  only some of 'vaccine' instance, such as 'VacX', bearer_of
> 'material to be added role'?  I think the one  shown in figure represent the
> first meaning. If in the text description means the second option, we may
> need to change the figure.
>
> Since I don't have much time working on it, the changes I pointed out were
> what I thought we should make. Hope somebody else can check out whether
> anything else need to be updated.
>
> Thanks,
>
> Jie
>
>
> Yongqun He wrote:
>>
>> Hi Jie,
>> I have updated Figure 2 as you instructed. The updated figure is committed
>> to the SVN. Please check it out and let me know if more changes are needed.
>> Thanks!
>> Oliver
>>
>> >>> Jie Zheng <jiezheng@...> 2/25/2010 9:11 AM >>>
>> Hi All,
>>
>> I think we don't need to make any modification for Figure 1 except
>> adding Alan proposed text.
>>
>> In Figure2, add 'Influenza Virus' is instance_of  'Virus'. We should
>> change instance 'mouse' is_a  'organism' to 'mouse' is instance_of
>> 'organism or individual 'mouse' is instance_of 'Mus musculus' and 'Mus
>> musculus' is_a 'organism'. Figure2 was drawn using Visio, I cannot help
>> to modify it. Oliver, can you update it?
>>
>> Could someone else check any other changes we should make in the figures?
>>
>> Thanks,
>>
>> Jie
>>
>>
>>
>> Larisa Soldatova wrote:
>> > Hi All,
>> >
>> > I got a reply from the Editors. The permitted to make changes in the
>> > figures if we do it quickly.
>> >
>> > I will update fig. 3 as proposed. It would be great if someone can
>> > take care about other figures: I have very heavy teaching load now and
>> > cannot do anything extra.
>> >
>> > I wish to have your opinion on my suggestion to figures online and
>> > give links to them in the paper.
>> >
>> > Thank you,
>> > Larisa
>> >
>> >
>> >> Hi Larisa,
>> >>
>> >> Agree with you. If we can change the relation between 'planning' and
>> >> 'plan specification' should be good enough now.
>> >>
>> >> Thanks a lot for making the modification on figure/legend and trying
>> >> to make it taken by the editors.
>> >>
>> >> Jie
>> >>
>> >> lss@... wrote:
>> >>> Hi All,
>> >>>
>> >>> thank you to Timothy for reviewing our paper. Unfortunately it might
>> >>> be
>> >>> too late. I really can not predict how the editors would react on a
>> >>> request to make several changes. I hoped that we can try to change
>> >>> captions of figures (1 file). But if we need to change the figures
>> >>> (they
>> >>> are in separate files) we have to request to change all our
>> >>> submission.
>> >>> Maybe it is better to wait for proofs and try to do it on that stage.
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>>> (1) In Figure 3, ...
>> >>>>>
>> >>>> You are right. It may be easily fixed by changing the relation to:
>> >>>> 'planning' has_specified_output 'plan specification'.
>> >>>>
>> >>>
>> >>> OK, I will do that tomorrow (It is already late in UK)
>> >>>
>> >>>
>> >>>
>> >>>>> (3) In the latest version of the figures I saw, several
>> >>>>> individuals seem
>> >>>>> to not
>> >>>>> be linked to any class through an 'instance_of' arrow -- for
>> >>>>> example,
>> >>>>> the
>> >>>>> Influenza Virus individual in figure 2, and the metabolite
>> >>>>> individual in
>> >>>>> figure
>> >>>>> 3.  Should those have classes indicated?
>> >>>>>
>> >>>>>
>> >>>> It may be better in Figure 3, add 'metabolite C00449' is instance_of
>> >>>> 'molecular entity'. In Figure2, add 'Influenza Virus' is instance_of
>> >>>> 'Virus'. As you pointed out in another email. In the Figure 2, we
>> >>>> should
>> >>>> change instance 'mouse' is_a  'organism' to 'mouse' is instance_of
>> >>>> 'organism or individual 'mouse' is instance_of 'Mus musculus' and
>> >>>> 'Mus
>> >>>> musculus' is_a 'organism'.
>> >>>>
>> >>>
>> >>> The figures show only fragments, we can not include all relations into
>> >>> diagrams as they are already complicated and we were criticized for
>> >>> that.
>> >>> I would refrain from making such sort of changes at this stage.
>> >>> There is
>> >>> nothing wrong with those relations, and short-cuts are logically
>> >>> correct.
>> >>> But we definitely should take this point of view (what relations to
>> >>> show
>> >>> in figures) into account for the main OBI paper.
>> >>>
>> >>> Larisa
>> >>>
>> >>
>>
>>
>> **********************************************************
>> Electronic Mail is not secure, may not be read every day, and should not
>> be used for urgent or sensitive issues
>
>



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.

Thanks Alan, I think this does actually clarify a lot of things I
wasn't clear on in the initial presentation regarding instances and
classes. If the typography is consistent with the other images (which
was something the reviewers originally noted and that we fixed in the
resubmisson) then that's great.

Thanks,
Jess

On Thu, Feb 25, 2010 at 7:49 PM, Alan Ruttenberg
<alanruttenberg@...> wrote:
> Attached is an alternative arrangement of the neuroscience use case
> for consideration. I have made the following changes:
>
> Each box now represents an individual, either explicitly named, or
> not. All links in the diagram are to be understood as relations
> between instances. Some are inferred, some explicitly asserted.
>
> Explicitly named instances have typographically distinguished names -
> they are suffixed with a number, and in monospace font. Their type is
> noted as "instance of <class name>".
>
> Un-named instances simply have their class name in the box. All class
> names are bold face.
>
> I have added some participation and realization relations that exist
> but were not stated, that I hope clarify some relationships.
>
> I realize this may be more changes than were expected, but this seems
> like the simplest change that avoids the confusion of having to
> explain how to interpret a mixture of  class-class and
> instance-instance relations in the same diagram.
>
> If this approach to diagramming addressed the issue of clarity, and is
> considered acceptable to the other authors, I can have a go at
> adjusting the other two figures to follow the same style, and to add a
> couple of sentences explaining how to read the figures.
>
> Jonathan, Tim, could you comment on whether this approach addresses
> your concerns about clarity?
> Co-authors, could you weigh in on whether we should go with this
> approach or have another go at it.
>
> Thanks,
>
> -Alan
>
>
>
> On Thu, Feb 25, 2010 at 7:14 PM, jie zheng <jiezheng@...> wrote:
>> Hi Oliver,
>>
>> Thanks a lot for updating the figure 2.
>>
>> I looked the updated figure. You have changed all the issues I mentioned.
>>
>> Here are two additional issues were addressed in the previous email
>> discussion with Timothy and Alan. You may consider whether we should change
>> it or not.
>> 1. There are two 'injection function' linked to 'syringe' which is realized
>> by 'vaccination' and 'pathogen challenge' processes. However, others like,
>> 'host role', 'target of material addition role' only shown once in the
>> figure. Did two 'injection function' classes mean differently?
>> 2. 'material to be added role' inheres_in 'vaccine', 'VacX' is instance_of
>> 'vaccine'. Are all instances of 'vaccine' bearer_of 'material to be added
>> role' or  only some of 'vaccine' instance, such as 'VacX', bearer_of
>> 'material to be added role'?  I think the one  shown in figure represent the
>> first meaning. If in the text description means the second option, we may
>> need to change the figure.
>>
>> Since I don't have much time working on it, the changes I pointed out were
>> what I thought we should make. Hope somebody else can check out whether
>> anything else need to be updated.
>>
>> Thanks,
>>
>> Jie
>>
>>
>> Yongqun He wrote:
>>>
>>> Hi Jie,
>>> I have updated Figure 2 as you instructed. The updated figure is committed
>>> to the SVN. Please check it out and let me know if more changes are needed.
>>> Thanks!
>>> Oliver
>>>
>>> >>> Jie Zheng <jiezheng@...> 2/25/2010 9:11 AM >>>
>>> Hi All,
>>>
>>> I think we don't need to make any modification for Figure 1 except
>>> adding Alan proposed text.
>>>
>>> In Figure2, add 'Influenza Virus' is instance_of  'Virus'. We should
>>> change instance 'mouse' is_a  'organism' to 'mouse' is instance_of
>>> 'organism or individual 'mouse' is instance_of 'Mus musculus' and 'Mus
>>> musculus' is_a 'organism'. Figure2 was drawn using Visio, I cannot help
>>> to modify it. Oliver, can you update it?
>>>
>>> Could someone else check any other changes we should make in the figures?
>>>
>>> Thanks,
>>>
>>> Jie
>>>
>>>
>>>
>>> Larisa Soldatova wrote:
>>> > Hi All,
>>> >
>>> > I got a reply from the Editors. The permitted to make changes in the
>>> > figures if we do it quickly.
>>> >
>>> > I will update fig. 3 as proposed. It would be great if someone can
>>> > take care about other figures: I have very heavy teaching load now and
>>> > cannot do anything extra.
>>> >
>>> > I wish to have your opinion on my suggestion to figures online and
>>> > give links to them in the paper.
>>> >
>>> > Thank you,
>>> > Larisa
>>> >
>>> >
>>> >> Hi Larisa,
>>> >>
>>> >> Agree with you. If we can change the relation between 'planning' and
>>> >> 'plan specification' should be good enough now.
>>> >>
>>> >> Thanks a lot for making the modification on figure/legend and trying
>>> >> to make it taken by the editors.
>>> >>
>>> >> Jie
>>> >>
>>> >> lss@... wrote:
>>> >>> Hi All,
>>> >>>
>>> >>> thank you to Timothy for reviewing our paper. Unfortunately it might
>>> >>> be
>>> >>> too late. I really can not predict how the editors would react on a
>>> >>> request to make several changes. I hoped that we can try to change
>>> >>> captions of figures (1 file). But if we need to change the figures
>>> >>> (they
>>> >>> are in separate files) we have to request to change all our
>>> >>> submission.
>>> >>> Maybe it is better to wait for proofs and try to do it on that stage.
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>>> (1) In Figure 3, ...
>>> >>>>>
>>> >>>> You are right. It may be easily fixed by changing the relation to:
>>> >>>> 'planning' has_specified_output 'plan specification'.
>>> >>>>
>>> >>>
>>> >>> OK, I will do that tomorrow (It is already late in UK)
>>> >>>
>>> >>>
>>> >>>
>>> >>>>> (3) In the latest version of the figures I saw, several
>>> >>>>> individuals seem
>>> >>>>> to not
>>> >>>>> be linked to any class through an 'instance_of' arrow -- for
>>> >>>>> example,
>>> >>>>> the
>>> >>>>> Influenza Virus individual in figure 2, and the metabolite
>>> >>>>> individual in
>>> >>>>> figure
>>> >>>>> 3.  Should those have classes indicated?
>>> >>>>>
>>> >>>>>
>>> >>>> It may be better in Figure 3, add 'metabolite C00449' is instance_of
>>> >>>> 'molecular entity'. In Figure2, add 'Influenza Virus' is instance_of
>>> >>>> 'Virus'. As you pointed out in another email. In the Figure 2, we
>>> >>>> should
>>> >>>> change instance 'mouse' is_a  'organism' to 'mouse' is instance_of
>>> >>>> 'organism or individual 'mouse' is instance_of 'Mus musculus' and
>>> >>>> 'Mus
>>> >>>> musculus' is_a 'organism'.
>>> >>>>
>>> >>>
>>> >>> The figures show only fragments, we can not include all relations into
>>> >>> diagrams as they are already complicated and we were criticized for
>>> >>> that.
>>> >>> I would refrain from making such sort of changes at this stage.
>>> >>> There is
>>> >>> nothing wrong with those relations, and short-cuts are logically
>>> >>> correct.
>>> >>> But we definitely should take this point of view (what relations to
>>> >>> show
>>> >>> in figures) into account for the main OBI paper.
>>> >>>
>>> >>> Larisa
>>> >>>
>>> >>
>>>
>>>
>>> **********************************************************
>>> Electronic Mail is not secure, may not be read every day, and should not
>>> be used for urgent or sensitive issues
>>
>>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; 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@...
> https://lists.sourceforge.net/lists/listinfo/obi-devel
>



-- 
Jessica Turner, Ph.D.
Research Scientist
MIND Research Network
1101 Yale Blvd. NE
Albuquerque, New Mexico 87106
Ph: 505-272-1570
email: jturner@...

Hi Jie,
 
I have updated the Figure 2 again. Basically, I deleted one 'injection function' out of two. It is the same meaning. I added two before just for drawing convenience. Deleting one clarifies the story.  
 
For the second point, all instances of 'vaccine' bearer_of 'material to be added role' in the vaccination process.
 
Figure 2 looks better from these changes. The same is for the other two figures. 
Thanks!
 
Oliver  


>>> jie zheng <jiezheng@...> 2/25/2010 7:14 PM >>>
Hi Oliver,

Thanks a lot for updating the figure 2.

I looked the updated figure. You have changed all the issues I mentioned.

Here are two additional issues were addressed in the previous email 
discussion with Timothy and Alan. You may consider whether we should 
change it or not.
1. There are two 'injection function' linked to 'syringe' which is 
realized by 'vaccination' and 'pathogen challenge' processes. However, 
others like, 'host role', 'target of material addition role' only shown 
once in the figure. Did two 'injection function' classes mean differently?
2. 'material to be added role' inheres_in 'vaccine', 'VacX' is 
instance_of 'vaccine'. Are all instances of 'vaccine' bearer_of 
'material to be added role' or  only some of 'vaccine' instance, such as 
'VacX', bearer_of 'material to be added role'?  I think the one  shown 
in figure represent the first meaning. If in the text description means 
the second option, we may need to change the figure.

Since I don't have much time working on it, the changes I pointed out 
were what I thought we should make. Hope somebody else can check out 
whether anything else need to be updated.

Thanks,

Jie


Yongqun He wrote:
> Hi Jie,
> I have updated Figure 2 as you instructed. The updated figure is 
> committed to the SVN. Please check it out and let me know if more 
> changes are needed.
> Thanks!
> Oliver
>
> >>> Jie Zheng <jiezheng@...> 2/25/2010 9:11 AM >>>
> Hi All,
>
> I think we don't need to make any modification for Figure 1 except
> adding Alan proposed text.
>
> In Figure2, add 'Influenza Virus' is instance_of  'Virus'. We should
> change instance 'mouse' is_a  'organism' to 'mouse' is instance_of
> 'organism or individual 'mouse' is instance_of 'Mus musculus' and 'Mus
> musculus' is_a 'organism'. Figure2 was drawn using Visio, I cannot help
> to modify it. Oliver, can you update it?
>
> Could someone else check any other changes we should make in the figures?
>
> Thanks,
>
> Jie
>
>
>
> Larisa Soldatova wrote:
> > Hi All,
> >
> > I got a reply from the Editors. The permitted to make changes in the
> > figures if we do it quickly.
> >
> > I will update fig. 3 as proposed. It would be great if someone can
> > take care about other figures: I have very heavy teaching load now and
> > cannot do anything extra.
> >
> > I wish to have your opinion on my suggestion to figures online and
> > give links to them in the paper.
> >
> > Thank you,
> > Larisa
> >
> >
> >> Hi Larisa,
> >>
> >> Agree with you. If we can change the relation between 'planning' and
> >> 'plan specification' should be good enough now.
> >>
> >> Thanks a lot for making the modification on figure/legend and trying
> >> to make it taken by the editors.
> >>
> >> Jie
> >>
> >> lss@... wrote:
> >>> Hi All,
> >>>
> >>> thank you to Timothy for reviewing our paper. Unfortunately it 
> might be
> >>> too late. I really can not predict how the editors would react on a
> >>> request to make several changes. I hoped that we can try to change
> >>> captions of figures (1 file). But if we need to change the figures
> >>> (they
> >>> are in separate files) we have to request to change all our 
> submission.
> >>> Maybe it is better to wait for proofs and try to do it on that stage.
> >>>
> >>>
> >>>
> >>>
> >>>>> (1) In Figure 3, ...
> >>>>>
> >>>> You are right. It may be easily fixed by changing the relation to:
> >>>> 'planning' has_specified_output 'plan specification'.
> >>>>
> >>>
> >>> OK, I will do that tomorrow (It is already late in UK)
> >>>
> >>>
> >>>
> >>>>> (3) In the latest version of the figures I saw, several
> >>>>> individuals seem
> >>>>> to not
> >>>>> be linked to any class through an 'instance_of' arrow -- for 
> example,
> >>>>> the
> >>>>> Influenza Virus individual in figure 2, and the metabolite
> >>>>> individual in
> >>>>> figure
> >>>>> 3.  Should those have classes indicated?
> >>>>>
> >>>>>
> >>>> It may be better in Figure 3, add 'metabolite C00449' is instance_of
> >>>> 'molecular entity'. In Figure2, add 'Influenza Virus' is instance_of
> >>>> 'Virus'. As you pointed out in another email. In the Figure 2, we
> >>>> should
> >>>> change instance 'mouse' is_a  'organism' to 'mouse' is instance_of
> >>>> 'organism or individual 'mouse' is instance_of 'Mus musculus' and 
> 'Mus
> >>>> musculus' is_a 'organism'.
> >>>>
> >>>
> >>> The figures show only fragments, we can not include all relations into
> >>> diagrams as they are already complicated and we were criticized for
> >>> that.
> >>> I would refrain from making such sort of changes at this stage.
> >>> There is
> >>> nothing wrong with those relations, and short-cuts are logically
> >>> correct.
> >>> But we definitely should take this point of view (what relations to
> >>> show
> >>> in figures) into account for the main OBI paper.
> >>>
> >>> Larisa
> >>>
> >>
>
>
> **********************************************************
> Electronic Mail is not secure, may not be read every day, and should 
> not be used for urgent or sensitive issues


**********************************************************
Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues

Hi Oliver,

Thanks a lot.

Alan suggested to represent all the figures in the different way to 
clarify all the relations as individual and individual (please checked 
the modified figure1 he attached to his email). Because I don't have 
time to work on the figures by myself, I would like to go either way 
others decided.

Thanks,

Jie

Yongqun He wrote:
> Hi Jie,
>  
> I have updated the Figure 2 again. Basically, I deleted one 'injection 
> function' out of two. It is the same meaning. I added two before just 
> for drawing convenience. Deleting one clarifies the story.  
>  
> For the second point, all instances of 'vaccine' bearer_of 'material 
> to be added role' in the vaccination process.
>  
> Figure 2 looks better from these changes. The same is for the other 
> two figures. 
> Thanks!
>  
> Oliver  
>
>
> >>> jie zheng <jiezheng@...> 2/25/2010 7:14 PM >>>
> Hi Oliver,
>
> Thanks a lot for updating the figure 2.
>
> I looked the updated figure. You have changed all the issues I mentioned.
>
> Here are two additional issues were addressed in the previous email
> discussion with Timothy and Alan. You may consider whether we should
> change it or not.
> 1. There are two 'injection function' linked to 'syringe' which is
> realized by 'vaccination' and 'pathogen challenge' processes. However,
> others like, 'host role', 'target of material addition role' only shown
> once in the figure. Did two 'injection function' classes mean differently?
> 2. 'material to be added role' inheres_in 'vaccine', 'VacX' is
> instance_of 'vaccine'. Are all instances of 'vaccine' bearer_of
> 'material to be added role' or  only some of 'vaccine' instance, such as
> 'VacX', bearer_of 'material to be added role'?  I think the one  shown
> in figure represent the first meaning. If in the text description means
> the second option, we may need to change the figure.
>
> Since I don't have much time working on it, the changes I pointed out
> were what I thought we should make. Hope somebody else can check out
> whether anything else need to be updated.
>
> Thanks,
>
> Jie
>
>
> Yongqun He wrote:
> > Hi Jie,
> > I have updated Figure 2 as you instructed. The updated figure is
> > committed to the SVN. Please check it out and let me know if more
> > changes are needed.
> > Thanks!
> > Oliver
> >
> > >>> Jie Zheng <jiezheng@...> 2/25/2010 9:11 AM >>>
> > Hi All,
> >
> > I think we don't need to make any modification for Figure 1 except
> > adding Alan proposed text.
> >
> > In Figure2, add 'Influenza Virus' is instance_of  'Virus'. We should
> > change instance 'mouse' is_a  'organism' to 'mouse' is instance_of
> > 'organism or individual 'mouse' is instance_of 'Mus musculus' and 'Mus
> > musculus' is_a 'organism'. Figure2 was drawn using Visio, I cannot help
> > to modify it. Oliver, can you update it?
> >
> > Could someone else check any other changes we should make in the 
> figures?
> >
> > Thanks,
> >
> > Jie
> >
> >
> >
> > Larisa Soldatova wrote:
> > > Hi All,
> > >
> > > I got a reply from the Editors. The permitted to make changes in the
> > > figures if we do it quickly.
> > >
> > > I will update fig. 3 as proposed. It would be great if someone can
> > > take care about other figures: I have very heavy teaching load now and
> > > cannot do anything extra.
> > >
> > > I wish to have your opinion on my suggestion to figures online and
> > > give links to them in the paper.
> > >
> > > Thank you,
> > > Larisa
> > >
> > >
> > >> Hi Larisa,
> > >>
> > >> Agree with you. If we can change the relation between 'planning' and
> > >> 'plan specification' should be good enough now.
> > >>
> > >> Thanks a lot for making the modification on figure/legend and trying
> > >> to make it taken by the editors.
> > >>
> > >> Jie
> > >>
> > >> lss@... wrote:
> > >>> Hi All,
> > >>>
> > >>> thank you to Timothy for reviewing our paper. Unfortunately it
> > might be
> > >>> too late. I really can not predict how the editors would react on a
> > >>> request to make several changes. I hoped that we can try to change
> > >>> captions of figures (1 file). But if we need to change the figures
> > >>> (they
> > >>> are in separate files) we have to request to change all our
> > submission.
> > >>> Maybe it is better to wait for proofs and try to do it on that 
> stage.
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>>> (1) In Figure 3, ...
> > >>>>>
> > >>>> You are right. It may be easily fixed by changing the relation to:
> > >>>> 'planning' has_specified_output 'plan specification'.
> > >>>>
> > >>>
> > >>> OK, I will do that tomorrow (It is already late in UK)
> > >>>
> > >>>
> > >>>
> > >>>>> (3) In the latest version of the figures I saw, several
> > >>>>> individuals seem
> > >>>>> to not
> > >>>>> be linked to any class through an 'instance_of' arrow -- for
> > example,
> > >>>>> the
> > >>>>> Influenza Virus individual in figure 2, and the metabolite
> > >>>>> individual in
> > >>>>> figure
> > >>>>> 3.  Should those have classes indicated?
> > >>>>>
> > >>>>>
> > >>>> It may be better in Figure 3, add 'metabolite C00449' is 
> instance_of
> > >>>> 'molecular entity'. In Figure2, add 'Influenza Virus' is 
> instance_of
> > >>>> 'Virus'. As you pointed out in another email. In the Figure 2, we
> > >>>> should
> > >>>> change instance 'mouse' is_a  'organism' to 'mouse' is instance_of
> > >>>> 'organism or individual 'mouse' is instance_of 'Mus musculus' and
> > 'Mus
> > >>>> musculus' is_a 'organism'.
> > >>>>
> > >>>
> > >>> The figures show only fragments, we can not include all 
> relations into
> > >>> diagrams as they are already complicated and we were criticized for
> > >>> that.
> > >>> I would refrain from making such sort of changes at this stage.
> > >>> There is
> > >>> nothing wrong with those relations, and short-cuts are logically
> > >>> correct.
> > >>> But we definitely should take this point of view (what relations to
> > >>> show
> > >>> in figures) into account for the main OBI paper.
> > >>>
> > >>> Larisa
> > >>>
> > >>
> >
> >
> > **********************************************************
> > Electronic Mail is not secure, may not be read every day, and should
> > not be used for urgent or sensitive issues
>
>
> **********************************************************
> Electronic Mail is not secure, may not be read every day, and should 
> not be used for urgent or sensitive issues

Hi All,

thank you very much for working on figure. And sorry for being silent - I
have very heavy teaching duties for this months. My best hope that I would
be able to work on updates tomorrow evening.

I would prefer to send everything to the editors on Monday evening.

Larisa

>
> Thanks a lot.
>
> Alan suggested to represent all the figures in the different way to
> clarify all the relations as individual and individual (please checked
> the modified figure1 he attached to his email). Because I don't have
> time to work on the figures by myself, I would like to go either way
> others decided.
>
> Thanks,
>
> Jie
>
> Yongqun He wrote:
>> Hi Jie,
>>
>> I have updated the Figure 2 again. Basically, I deleted one 'injection
>> function' out of two. It is the same meaning. I added two before just
>> for drawing convenience. Deleting one clarifies the story.
>>
>> For the second point, all instances of 'vaccine' bearer_of 'material
>> to be added role' in the vaccination process.
>>
>> Figure 2 looks better from these changes. The same is for the other
>> two figures.
>> Thanks!
>>
>> Oliver
>>
>>
>> >>> jie zheng <jiezheng@...> 2/25/2010 7:14 PM >>>
>> Hi Oliver,
>>
>> Thanks a lot for updating the figure 2.
>>
>> I looked the updated figure. You have changed all the issues I
>> mentioned.
>>
>> Here are two additional issues were addressed in the previous email
>> discussion with Timothy and Alan. You may consider whether we should
>> change it or not.
>> 1. There are two 'injection function' linked to 'syringe' which is
>> realized by 'vaccination' and 'pathogen challenge' processes. However,
>> others like, 'host role', 'target of material addition role' only shown
>> once in the figure. Did two 'injection function' classes mean
>> differently?
>> 2. 'material to be added role' inheres_in 'vaccine', 'VacX' is
>> instance_of 'vaccine'. Are all instances of 'vaccine' bearer_of
>> 'material to be added role' or  only some of 'vaccine' instance, such as
>> 'VacX', bearer_of 'material to be added role'?  I think the one  shown
>> in figure represent the first meaning. If in the text description means
>> the second option, we may need to change the figure.
>>
>> Since I don't have much time working on it, the changes I pointed out
>> were what I thought we should make. Hope somebody else can check out
>> whether anything else need to be updated.
>>
>> Thanks,
>>
>> Jie
>>
>>
>> Yongqun He wrote:
>> > Hi Jie,
>> > I have updated Figure 2 as you instructed. The updated figure is
>> > committed to the SVN. Please check it out and let me know if more
>> > changes are needed.
>> > Thanks!
>> > Oliver
>> >
>> > >>> Jie Zheng <jiezheng@...> 2/25/2010 9:11 AM >>>
>> > Hi All,
>> >
>> > I think we don't need to make any modification for Figure 1 except
>> > adding Alan proposed text.
>> >
>> > In Figure2, add 'Influenza Virus' is instance_of  'Virus'. We should
>> > change instance 'mouse' is_a  'organism' to 'mouse' is instance_of
>> > 'organism or individual 'mouse' is instance_of 'Mus musculus' and 'Mus
>> > musculus' is_a 'organism'. Figure2 was drawn using Visio, I cannot
>> help
>> > to modify it. Oliver, can you update it?
>> >
>> > Could someone else check any other changes we should make in the
>> figures?
>> >
>> > Thanks,
>> >
>> > Jie
>> >
>> >
>> >
>> > Larisa Soldatova wrote:
>> > > Hi All,
>> > >
>> > > I got a reply from the Editors. The permitted to make changes in the
>> > > figures if we do it quickly.
>> > >
>> > > I will update fig. 3 as proposed. It would be great if someone can
>> > > take care about other figures: I have very heavy teaching load now
>> and
>> > > cannot do anything extra.
>> > >
>> > > I wish to have your opinion on my suggestion to figures online and
>> > > give links to them in the paper.
>> > >
>> > > Thank you,
>> > > Larisa
>> > >
>> > >
>> > >> Hi Larisa,
>> > >>
>> > >> Agree with you. If we can change the relation between 'planning'
>> and
>> > >> 'plan specification' should be good enough now.
>> > >>
>> > >> Thanks a lot for making the modification on figure/legend and
>> trying
>> > >> to make it taken by the editors.
>> > >>
>> > >> Jie
>> > >>
>> > >> lss@... wrote:
>> > >>> Hi All,
>> > >>>
>> > >>> thank you to Timothy for reviewing our paper. Unfortunately it
>> > might be
>> > >>> too late. I really can not predict how the editors would react on
>> a
>> > >>> request to make several changes. I hoped that we can try to change
>> > >>> captions of figures (1 file). But if we need to change the figures
>> > >>> (they
>> > >>> are in separate files) we have to request to change all our
>> > submission.
>> > >>> Maybe it is better to wait for proofs and try to do it on that
>> stage.
>> > >>>
>> > >>>
>> > >>>
>> > >>>
>> > >>>>> (1) In Figure 3, ...
>> > >>>>>
>> > >>>> You are right. It may be easily fixed by changing the relation
>> to:
>> > >>>> 'planning' has_specified_output 'plan specification'.
>> > >>>>
>> > >>>
>> > >>> OK, I will do that tomorrow (It is already late in UK)
>> > >>>
>> > >>>
>> > >>>
>> > >>>>> (3) In the latest version of the figures I saw, several
>> > >>>>> individuals seem
>> > >>>>> to not
>> > >>>>> be linked to any class through an 'instance_of' arrow -- for
>> > example,
>> > >>>>> the
>> > >>>>> Influenza Virus individual in figure 2, and the metabolite
>> > >>>>> individual in
>> > >>>>> figure
>> > >>>>> 3.  Should those have classes indicated?
>> > >>>>>
>> > >>>>>
>> > >>>> It may be better in Figure 3, add 'metabolite C00449' is
>> instance_of
>> > >>>> 'molecular entity'. In Figure2, add 'Influenza Virus' is
>> instance_of
>> > >>>> 'Virus'. As you pointed out in another email. In the Figure 2, we
>> > >>>> should
>> > >>>> change instance 'mouse' is_a  'organism' to 'mouse' is
>> instance_of
>> > >>>> 'organism or individual 'mouse' is instance_of 'Mus musculus' and
>> > 'Mus
>> > >>>> musculus' is_a 'organism'.
>> > >>>>
>> > >>>
>> > >>> The figures show only fragments, we can not include all
>> relations into
>> > >>> diagrams as they are already complicated and we were criticized
>> for
>> > >>> that.
>> > >>> I would refrain from making such sort of changes at this stage.
>> > >>> There is
>> > >>> nothing wrong with those relations, and short-cuts are logically
>> > >>> correct.
>> > >>> But we definitely should take this point of view (what relations
>> to
>> > >>> show
>> > >>> in figures) into account for the main OBI paper.
>> > >>>
>> > >>> Larisa
>> > >>>
>> > >>
>> >
>> >
>> > **********************************************************
>> > Electronic Mail is not secure, may not be read every day, and should
>> > not be used for urgent or sensitive issues
>>
>>
>> **********************************************************
>> Electronic Mail is not secure, may not be read every day, and should
>> not be used for urgent or sensitive issues
>
>

Hi Alan,
 
I agree with you that it may represent a big change. This new type of representation may need some time to discuss, digest, and agree by all. For now, I feel that this new type is not appropriate for this paper. I think that the method is not mature yet and will make the figure look more confusing. For example, it is very confusing to say  "light on tangent screen-21, instance of light source", "stimulation-12 instance of presentation of stimulus", etc. Readers do not care if it is stimulation-12 or stimulation-11, which is probably not necessary to be included to make a nice story. 
 
I prefer to still use the "traditional" figures with some changes to be incorporated based on recent discussions. For example, I have made several changes to the Figure 2, and these changes include those proposed by Jie, Timothy, and you.  I think current Figure 2 looks very good now. I think that we can discuss your approach of representing in more details in our OBI meetings and Vancouver workshop.
 
Oliver  


>>> Alan Ruttenberg <alanruttenberg@...> 2/25/2010 9:50 PM >>>
Now it is really attached.
-Alan

On Thu, Feb 25, 2010 at 9:49 PM, Alan Ruttenberg
<alanruttenberg@...> wrote:
> Attached is an alternative arrangement of the neuroscience use case
> for consideration. I have made the following changes:
>
> Each box now represents an individual, either explicitly named, or
> not. All links in the diagram are to be understood as relations
> between instances. Some are inferred, some explicitly asserted.
>
> Explicitly named instances have typographically distinguished names -
> they are suffixed with a number, and in monospace font. Their type is
> noted as "instance of <class name>".
>
> Un-named instances simply have their class name in the box. All class
> names are bold face.
>
> I have added some participation and realization relations that exist
> but were not stated, that I hope clarify some relationships.
>
> I realize this may be more changes than were expected, but this seems
> like the simplest change that avoids the confusion of having to
> explain how to interpret a mixture of  class-class and
> instance-instance relations in the same diagram.
>
> If this approach to diagramming addressed the issue of clarity, and is
> considered acceptable to the other authors, I can have a go at
> adjusting the other two figures to follow the same style, and to add a
> couple of sentences explaining how to read the figures.
>
> Jonathan, Tim, could you comment on whether this approach addresses
> your concerns about clarity?
> Co-authors, could you weigh in on whether we should go with this
> approach or have another go at it.
>
> Thanks,
>
> -Alan
>
>
>
> On Thu, Feb 25, 2010 at 7:14 PM, jie zheng <jiezheng@...> wrote:
>> Hi Oliver,
>>
>> Thanks a lot for updating the figure 2.
>>
>> I looked the updated figure. You have changed all the issues I mentioned.
>>
>> Here are two additional issues were addressed in the previous email
>> discussion with Timothy and Alan. You may consider whether we should change
>> it or not.
>> 1. There are two 'injection function' linked to 'syringe' which is realized
>> by 'vaccination' and 'pathogen challenge' processes. However, others like,
>> 'host role', 'target of material addition role' only shown once in the
>> figure. Did two 'injection function' classes mean differently?
>> 2. 'material to be added role' inheres_in 'vaccine', 'VacX' is instance_of
>> 'vaccine'. Are all instances of 'vaccine' bearer_of 'material to be added
>> role' or  only some of 'vaccine' instance, such as 'VacX', bearer_of
>> 'material to be added role'?  I think the one  shown in figure represent the
>> first meaning. If in the text description means the second option, we may
>> need to change the figure.
>>
>> Since I don't have much time working on it, the changes I pointed out were
>> what I thought we should make. Hope somebody else can check out whether
>> anything else need to be updated.
>>
>> Thanks,
>>
>> Jie
>>
>>
>> Yongqun He wrote:
>>>
>>> Hi Jie,
>>> I have updated Figure 2 as you instructed. The updated figure is committed
>>> to the SVN. Please check it out and let me know if more changes are needed.
>>> Thanks!
>>> Oliver
>>>
>>> >>> Jie Zheng <jiezheng@...> 2/25/2010 9:11 AM >>>
>>> Hi All,
>>>
>>> I think we don't need to make any modification for Figure 1 except
>>> adding Alan proposed text.
>>>
>>> In Figure2, add 'Influenza Virus' is instance_of  'Virus'. We should
>>> change instance 'mouse' is_a  'organism' to 'mouse' is instance_of
>>> 'organism or individual 'mouse' is instance_of 'Mus musculus' and 'Mus
>>> musculus' is_a 'organism'. Figure2 was drawn using Visio, I cannot help
>>> to modify it. Oliver, can you update it?
>>>
>>> Could someone else check any other changes we should make in the figures?
>>>
>>> Thanks,
>>>
>>> Jie
>>>
>>>
>>>
>>> Larisa Soldatova wrote:
>>> > Hi All,
>>> >
>>> > I got a reply from the Editors. The permitted to make changes in the
>>> > figures if we do it quickly.
>>> >
>>> > I will update fig. 3 as proposed. It would be great if someone can
>>> > take care about other figures: I have very heavy teaching load now and
>>> > cannot do anything extra.
>>> >
>>> > I wish to have your opinion on my suggestion to figures online and
>>> > give links to them in the paper.
>>> >
>>> > Thank you,
>>> > Larisa
>>> >
>>> >
>>> >> Hi Larisa,
>>> >>
>>> >> Agree with you. If we can change the relation between 'planning' and
>>> >> 'plan specification' should be good enough now.
>>> >>
>>> >> Thanks a lot for making the modification on figure/legend and trying
>>> >> to make it taken by the editors.
>>> >>
>>> >> Jie
>>> >>
>>> >> lss@... wrote:
>>> >>> Hi All,
>>> >>>
>>> >>> thank you to Timothy for reviewing our paper. Unfortunately it might
>>> >>> be
>>> >>> too late. I really can not predict how the editors would react on a
>>> >>> request to make several changes. I hoped that we can try to change
>>> >>> captions of figures (1 file). But if we need to change the figures
>>> >>> (they
>>> >>> are in separate files) we have to request to change all our
>>> >>> submission.
>>> >>> Maybe it is better to wait for proofs and try to do it on that stage.
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>>> (1) In Figure 3, ...
>>> >>>>>
>>> >>>> You are right. It may be easily fixed by changing the relation to:
>>> >>>> 'planning' has_specified_output 'plan specification'.
>>> >>>>
>>> >>>
>>> >>> OK, I will do that tomorrow (It is already late in UK)
>>> >>>
>>> >>>
>>> >>>
>>> >>>>> (3) In the latest version of the figures I saw, several
>>> >>>>> individuals seem
>>> >>>>> to not
>>> >>>>> be linked to any class through an 'instance_of' arrow -- for
>>> >>>>> example,
>>> >>>>> the
>>> >>>>> Influenza Virus individual in figure 2, and the metabolite
>>> >>>>> individual in
>>> >>>>> figure
>>> >>>>> 3.  Should those have classes indicated?
>>> >>>>>
>>> >>>>>
>>> >>>> It may be better in Figure 3, add 'metabolite C00449' is instance_of
>>> >>>> 'molecular entity'. In Figure2, add 'Influenza Virus' is instance_of
>>> >>>> 'Virus'. As you pointed out in another email. In the Figure 2, we
>>> >>>> should
>>> >>>> change instance 'mouse' is_a  'organism' to 'mouse' is instance_of
>>> >>>> 'organism or individual 'mouse' is instance_of 'Mus musculus' and
>>> >>>> 'Mus
>>> >>>> musculus' is_a 'organism'.
>>> >>>>
>>> >>>
>>> >>> The figures show only fragments, we can not include all relations into
>>> >>> diagrams as they are already complicated and we were criticized for
>>> >>> that.
>>> >>> I would refrain from making such sort of changes at this stage.
>>> >>> There is
>>> >>> nothing wrong with those relations, and short-cuts are logically
>>> >>> correct.
>>> >>> But we definitely should take this point of view (what relations to
>>> >>> show
>>> >>> in figures) into account for the main OBI paper.
>>> >>>
>>> >>> Larisa
>>> >>>
>>> >>
>>>
>>>
>>> **********************************************************
>>> Electronic Mail is not secure, may not be read every day, and should not
>>> be used for urgent or sensitive issues
>>
>>
>

**********************************************************
Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues

On Fri, Feb 26, 2010 at 1:17 PM, Yongqun He <yongqunh@...> wrote:
> Hi Alan,
>
> I agree with you that it may represent a big change. This new type of
> representation may need some time to discuss, digest, and agree by all. For
> now, I feel that this new type is not appropriate for this paper. I
> think that the method is not mature yet and will make the figure look more
> confusing. For example, it is very confusing to say  "light on tangent
> screen-21, instance of light source", "stimulation-12 instance of
> presentation of stimulus", etc. Readers do not care if it is stimulation-12
> or stimulation-11, which is probably not necessary to be included to make a
> nice story.

I think we could remove those markings. They were an attempt to
respect that the original figures made a distinction between some
instances being marked as such and others not.

> I prefer to still use the "traditional" figures with some changes to
> be incorporated based on recent discussions. For example, I have made
> several changes to the Figure 2, and these changes include those proposed by
> Jie, Timothy, and you.  I think current Figure 2 looks very good now.

I'll have a look at your revised picture and discuss it with Tim. (the
figure looked good before too :) - the question was whether it could
be clearly interpreted).

-Alan

> I  think that we can discuss your approach of representing in more details in
> our OBI meetings and Vancouver workshop.
>
> Oliver
>
>>>> Alan Ruttenberg <alanruttenberg@...> 2/25/2010 9:50 PM >>>
> Now it is really attached.
> -Alan
>
> On Thu, Feb 25, 2010 at 9:49 PM, Alan Ruttenberg
> <alanruttenberg@...> wrote:
>> Attached is an alternative arrangement of the neuroscience use case
>> for consideration. I have made the following changes:
>>
>> Each box now represents an individual, either explicitly named, or
>> not. All links in the diagram are to be understood as relations
>> between instances. Some are inferred, some explicitly asserted.
>>
>> Explicitly named instances have typographically distinguished names -
>> they are suffixed with a number, and in monospace font. Their type is
>> noted as "instance of <class name>".
>>
>> Un-named instances simply have their class name in the box. All class
>> names are bold face.
>>
>> I have added some participation and realization relations that exist
>> but were not stated, that I hope clarify some relationships.
>>
>> I realize this may be more changes than were expected, but this seems
>> like the simplest change that avoids the confusion of having to
>> explain how to interpret a mixture of  class-class and
>> instance-instance relations in the same diagram.
>>
>> If this approach to diagramming addressed the issue of clarity, and is
>> considered acceptable to the other authors, I can have a go at
>> adjusting the other two figures to follow the same style, and to add a
>> couple of sentences explaining how to read the figures.
>>
>> Jonathan, Tim, could you comment on whether this approach addresses
>> your concerns about clarity?
>> Co-authors, could you weigh in on whether we should go with this
>> approach or have another go at it.
>>
>> Thanks,
>>
>> -Alan
>>
>>
>>
>> On Thu, Feb 25, 2010 at 7:14 PM, jie zheng <jiezheng@...>
>> wrote:
>>> Hi Oliver,
>>>
>>> Thanks a lot for updating the figure 2.
>>>
>>> I looked the updated figure. You have changed all the issues I mentioned.
>>>
>>> Here are two additional issues were addressed in the previous email
>>> discussion with Timothy and Alan. You may consider whether we should
>>> change
>>> it or not.
>>> 1. There are two 'injection function' linked to 'syringe' which is
>>> realized
>>> by 'vaccination' and 'pathogen challenge' processes. However, others
>>> like,
>>> 'host role', 'target of material addition role' only shown once in the
>>> figure. Did two 'injection function' classes mean differently?
>>> 2. 'material to be added role' inheres_in 'vaccine', 'VacX' is
>>> instance_of
>>> 'vaccine'. Are all instances of 'vaccine' bearer_of 'material to be added
>>> role' or  only some of 'vaccine' instance, such as 'VacX', bearer_of
>>> 'material to be added role'?  I think the one  shown in figure represent
>>> the
>>> first meaning. If in the text description means the second option, we may
>>> need to change the figure.
>>>
>>> Since I don't have much time working on it, the changes I pointed out
>>> were
>>> what I thought we should make. Hope somebody else can check out whether
>>> anything else need to be updated.
>>>
>>> Thanks,
>>>
>>> Jie
>>>
>>>
>>> Yongqun He wrote:
>>>>
>>>> Hi Jie,
>>>> I have updated Figure 2 as you instructed. The updated figure is
>>>> committed
>>>> to the SVN. Please check it out and let me know if more changes are
>>>> needed.
>>>> Thanks!
>>>> Oliver
>>>>
>>>> >>> Jie Zheng <jiezheng@...> 2/25/2010 9:11 AM >>>
>>>> Hi All,
>>>>
>>>> I think we don't need to make any modification for Figure 1 except
>>>> adding Alan proposed text.
>>>>
>>>> In Figure2, add 'Influenza Virus' is instance_of  'Virus'. We should
>>>> change instance 'mouse' is_a  'organism' to 'mouse' is instance_of
>>>> 'organism or individual 'mouse' is instance_of 'Mus musculus' and 'Mus
>>>> musculus' is_a 'organism'. Figure2 was drawn using Visio, I cannot help
>>>> to modify it. Oliver, can you update it?
>>>>
>>>> Could someone else check any other changes we should make in the
>>>> figures?
>>>>
>>>> Thanks,
>>>>
>>>> Jie
>>>>
>>>>
>>>>
>>>> Larisa Soldatova wrote:
>>>> > Hi All,
>>>> >
>>>> > I got a reply from the Editors. The permitted to make changes in the
>>>> > figures if we do it quickly.
>>>> >
>>>> > I will update fig. 3 as proposed. It would be great if someone can
>>>> > take care about other figures: I have very heavy teaching load now and
>>>> > cannot do anything extra.
>>>> >
>>>> > I wish to have your opinion on my suggestion to figures online and
>>>> > give links to them in the paper.
>>>> >
>>>> > Thank you,
>>>> > Larisa
>>>> >
>>>> >
>>>> >> Hi Larisa,
>>>> >>
>>>> >> Agree with you. If we can change the relation between 'planning' and
>>>> >> 'plan specification' should be good enough now.
>>>> >>
>>>> >> Thanks a lot for making the modification on figure/legend and trying
>>>> >> to make it taken by the editors.
>>>> >>
>>>> >> Jie
>>>> >>
>>>> >> lss@... wrote:
>>>> >>> Hi All,
>>>> >>>
>>>> >>> thank you to Timothy for reviewing our paper. Unfortunately it might
>>>> >>> be
>>>> >>> too late. I really can not predict how the editors would react on a
>>>> >>> request to make several changes. I hoped that we can try to change
>>>> >>> captions of figures (1 file). But if we need to change the figures
>>>> >>> (they
>>>> >>> are in separate files) we have to request to change all our
>>>> >>> submission.
>>>> >>> Maybe it is better to wait for proofs and try to do it on that
>>>> >>> stage.
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>>>> (1) In Figure 3, ...
>>>> >>>>>
>>>> >>>> You are right. It may be easily fixed by changing the relation to:
>>>> >>>> 'planning' has_specified_output 'plan specification'.
>>>> >>>>
>>>> >>>
>>>> >>> OK, I will do that tomorrow (It is already late in UK)
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>>>> (3) In the latest version of the figures I saw, several
>>>> >>>>> individuals seem
>>>> >>>>> to not
>>>> >>>>> be linked to any class through an 'instance_of' arrow -- for
>>>> >>>>> example,
>>>> >>>>> the
>>>> >>>>> Influenza Virus individual in figure 2, and the metabolite
>>>> >>>>> individual in
>>>> >>>>> figure
>>>> >>>>> 3.  Should those have classes indicated?
>>>> >>>>>
>>>> >>>>>
>>>> >>>> It may be better in Figure 3, add 'metabolite C00449' is
>>>> >>>> instance_of
>>>> >>>> 'molecular entity'. In Figure2, add 'Influenza Virus' is
>>>> >>>> instance_of
>>>> >>>> 'Virus'. As you pointed out in another email. In the Figure 2, we
>>>> >>>> should
>>>> >>>> change instance 'mouse' is_a  'organism' to 'mouse' is instance_of
>>>> >>>> 'organism or individual 'mouse' is instance_of 'Mus musculus' and
>>>> >>>> 'Mus
>>>> >>>> musculus' is_a 'organism'.
>>>> >>>>
>>>> >>>
>>>> >>> The figures show only fragments, we can not include all relations
>>>> >>> into
>>>> >>> diagrams as they are already complicated and we were criticized for
>>>> >>> that.
>>>> >>> I would refrain from making such sort of changes at this stage.
>>>> >>> There is
>>>> >>> nothing wrong with those relations, and short-cuts are logically
>>>> >>> correct.
>>>> >>> But we definitely should take this point of view (what relations to
>>>> >>> show
>>>> >>> in figures) into account for the main OBI paper.
>>>> >>>
>>>> >>> Larisa
>>>> >>>
>>>> >>
>>>>
>>>>
>>>> **********************************************************
>>>> Electronic Mail is not secure, may not be read every day, and should not
>>>> be used for urgent or sensitive issues
>>>
>>>
>>
>
> **********************************************************
> Electronic Mail is not secure, may not be read every day, and should not be
> used for urgent or sensitive issues