search

broadinstitute / BARD

BioAssay Research Database
20 stars 4 forks source link

Hierarchy of Result Types / measures #4

Closed dllahr closed 11 years ago

dllahr commented 11 years ago

Latest agreements:

original statement:

I would like to push forward with useful our discussion of the hierarchy of result types / measures that we had at NCGC last Thursday.

Let me start by proposing some common vocabulary (please suggest changes!)

Current proposal:

Original proposal: 1) Within an assay definition, individual result types are associated with assay contexts. No hierarchy is specified 2) Within an experiment, the experiment hierarchy is specified, based on the result types(set A) that are associated with assay contexts in the assay definition for that experiment.

3) more advanced: within an assay definition the display result hierarchy may be defined. Same rules as experiment hierarchy apply

southalln commented 11 years ago

Multiple issues, starting with the most straightforward:

\* intrinsic result type hierarchy

Does this exist? If so, where can I find it for 'fold-shift'? Does it really help one understand which PIs go with which IC50s when there are multiple such IC50s?

\* Within an assay definition, individual result types are associated with assay contexts

Experiments have individual result types, not sure about assays. Are the assay result types then the superset of all the experiment result types?

schatwin commented 11 years ago

intrinsic result type hierarchy Not sure if it's really intrinsic, but yes a default hierarchy can (should?) be set up in the assay definition. It makes it simpler for users of the assay further down the process flow. This may be one of potential benefits of creating a set of 'template' assays. (see http://broadinstitute.github.com/BARD/UML%20-%20CAP%20and%20Data%20Entry/EARoot/EA2/EA3/EA461.htm).

result types are associated with assay contexts Yes, and a measure can be associated with multiple contexts (see the Vanderbilt ones we've been looking at recently). This is defined in the assay and the links remain the same (are not messed with) in the upload of experiment results.

For an experiment, yes, the result types MUST be a subset of the ones defined in the assay. If you don't have the one you need, it's not a big deal to add it to the assay definition (it'll version the definition, but no other consequences because it does not affect the biology under test or invalidate previously loaded results). We force this on the users to ensure they have looked at the assay definition and have had the opportunity to link the new measure to the correct assay contexts.

Whether the experiment result types must use the same drill down as the assay definition is an open question. I haven't yet seen an example of where they might be different, but I don't get out a lot. Currently we're proposing to model this so they can have different drill downs, but I'm not sure that this makes scientific sense.

benralexander commented 11 years ago

This thread brings a few questions to mind:

1) Can we explicitly list the intrinsic result type hierarchy? Until we have a prototype list we can’t start to identify the missing elements. I like the template-based approach, but can we come up with those templates a priori, or do we instead accumulate them as we go? 2) I like Dave's idea of a display result hierarchy, at least in principle. What happens, however, when a user wants to pivot the data and aggregate it based on a different quantity? Are those two different approaches to aggregating data all held within the same display result type hierarchy? Or maybe users move between different subclasses within the display hierarchy? 3) I understand Simon's point that different experimental result types must be defined in the assay, but I wonder about the mechanics of adding to that assay definition over the long term. I presume that results aren't back-filled with nulls for previous experiments, but that we depend on different version numbers to permit different definitions? Will it be clear how to compare experiments across different assay definition versions? Is there ever a point when we've made enough modifications to the assay definition that we need to split it, or can we always keep expanding it?

schatwin commented 11 years ago

1) I think it's possible, but remember that each assay has its own drill-down hierarchy. A template is simply an assay where assay_type = 'Template'. We can gather these templates over time, but I understand Josh/Paul have a good idea of what the initial set should be.

3) If the modification to an assay definition does not change the biology tested, it does not create a new assay. This overlaps with the requirements for uniqueness in assay definitions. So the only time we would want to fork the definition and create a new assay is when the biology of the assay is changed. The rules for editing parts of the assay definition and thus what creates a new version and what a new assay are outlined here Edit an Assay with Exprmts.

With these rules in mind, ALL experiments for one assay exercise the same biological conditions, thus the results in those experiments can always be compared and aggregated. But clearly you wouldn't aggregate IC50 and PI results together. Thus we define the header for a column in the molecular spreadsheet with the assay and the result type. So aggregation/comparison basically employs that simplistic definition of a result: that it is the intersection of a substance, a result type and a biological context (a.k.a. assay). In the molecular spreadsheet these are the row and column headers.

So, to your point above, there is no point at which you have made enough modifications to create a new assay. Versions in assays are not like versions in software, for assay versions always happen within the unique biological circumstances of the assay and they do not affect the uniqueness of the assay.

