[Obi-protocol-application-branch] Change to 'Data Collection' and 'Prediction' classes

1 view
Skip to first unread message

James Malone

unread,
Feb 9, 2009, 9:55:36 AM2/9/09
to Protocol App Branch
Hi Plan People,

I've added the new information transformation (IT) class to OBI. As a
consequence, the reasoner has now classified 'data collection' and
'prediction' as children of IT (as well as data transformation which i
was expecting). In future, I will get around to making DT a defined
class as well (I have not presently because not everything asserted
there is defined sufficiently to fall under DT and I would like to keep
them there for now). Presumably they would both fall under DT then as
they deal with data (not ICE). This raises the question over the
'prediction' class. This sounds like an objective (since many DTs can
be used for this purpose presumably). My suggestion would be we
obsolete this in favour of creating a 'prediction objective
specification' which encapsulates the same meaning.

I am less sure about data collection but the placement under IT seems to
fit. (Side note, IAO are going to add 'data collection' with a totally
different meaning, we might wish to rename this).

James


--
European Bioinformatics Institute,
Wellcome Trust Genome Campus,
Hinxton,
Cambridge, CB10 1SD,
United Kingdom
Tel: + 44 (0) 1223 494 676
Fax: + 44 (0) 1223 492 468


------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
Obi-protocol-application-branch mailing list
Obi-protocol-ap...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/obi-protocol-application-branch

Bjoern Peters

unread,
Feb 9, 2009, 10:26:15 PM2/9/09
to James Malone, Protocol App Branch
I like the idea of a 'prediction objective specification'. It should be
subclassed by what is predicted. That means that processes with that
objective have as a specified output a 'prediction', which should be an
information content type similar to 'Hypothesis'. We can than subtype
predictions by what they are 'about'.

- Bjoern

- Bjoern


James Malone wrote:
> Hi Plan People,
>
> I've added the new information transformation (IT) class to OBI. As a
> consequence, the reasoner has now classified 'data collection' and
> 'prediction' as children of IT (as well as data transformation which i
> was expecting). In future, I will get around to making DT a defined
> class as well (I have not presently because not everything asserted
> there is defined sufficiently to fall under DT and I would like to keep
> them there for now). Presumably they would both fall under DT then as
> they deal with data (not ICE). This raises the question over the
> 'prediction' class. This sounds like an objective (since many DTs can
> be used for this purpose presumably). My suggestion would be we
> obsolete this in favour of creating a 'prediction objective
> specification' which encapsulates the same meaning.
>
> I am less sure about data collection but the placement under IT seems to
> fit. (Side note, IAO are going to add 'data collection' with a totally
> different meaning, we might wish to rename this).
>
> James
>
>
>

Melanie Courtot

unread,
Feb 9, 2009, 11:07:01 PM2/9/09
to Bjoern Peters, Protocol App Branch
Hi,

I was looking at the conferred qualities this afternoon, and was
thinking the same when looking at "predicted". Similarly maybe for
"validation" and "validated" (though the process doesn't have the
restrictions yet thus doesn't fall under the new IT class for now)

Predicted is currently defined as output of prediction process, so
doesn't cover the DT class prediction process. I was thinking that we
could maybe adopt the system implemented by DT for normalized data
set, i.e,, having the objective, the defined class "prediction
process" defined as all processes with objective prediction (which
seems to be exactly what James suggested :) ) and then use that to
define "predicted data item" .

I was also wondering if we should consider having an IT objective
under objective specification, of which data transformation would be a
subclass?

Melanie

---
Mélanie Courtot
TFL- BCCRC
675 West 10th Avenue
Vancouver, BC
V5Z 1L3, Canada

Alan Ruttenberg

unread,
Feb 9, 2009, 11:42:00 PM2/9/09
to Melanie Courtot, Protocol App Branch
> I was also wondering if we should consider having an IT objective
> under objective specification, of which data transformation would be a
> subclass?

I'm not immediately keen on this. I think that objectives should stay
very biologically focused and very few have, as an objective, to
simply transform data (exceptions would be perhaps archivists, people
who design compression algorithms, etc.).

-Alan

Melanie Courtot

unread,
Feb 10, 2009, 12:31:24 AM2/10/09
to Alan Ruttenberg, Protocol App Branch
While I agree with you that the most high-level objective in the
context of OBI is biologically oriented, I think we need to be able to
assign objectives at the process level.
One of the original need for the objectives originated from the DT
branch, when we realized we had multiple inheritance trouble, as one
method can be used with different goals.