Also notice that only the latest version of an assay is ever used - you don't need to go back to a previous version (remember: deletion is not allowed in versionning to prevent the user invalidating earlier results). The current version contains all the previous versions.

dllahr commented 11 years ago

Great discussion, thank you all. To help clarify I've added some definitions and made some slight tweaks to the definitions / vocabulary we are using:

important modification:

On Wed, Nov 14, 2012 at 10:10 AM, Simon notifications@github.com wrote:

1) I think it's possible, but remember that each assay has its own drill-down hierarchy. A template is simply an assay where assay_type = 'Template'. We can gather these templates over time, but I understand Josh/Paul have a good idea of what the initial set should be.

3) If the modification to an assay definition does not change the biology tested, it does not create a new assay. This overlaps with the requirements for uniqueness in assay definitions. So the only time we would want to fork the definition and create a new assay is when the biology of the assay is changed. The rules for editing parts of the assay definition and thus what creates a new version and what a new assay are outlined here Edit an Assay with Exprmtshttp://broadinstitute.github.com/BARD/UML%20-%20CAP%20and%20Data%20Entry/EARoot/EA3/EA2/EA525.htm .

With these rules in mind, ALL experiments for one assay exercise the same biological conditions, thus the results in those experiments can always be compared and aggregated. But clearly you wouldn't aggregate IC50 and PI results together. Thus we define the header for a column in the molecular spreadsheet with the assay and the result type. So aggregation/comparison basically employs that simplistic definition of a result: that it is the intersection of a substance, a result type and a biological context (a.k.a. assay). In the molecular spreadsheet these are the row and column headers.

So, to your point above, there is no point at which you have made enough modifications to create a new assay. Versions in assays are not like versions in software, for assay versions always happen within the unique biological circumstances of the assay and they do not affect the uniqueness of the assay.

Also notice that only the latest version of an assay is ever used - you don't need to go back to a previous version (remember: deletion is not allowed in versionning to prevent the user invalidating earlier results). The current version contains all the previous versions.

— Reply to this email directly or view it on GitHubhttps://github.com/broadinstitute/BARD/issues/4#issuecomment-10369335.

617 714 7868 dlahr@broadinstitute.org

dllahr commented 11 years ago

To answer Noel's questions:

intrinsic result type hierarchy

Does this exist? If so, where can I find it for 'fold-shift'? Does it really help one understand which PIs go with which IC50s when there are multiple such IC50s?

Within an assay definition, individual result types are associated with assay contexts

Experiments have individual result types, not sure about assays. Are the assay result types then the superset of all the experiment result types?

On Wed, Nov 14, 2012 at 6:50 PM, David Lahr dlahr@broadinstitute.orgwrote:

Great discussion, thank you all. To help clarify I've added some definitions and made some slight tweaks to the definitions / vocabulary we are using:

  • result type - abstract concept of a scientific measurement - e.g. the concept of IC50, not a specific IC50 value
  • measure - instance of a result type - occurs within experiments - a specific IC50 value

important modification:

  • intrinsic result type hierarchy - the "derived from" relationship between result types / measures as defined in the ontology. It is independent of an assay definition or an experiment or display options
  • i.e. mean IC50 is derived from IC50 is derived from percent inhibition (PI)

On Wed, Nov 14, 2012 at 10:10 AM, Simon notifications@github.com wrote:

1) I think it's possible, but remember that each assay has its own drill-down hierarchy. A template is simply an assay where assay_type = 'Template'. We can gather these templates over time, but I understand Josh/Paul have a good idea of what the initial set should be.

3) If the modification to an assay definition does not change the biology tested, it does not create a new assay. This overlaps with the requirements for uniqueness in assay definitions. So the only time we would want to fork the definition and create a new assay is when the biology of the assay is changed. The rules for editing parts of the assay definition and thus what creates a new version and what a new assay are outlined here Edit an Assay with Exprmtshttp://broadinstitute.github.com/BARD/UML%20-%20CAP%20and%20Data%20Entry/EARoot/EA3/EA2/EA525.htm .

With these rules in mind, ALL experiments for one assay exercise the same biological conditions, thus the results in those experiments can always be compared and aggregated. But clearly you wouldn't aggregate IC50 and PI results together. Thus we define the header for a column in the molecular spreadsheet with the assay and the result type. So aggregation/comparison basically employs that simplistic definition of a result: that it is the intersection of a substance, a result type and a biological context (a.k.a. assay). In the molecular spreadsheet these are the row and column headers.

So, to your point above, there is no point at which you have made enough modifications to create a new assay. Versions in assays are not like versions in software, for assay versions always happen within the unique biological circumstances of the assay and they do not affect the uniqueness of the assay.

Also notice that only the latest version of an assay is ever used - you don't need to go back to a previous version (remember: deletion is not allowed in versionning to prevent the user invalidating earlier results). The current version contains all the previous versions.

— Reply to this email directly or view it on GitHubhttps://github.com/broadinstitute/BARD/issues/4#issuecomment-10369335.

617 714 7868 dlahr@broadinstitute.org

617 714 7868 dlahr@broadinstitute.org

dllahr commented 11 years ago

On Tue, Nov 13, 2012 at 6:34 PM, Simon notifications@github.com wrote:

intrinsic result type hierarchy Not sure if it's really intrinsic, but yes a default hierarchy can (should?) be set up in the assay definition. It makes it simpler for users of the assay further down the process flow. This may be one of potential benefits of creating a set of 'template' assays. (see http://broadinstitute.github.com/BARD/UML%20-%20CAP%20and%20Data%20Entry/EARoot/EA2/EA3/EA461.htm ).

Agreed that instrinsic is not quite the right word but the phrase "derived from relationships in the ontology" is a bit bulky. This is not the hierarcy between result types that exist in an Assay definition - we do not have a vocab term for that yet.

result types are associated with assay contexts

Yes, and a measure can be associated with multiple contexts (see the Vanderbilt ones we've been looking at recently). This is defined in the assay and the links remain the same (are not messed with) in the upload of experiment results.

Agreed - the result type corresponding to the measure is associated to as many assay contexts as the user wishes

For an experiment, yes, the result types MUST be a subset of the ones defined in the assay. If you don't have the one you need, it's not a big deal to add it to the assay definition (it'll version the definition, but no other consequences because it does not affect the biology under test or invalidate previously loaded results). We force this on the users to ensure they have looked at the assay definition and have had the opportunity to link the new measure to the correct assay contexts.

agreed

Whether the experiment result types must use the same drill down as the assay definition is an open question. I haven't yet seen an example of where they might be different, but I don't get out a lot. Currently we're proposing to model this so they can have different drill downs, but I'm not sure that this makes scientific sense.

We are working to figure this one out. I claim that if there is an intrinsic hierarchy (==derived from relationships between result types in the ontology) then the users do not need to specify it in assay definition. What they will do is specify relationship between measures for their experiments, and this will be constrained to follow the intrinsic hierarchy (allowed to skip intermediates but there must be a path through the directed acyclic graph between measures)

— Reply to this email directly or view it on GitHubhttps://github.com/broadinstitute/BARD/issues/4#issuecomment-10348856.

617 714 7868 dlahr@broadinstitute.org

dllahr commented 11 years ago

To Ben's questions:

On Wed, Nov 14, 2012 at 8:02 AM, Ben R. Alexander notifications@github.comwrote:

This thread brings a few questions to mind:

1) Can we explicitly list the intrinsic result type hierarchy? Until we have a prototype list we can’t start to identify the missing elements. I like the template-based approach, but can we come up with those templates a priori, or do we instead accumulate them as we go?

Yes, Paul will work on this. We will start to build templates a priori (Tuesday we are meeting with the MLP Assay Dev working group on this coincidentally)

2) I like Dave's idea of a display result hierarchy, at least in principle. What happens, however, when a user wants to pivot the data and aggregate it based on a different quantity? Are those two different approaches to aggregating data all held within the same display result type hierarchy? Or maybe users move between different subclasses within the display hierarchy?

I would say that the display result hierarchy is the default setting, and then as an even more advanced feature the end user could specify a new display result hierarchy to use in the pivot/aggregation. And/or navigation through the hierarchy as you suggest.

3) I understand Simon's point that different experimental result types must be defined in the assay, but I wonder about the mechanics of adding to that assay definition over the long term. I presume that results aren't back-filled with nulls for previous experiments, but that we depend on different version numbers to permit different definitions? Will it be clear how to compare experiments across different assay definition versions? Is there ever a point when we've made enough modifications to the assay definition that we need to split it, or can we always keep expanding it?

A key point here is that there is no requirement that an experiment fill in any of the result types that are associated with the assay definition. The reverse is true: an experiment can only provide measures(result type instances) for the result types that are defined in the assay definition. So we have to deal with this issue independently of what we decide regarding result type hierarchies.