We currently have around 20 objectives regarding data manipulation,
like averaging, normalization, class prediction, merging,
partitioning..., and they are essential for example for the
GenePattern use case James prepared (http://docs.google.com/Doc?id=dm9czrk_8gsrndsft&hl=en
)

Considering that the data transformation class is now a subclass of
Information transformation, I think it would make sense to reflect
that in the objective specification hierarchy too, to cover cases like
prediction.

Does that seem more reasonable?

Melanie

Alan Ruttenberg

unread,
Feb 10, 2009, 4:37:15 AM2/10/09
to Melanie Courtot, Protocol App Branch
On Tue, Feb 10, 2009 at 12:31 AM, Melanie Courtot <mcou...@gmail.com> wrote:
While I agree with you that the most high-level objective in the context of OBI is biologically oriented, I think we need to be able to assign objectives at the process level.

Why?
 
One of the original need for the objectives originated from the DT branch, when we realized we had multiple inheritance trouble, as one method can be used with different goals.

Agreed.
 
We currently have around 20 objectives regarding data manipulation, like averaging, normalization, class prediction, merging, partitioning..., and they are essential for example for the GenePattern use case James prepared (http://docs.google.com/Doc?id=dm9czrk_8gsrndsft&hl=en)

Agreed.
 
Considering that the data transformation class is now a subclass of Information transformation, I think it would make sense to reflect that in the objective specification hierarchy too, to cover cases like prediction.

First, I'm not convinced that there should be a subclass of information transformation called data transformation. I'm behind on reviewing the changes that were suggested by denrie, and even if sensible it's not obvious (to me) that the class changes under ICE need to be reflected in the process hierarchy.

Second I don't see why the objective specification hierarchy need replicate the process hierarchy. 
 
Does that seem more reasonable?

Sigh. Can't answer this one without getting in to trouble :) 
The suggestions are "reasonable" in both cases. Far be it from me to suggest that they are "unreasonable".
However, I don't agree, atm.

"of course, I may be wrong" 

James Malone

unread,
Feb 10, 2009, 4:58:46 AM2/10/09
to Alan Ruttenberg, OBI-DataTransform Branch, Protocol App Branch
I interpret Melanie's first email to mean we need to be able to assign
objectives at the planned process level, presumably, which is of course
correct because objective specification is_a information about a
realizable. So I don't seen the problem. This fits present usage and
also the usage suggested by Melanie. I can certainly see you might
follow a particular planned process to achieve a different objective. I
also don't see the need for these to be biologically oriented. We break
this rule with data transformation generally as we have numerous DTs
that are not biologically oriented and rather capture the mathematical
sense of the process. This has been the scope of DT from the start. As
I suggested yesterday in my email to DT branch, I suspect DT (or IT)
will probably also move to a separate ontology in time, akin to IAO for
this reason.

I'm not sure if the class 'data transformation' is required also, but
this is because the difference between information and data is new and
I'm still unsure if we've captured the differences adequately, time will
tell. My instinct tells me there IS a need to separate data and
information and I think we have made a start on that at the workshop
and, consequently, there is likely a usefulness in being able to
separate things that operate on data (data transformations) and things
that operate on information but we will see as we continue our
development. So, in summary, I don't think it's useful to start a
debate on whether the class DT should disappear or not and I think
objectives should be permitted on planned processes, whatever they are.

"But I could also be wrong." "Though I'm probably not." :)

James