— Reply to this email directly or view it on GitHubhttps://github.com/broadinstitute/BARD/issues/4#issuecomment-10365185.

617 714 7868 dlahr@broadinstitute.org

dllahr commented 11 years ago

To Timon's second set of points:

On Wed, Nov 14, 2012 at 10:10 AM, Simon notifications@github.com wrote:

1) I think it's possible, but remember that each assay has its own drill-down hierarchy. A template is simply an assay where assay_type = 'Template'. We can gather these templates over time, but I understand Josh/Paul have a good idea of what the initial set should be.

3) If the modification to an assay definition does not change the biology tested, it does not create a new assay. This overlaps with the requirements for uniqueness in assay definitions. So the only time we would want to fork the definition and create a new assay is when the biology of the assay is changed. The rules for editing parts of the assay definition and thus what creates a new version and what a new assay are outlined here Edit an Assay with Exprmtshttp://broadinstitute.github.com/BARD/UML%20-%20CAP%20and%20Data%20Entry/EARoot/EA3/EA2/EA525.htm .

agreed, absolutely

With these rules in mind, ALL experiments for one assay exercise the same biological conditions, thus the results in those experiments can always be compared and aggregated. But clearly you wouldn't aggregate IC50 and PI results together. Thus we define the header for a column in the molecular spreadsheet with the assay and the result type. So aggregation/comparison basically employs that simplistic definition of a result: that it is the intersection of a substance, a result type and a biological context (a.k.a. assay). In the molecular spreadsheet these are the row and column headers.

agreed

So, to your point above, there is no point at which you have made enough modifications to create a new assay. Versions in assays are not like versions in software, for assay versions always happen within the unique biological circumstances of the assay and they do not affect the uniqueness of the assay.

to clarify, by adding result types to the assay there is no point at which you will create a new assay.

Also notice that only the latest version of an assay is ever used - you don't need to go back to a previous version (remember: deletion is not allowed in versionning to prevent the user invalidating earlier results). The current version contains all the previous versions.

— Reply to this email directly or view it on GitHubhttps://github.com/broadinstitute/BARD/issues/4#issuecomment-10369335.

617 714 7868 dlahr@broadinstitute.org

dllahr commented 11 years ago

I'm going to try to summarize where we are:

Is everyone else in rough agreement with these points?

On Wed, Nov 14, 2012 at 7:09 PM, David Lahr dlahr@broadinstitute.orgwrote:

To Timon's second set of points:

On Wed, Nov 14, 2012 at 10:10 AM, Simon notifications@github.com wrote:

1) I think it's possible, but remember that each assay has its own drill-down hierarchy. A template is simply an assay where assay_type = 'Template'. We can gather these templates over time, but I understand Josh/Paul have a good idea of what the initial set should be.

3) If the modification to an assay definition does not change the biology tested, it does not create a new assay. This overlaps with the requirements for uniqueness in assay definitions. So the only time we would want to fork the definition and create a new assay is when the biology of the assay is changed. The rules for editing parts of the assay definition and thus what creates a new version and what a new assay are outlined here Edit an Assay with Exprmtshttp://broadinstitute.github.com/BARD/UML%20-%20CAP%20and%20Data%20Entry/EARoot/EA3/EA2/EA525.htm .

agreed, absolutely

With these rules in mind, ALL experiments for one assay exercise the same biological conditions, thus the results in those experiments can always be compared and aggregated. But clearly you wouldn't aggregate IC50 and PI results together. Thus we define the header for a column in the molecular spreadsheet with the assay and the result type. So aggregation/comparison basically employs that simplistic definition of a result: that it is the intersection of a substance, a result type and a biological context (a.k.a. assay). In the molecular spreadsheet these are the row and column headers.

agreed

So, to your point above, there is no point at which you have made enough modifications to create a new assay. Versions in assays are not like versions in software, for assay versions always happen within the unique biological circumstances of the assay and they do not affect the uniqueness of the assay.

to clarify, by adding result types to the assay there is no point at which you will create a new assay.

Also notice that only the latest version of an assay is ever used - you don't need to go back to a previous version (remember: deletion is not allowed in versionning to prevent the user invalidating earlier results). The current version contains all the previous versions.

— Reply to this email directly or view it on GitHubhttps://github.com/broadinstitute/BARD/issues/4#issuecomment-10369335.

617 714 7868 dlahr@broadinstitute.org

617 714 7868 dlahr@broadinstitute.org

southalln commented 11 years ago

This seems correct, with some minor points still a bit confusing, like “(allowed to skip intermediates but there must be a path through the directed acyclic graph between measures)”

I think it would help to add some specific examples to the ‘intrinsic hierarchy’ discussion. For instance, you said that IC50s are intrinsically related to percent inhibition (I think that was said). But just as often, using the same assay, people take the raw reads and calculate IC50s directly from RLUs. Are RLUs and IC50s also intrinsically linked in the BARD dictionary or is it just PIs? What about ratiometric assays where I first take the ratio of acceptor and donor and then fit those ratios into a Hill model – are these terms also going to be intrinsically linked? It seems like a stretch to force the dictionary to hold these relationships in canonical way.

Noel

From: dllahr [mailto:notifications@github.com] Sent: Wednesday, November 14, 2012 7:16 PM To: broadinstitute/BARD Cc: Southall, Noel (NIH/NCATS) [E] Subject: Re: [BARD] Hierarchy of Result Types / measures (#4)

I'm going to try to summarize where we are:

Is everyone else in rough agreement with these points?

On Wed, Nov 14, 2012 at 7:09 PM, David Lahr dlahr@broadinstitute.org<mailto:dlahr@broadinstitute.org>wrote:

To Timon's second set of points:

On Wed, Nov 14, 2012 at 10:10 AM, Simon notifications@github.com<mailto:notifications@github.com> wrote:

1) I think it's possible, but remember that each assay has its own drill-down hierarchy. A template is simply an assay where assay_type = 'Template'. We can gather these templates over time, but I understand Josh/Paul have a good idea of what the initial set should be.

3) If the modification to an assay definition does not change the biology tested, it does not create a new assay. This overlaps with the requirements for uniqueness in assay definitions. So the only time we would want to fork the definition and create a new assay is when the biology of the assay is changed. The rules for editing parts of the assay definition and thus what creates a new version and what a new assay are outlined here Edit an Assay with Exprmtshttp://broadinstitute.github.com/BARD/UML%20-%20CAP%20and%20Data%20Entry/EARoot/EA3/EA2/EA525.htm .

agreed, absolutely

With these rules in mind, ALL experiments for one assay exercise the same biological conditions, thus the results in those experiments can always be compared and aggregated. But clearly you wouldn't aggregate IC50 and PI results together. Thus we define the header for a column in the molecular spreadsheet with the assay and the result type. So aggregation/comparison basically employs that simplistic definition of a result: that it is the intersection of a substance, a result type and a biological context (a.k.a. assay). In the molecular spreadsheet these are the row and column headers.

agreed

So, to your point above, there is no point at which you have made enough modifications to create a new assay. Versions in assays are not like versions in software, for assay versions always happen within the unique biological circumstances of the assay and they do not affect the uniqueness of the assay.

to clarify, by adding result types to the assay there is no point at which you will create a new assay.

Also notice that only the latest version of an assay is ever used - you don't need to go back to a previous version (remember: deletion is not allowed in versionning to prevent the user invalidating earlier results). The current version contains all the previous versions.

— Reply to this email directly or view it on GitHubhttps://github.com/broadinstitute/BARD/issues/4#issuecomment-10369335.

617 714 7868 dlahr@broadinstitute.orgmailto:dlahr@broadinstitute.org

617 714 7868 dlahr@broadinstitute.orgmailto:dlahr@broadinstitute.org

— Reply to this email directly or view it on GitHubhttps://github.com/broadinstitute/BARD/issues/4#issuecomment-10392244.

schatwin commented 11 years ago

I agree with Noel's concerns about the "intrinsic hierarchy" being expressed in the ontology (sorry, I use dictionary and ontology interchangeably and know I shouldn't, but never know which term to use when..)