Alan Ruttenberg wrote:
>
>
> On Tue, Feb 10, 2009 at 12:31 AM, Melanie Courtot <mcou...@gmail.com
> <mailto:mcou...@gmail.com>> wrote:
>
> While I agree with you that the most high-level objective in the
> context of OBI is biologically oriented, I think we need to be
> able to assign objectives at the process level.
>
>
> Why?
>
>
> One of the original need for the objectives originated from the DT
> branch, when we realized we had multiple inheritance trouble, as
> one method can be used with different goals.
>
>
> Agreed.
>
>
> We currently have around 20 objectives regarding data
> manipulation, like averaging, normalization, class prediction,
> merging, partitioning..., and they are essential for example for
> the GenePattern use case James prepared
> (http://docs.google.com/Doc?id=dm9czrk_8gsrndsft&hl=en

> <http://docs.google.com/Doc?id=dm9czrk_8gsrndsft&hl=en>)

> <mailto:Obi-protocol-ap...@lists.sourceforge.net>


> https://lists.sourceforge.net/lists/listinfo/obi-protocol-application-branch
>
>
> ---
> Mélanie Courtot
> TFL- BCCRC
> 675 West 10th Avenue
> Vancouver, BC
> V5Z 1L3, Canada
>
>
>
>
>
> ------------------------------------------------------------------------------
> Create and Deploy Rich Internet Apps outside the browser
> with Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing
> skills and code to
> build responsive, highly engaging applications that
> combine the power of local
> resources and data with the reach of the web. Download the
> Adobe AIR SDK and
> Ajax docs to start building applications
> today-http://p.sf.net/sfu/adobe-com
> _______________________________________________
> Obi-protocol-application-branch mailing list
> Obi-protocol-ap...@lists.sourceforge.net

> <mailto:Obi-protocol-ap...@lists.sourceforge.net>


> https://lists.sourceforge.net/lists/listinfo/obi-protocol-application-branch
>
>
> ---
> Mélanie Courtot
> TFL- BCCRC
> 675 West 10th Avenue
> Vancouver, BC
> V5Z 1L3, Canada
>
>
>
>
>
> ------------------------------------------------------------------------
>

> ------------------------------------------------------------------------------
> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and code to
> build responsive, highly engaging applications that combine the power of local
> resources and data with the reach of the web. Download the Adobe AIR SDK and
> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com

> ------------------------------------------------------------------------


>
> _______________________________________________
> Obi-protocol-application-branch mailing list
> Obi-protocol-ap...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/obi-protocol-application-branch
>

--
European Bioinformatics Institute,
Wellcome Trust Genome Campus,
Hinxton,
Cambridge, CB10 1SD,
United Kingdom
Tel: + 44 (0) 1223 494 676
Fax: + 44 (0) 1223 492 468

Melanie Courtot

unread,
Feb 10, 2009, 11:08:59 AM2/10/09
to James Malone, OBI-DataTransform Branch, Protocol App Branch
Comments in line.

On 10-Feb-09, at 1:58 AM, James Malone wrote:

> I interpret Melanie's first email to mean we need to be able to
> assign objectives at the planned process level, presumably, which is
> of course correct because objective specification is_a information
> about a realizable. So I don't seen the problem. This fits present
> usage and also the usage suggested by Melanie. I can certainly see
> you might follow a particular planned process to achieve a different
> objective. I also don't see the need for these to be biologically
> oriented. We break this rule with data transformation generally as
> we have numerous DTs that are not biologically oriented and rather
> capture the mathematical sense of the process. This has been the
> scope of DT from the start. As I suggested yesterday in my email to
> DT branch, I suspect DT (or IT) will probably also move to a
> separate ontology in time, akin to IAO for this reason.


I was only suggesting that for example regarding the prediction class,
the only objective we have is "class prediction objective", under data
transformation objective.

If we add an objective "prediction objective specification", it can't
be a subclass of data transformation objective, which definition
currently is: " A data transformation objective is an objective
specification that a data transformation may have towards which the
realization of that transformation is directed. ".
I was therefore proposing to add a superclass information
transformation objective which would be parent of the current data
transformation objective and of the newly created prediction objective.

We need objective at the planned process level because that is the
level experimentalists are working at as shown in our use cases. They
want to be able to select for example all methods used for
normalization.

I agree with Alan that there is no strict constraint that the process
hierarchy be duplicated in the objective hierarchy: in this case I
think we have the option to renaming data transformation objective and
amend the definition or add a superclass. The latter seems cleaner to
me.

>
>
> I'm not sure if the class 'data transformation' is required also,
> but this is because the difference between information and data is
> new and I'm still unsure if we've captured the differences
> adequately, time will tell. My instinct tells me there IS a need to
> separate data and information and I think we have made a start on
> that at the workshop and, consequently, there is likely a usefulness
> in being able to separate things that operate on data (data
> transformations) and things that operate on information but we will
> see as we continue our development.

I have trouble pinpointing exactly the difference too, though I feel
there is one. At the moment I am thinking something along the lines of
DT are processes implemented by machine/computers, logical operations,
whereas IT are more mind processes. (though that is clearly not a
satisfying definition, nor intended to be, just a general feeling)

> So, in summary, I don't think it's useful to start a debate on
> whether the class DT should disappear or not and I think objectives
> should be permitted on planned processes, whatever they are.

>
> "But I could also be wrong." "Though I'm probably not." :)

No prediction about whether DT will disappear or not - I vote keeping
it until proven wrong.

"Though I don't see how that could happen" ;)

Melanie

https://lists.sourceforge.net/lists/listinfo/obi-protocol-application-branch

Reply all
Reply to author
Forward
0 new messages