I worry that it may not be practical to lay out all the 'derived from' relationships in the ontology. I'm afraid we'll get a horrendous mish-mash of nearly everything connected to nearly everything else. But until we try it (Noel's "we need to see some examples...") we won't know if it's good enough. The data structure is already in place to support hierarchies in the dictionary, the assay definition or the experiment; take your pick.

Let's try some and see how it fairs. Unfortunately we won't be able to do this effectively until we start in on the Measures user stories for the assay definition.

I can work with Mark to start getting his mappings converted into Measures and Assay Contexts and that will show some 'derived from' hierarchy. This can be extracted for use in the dictionary. As we do the UI for this we can add the relationships for the "intrinsic hierarchy" bit by bit and watch how useful and/or unmanageable it gets.

We can also add parentage (derived from) to the existing Measures in the CAP DB. We've got about 900 measures listed so far for all the assays.

sbrudz commented 11 years ago

I worry about asking scientists to define result hierarchies at the assay definition level.

As Simon noted earlier in this thread, assay definitions are intended to be abstractions and whether the scientist is measuring a PI at one concentration in three replicates or 10 PIs at dose in a single replicate is really a decision at the experiment level.

If that's the case then we should model it as such.

I propose that we capture only 'defining' result types at the assay definition level and capture the specific hierarchy of result types at the experiment level. 'Defining' result types are those that the assay definition is specifically designed to measure. They have no particular hierarchy at the assay definition level, but the hierarchy defined at the experiment level must include all of them. This would take all of the complexity of replicates and means out of the assay definition and make it more of a proper abstraction.

For example, a Vanderbilt ratiometric assay designed to measure how the presence of compound effects the uptake of glutamate might have 'fold shift', 'fold max', 'EC50 for vehicle', and 'EC50 for vehicle + compound' as its defining result types. If they then did two experiments with the same biology but one with the compound at constant concentration & vehicle at dose and the other with both compound & vehicle at varying dose, the two experiments should map back to the same assay definition. The fact that they did the first experiment in 3 replicates and the second experiment in 1 replicate should also be captured at the experiment definition time.

There are probably some holes in this proposal so please feel free to point them out and suggest improvements. My main concern, though, is eliminating the complexity and potential confusion of storing many potential result hierarchies at the assay definition level.

-Steve

Sent from my iPhone

On Nov 14, 2012, at 10:16 PM, Simon notifications@github.com wrote:

I agree with Noel's concerns about the "intrinsic hierarchy" being expressed in the ontology (sorry, I use dictionary and ontology interchangeably and know I shouldn't, but never know which term to use when..)

I worry that it may not be practical to lay out all the 'derived from' relationships in the ontology. I'm afraid we'll get a horrendous mish-mash of nearly everything connected to nearly everything else. But until we try it (Noel's "we need to see some examples...") we won't know if it's good enough. The data structure is already in place to support hierarchies in the dictionary, the assay definition or the experiment; take your pick.

Let's try some and see how it fairs. Unfortunately we won't be able to do this effectively until we start in on the Measures user stories for the assay definition.

I can work with Mark to start getting his mappings converted into Measures and Assay Contexts and that will show some 'derived from' hierarchy. This can be extracted for use in the dictionary. As we do the UI for this we can add the relationships for the "intrinsic hierarchy" bit by bit and watch how useful and/or unmanageable it gets.

We can also add parentage (derived from) to the existing Measures in the CAP DB. We've got about 900 measures listed so far for all the assays.

— Reply to this email directly or view it on GitHub.

schatwin commented 11 years ago
  1. If 'defining' means "used to determine the uniqueness of an assay" then none of the result types are defining
  2. in the definition for the Vanderbilt assay, the result types are 'fold shift', 'fold max', 'EC50'. Whether it's for glutamate or glutamate+compound is specified as an assay context choice and captured as a result context. It does not affect the result type (this gets into the Readout discussion earlier), merely provides context for it.
  3. The assay definition does nothing to specify the number of replicates, that is captured (not specified, but captured) during result deposition.

Yes, I think you're working along the lines that the design is headed down.

dllahr commented 11 years ago

I've updated the issue summary to include the last summary since I think we are all in general agreement about it

We've decided it is too risky to put the derived from / intrinsic result type hierarchy into the ontology for year 1, so instead we are going to ask the users if they want to specify them in the assay definition to use a template when specifying the measure hierarchy for their experiment.

On Thu, Nov 15, 2012 at 9:05 AM, Simon notifications@github.com wrote:

1.

If 'defining' means "used to determine the uniqueness of an assay" then none of the result types are defining 2.

in the definition for the Vanderbilt assay, the result types are 'fold shift', 'fold max', 'EC50'. Whether it's for glutamate or glutamate+compound is specified as an assay context choice and captured\ as a result context. It does not affect the result type (this gets into the Readout discussion earlier), merely provides context for it. 3.

The assay definition does nothing to specify the number of replicates, that is captured (not specified, but captured) during result deposition.

Yes, I think you're working along the lines that the design is headed down.

— Reply to this email directly or view it on GitHubhttps://github.com/broadinstitute/BARD/issues/4#issuecomment-10409359.

617 714 7868 dlahr@broadinstitute.org