Issues for Gene Expression Revision Task Force

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 5486: transformed DTD should keep dimensions in content list of the BioAssayData
Issue 5487: order attribute be be added for BioDataCube in model (and, hence, the DTD)
Issue 5488: dimension elements be transformed to be optional
Issue 5489: Changing name of Association from "featureShape" to "FeatureShape"
Issue 5490: Change in the DesignElement package
Issue 5491: Parent association from Organization to itself is marked
Issue 5528: abstract base classes should be removed from ref entity declarations in DTD
Issue 5529: Change owner association from Security to Contact from 1..1 to 0..n
Issue 5530: Recommend that FeatureLocation derive from Extendable
Issue 5531: Attribute to be added to Description called URI of type string and optional
Issue 5532: Recommend adding StandardQuantitationType, 'Failed' of type boolean
Issue 5533: Recommend changing cardinality of BioSource:sourceContacts
Issue 5534: Recommend adding optional association from Compound to DatabaseEntry
Issue 5535: Make association from DerivedBioAssay to BioAssayMap navigable both ways
Issue 5550: Allowing a person to belong to only one organization is too restrictive.
Issue 5551: QuantitationType issue
Issue 5552: association from FeatureExtraction to QuantitationTypeMapping needed
Issue 5553: It should be possible to assign default values to parameters
Issue 5554: Need a way to model features that are associated with a BioMaterial
Issue 5555: ExperimentFactor needs an OntologyEntry association
Issue 5556: Specifying a FactorValue needs to be more flexible
Issue 5557: Instances of OntologyEntries need a way to be further qualified
Issue 5558: Database role to be associated with person/organization
Issue 5559: Attribute to be added to describe its type
Issue 5560: For interoperability, need a rule for formatting numbers
Issue 5561: group BioSequences that share the same type, PolymerType, and Species infor
Issue 5927: Clarify and expand the documentation for the MAGE-OM model
Issue 5928: association ExperimentDesign
Issue 5929: Features should be able to know what their Reporter is
Issue 5930: rule in the ExperimentDesign package
Issue 5931: BibliographicReference
Issue 5932: MerckIndex association between Compound and OntologyEntry
Issue 5933: Type association between BioSample and OntologyEntry

Issue 5486: transformed DTD should keep dimensions in content list of the BioAssayData (gene-expression-ftf)

Recommend that the transformed DTD should keep dimensions in the content
list of the
BioAssayData element instead of moving them to the BioDataCube and
BioDataTuples 
content lists.  This simplifies considerable the difference between the PIM
and XML-DTD PSM.


Requires modification of the following files:
MAGE-ML.dtd
(by modifying the generating code:
generate_dtd\TransformBioAssayData.java)
Section 4.1.4, Transforming BioDataValues of the submission

The transformed DTD should keep dimensions in the content list of the BioAssayData element instead of moving them to the BioDataCube and BioDataTuples content lists. This simplifies considerable the difference between the PIM and XML-DTD PSM.

Recommend that, in additional to MAGE Issue 11, an order attribute be added
for 
BioDataCube in the model (and, hence, the DTD).  This will specify the order
of 
the dimensions in the accompanying data specified by either the DataInternal
or
DataExternal element.  In addition, the rule specifying "the first dimension
matches 
order of BioAssayDimension, second, the DesignElementDimension and the
third, the 
QuantitationDimension" can be removed.
Attribute to add: BioDataCube.order
type: enum {BDQ | BQD | DBQ | DQB | QBD | QDB}
default: 'BDQ'


The following will be effected by this change:
The model and MAGE.xmi file.
The DTD
Section 3.1.12, "BioAssayData" of the submission


(MAGE Issue 25)

This will specify the order of the dimensions in the accompanying data specified by either the DataInternal or DataExternal element. In addition, the rule specifying "the first dimension matches order of BioAssayDimension, second, the DesignElementDimension and the third, the QuantitationDimension" can be removed

Recommend that, in additional to MAGE Issue 11, the dimension elements be
transformed
to be optional, since the transformation of BioDataTuples makes specifying
the 
dimensions redundant.


The following will be effected by this change:
The DTD
(by modifying the generating code:
generate_dtd\TransformBioAssayData.java,
generate_classes\CreateFile.java)
Section 4.1.4, "Transforming BioDataValues" of the submission

In additional to Issue #5486, the dimension elements be transformed to be optional, since the transformation of BioDataTuples makes specifying the dimensions redundant.

Recommend changing name of Association from "featureShape" to "FeatureShape"
to be consistent 
with naming convention of initial capitals for Association names.


Only effects the Model and the generated MAGE.xmi file:
MAGE-OM::ArrayDesign::featureShape{3B72C550029B}    [Association]
to
MAGE-OM::ArrayDesign::FeatureShape{3B72C550029B}    [Association]

Change name of Association from "featureShape" to "FeatureShape"

to be consistent with naming convention of initial capitals for Association 

names.

Recommend to change, in the DesignElement package, the cardinality of the
Position end 
of the DistanceUnit association between Position and DistanceUnit from 0..n
to 1..1 since 
0..n and COMPOSITE are inconsistent with each other for an end role.
(that is, since the DistanceUnit is a composite aggregation it must belong
to one and 
only one Position)


Only effects the Model and the generated MAGE.xmi file:
<Foundation.Data_Types.MultiplicityRange.lower>0</Foundation.Data_Types.Mult
iplicityRange.lower>
<Foundation.Data_Types.MultiplicityRange.upper>-1</Foundation.Data_Types.Mul
tiplicityRange.upper>
to
<Foundation.Data_Types.MultiplicityRange.lower>1</Foundation.Data_Types.Mult
iplicityRange.lower>
<Foundation.Data_Types.MultiplicityRange.upper>1</Foundation.Data_Types.Mult
iplicityRange.upper>

Recommend to change, in the DesignElement package, the cardinality of the Position end of the DistanceUnit association between Position and DistanceUnit from 0..n to 1..1 since 0..n and COMPOSITE are inconsistent with each other for an end role. (that is, since the DistanceUnit is a composite aggregation it must belong to one and only one Position)

The Parent association from Organization to itself is wrongly marked as
composite
on the unnamed end.  Recommend, in AuditAndSecurity Package, that the Parent
Association be 
modified by changing the unnamed end (representing child organization) to be
a non-composite 
aggregation and to change its cardinality from unknown to 0..n.  Otherwise,
because of the 
constraint in the dtd, the Parent is owned by the Child and can, wrongly,
only belong to one 
Child.


Requires modification of the following files:
MAGE-ML.dtd
The Model and the generated MAGE.xmi file
<Foundation.Core.AssociationEnd.aggregation xmi.value = "composite"/>
to
<Foundation.Core.AssociationEnd.aggregation xmi.value = "none"/>

The Parent association from Organization to itself is wrongly marked as composite on the unnamed end. Recommend, in AuditAndSecurity Package, that the Parent Association be modified by changing the unnamed end (representing child organization) to be a non-composite aggregation and to change its cardinality from unknown to 0..n. Otherwise, because of the constraint in the dtd, the Parent is owned by the Child and can, wrongly, only belong to one Child.

The DTD currently is generated with the rule that the *_ref entity 
includes abstract class refs.  Since these can't be instantiated, 
implementations break when trying to figure out which class
to map to.  This is because the identifier concept allows using
the identifier to be an alternative key in the case that the 
identifier isn't immediately resolvable.  But without knowing the
actually base class, this won't work.  This is a particular
problem for use in disconnected inhouse high through-put pipelines.


Recommend that the abstract base classes be removed from the ref
entity declarations in the DTD.


Resolution of the issue would change:
MAGE-ML.dtd
(through a change to WriteDTDClassElement)
Section 4.1.2, "Mapping from MAGE-OM to MAGE-ML"

This fixes the problem that, since they can't be instantiated, if the concrete subclass isn't known yet, a placeholder can't be created to map to.

Recommend that the owner association from Security to Contact be 
changed from 1..1 to be 0..n.  It was brought up that there may be many
contacts with permission to change Security and, separately, that
there may be no ownership concept.


Resolution of the issue would change:
MAGE-OM and the generated MAGE.xmi
MAGE-ML.dtd
Section 3.1.3, "Description" of the documentation

This will allow both no owner and shared ownership

Recommend that FeatureLocation derive from Extendable.  It was an 
oversight that this was not done in the first palce


Resolution of the issue would change:
MAGE-OM and the generated MAGE.xmi
MAGE-ML.dtd
Section 3.1.7, "DesignElement" of the documentation

It was an oversight that this was not done in the first place

Recommend that an atribute be added to Description called URI of
type string and optional.  This will allow a description to reference 
an external MIME type


Resolution of the issue would change:
MAGE-OM and the generated MAGE.xmi
MAGE-ML.dtd
Section 3.1.3, "Description" of the documentation

This will allow a description to reference an external MIME type

Recommend adding StandardQuantitationType, 'Failed' of type boolean, 
to represent overall failure


Resolution of the issue would change:
MAGE-OM and the generated MAGE.xmi
MAGE-ML.dtd
3.1.17, "QuantitationType" of the documentation

This will allow a standard way to mark a feature has having failed to be extracted successfully by feature extraction

Recommend changing cardinality of BioSource:sourceContacts from
0..1 to 0..N to allow multiple contacts for a BioSource.


Resolution of the issue would change:
MAGE-OM and the generated MAGE.xmi
MAGE-ML.dtd
3.1.10, "BioMaterial" of the documentation

Changing cardinality of BioSource:sourceContacts from 0..1 to 0..N will allow multiple contacts for a BioSource

Recommend adding optional association from Compound to DatabaseEntry 
called 'ExternalLIMS' to reference an external LIMS system entry.


Resolution of the issue would change:
MAGE-OM and the generated MAGE.xmi
MAGE-ML.dtd
3.1.10, "BioMaterial" of the documentation

Adding optional association from Compound to DatabaseEntry called 'ExternalLIMS' will allow referencing an external LIMS system entry.

Recommend making association from DerivedBioAssay to BioAssayMap 
navigable both ways.  It currently is only navigable from BioAssayMap
to DerivedBioAssay.  This will make it easier to find what BioAssays
were used to producea BioAssay.  The association end should be named
derivedBioAssayMap


Resolution of the issue would change:
MAGE-OM and the generated MAGE.xmi
MAGE-ML.dtd
3.1.12, "BioAssayData" of the documentation

This will make it easier to find what BioAssays were used to produce a BioAssay. The association end should be named derivedBioAssayMap

Allowing a person to belong to only one organization is too restrictive.


Request from John Yost, NCI, that the affiliation association between 
Person and Organization be changed so that the Organization end is 
changed from 0..1 to 0..n.  

Request from John Yost, NCI, that the affiliation association between Person and Organization be changed so that the Organization end is changed from 0..1 to 0..n.

Not clear if any benefit in the scope of the specification is gained by this. Version two may will reconsider this, there have also been many other small, but important issues (database roles, security groups, etc.) raised about this package that make the delay worthwhile to give a thorough redoing consideration.

Allowing a QuantitationType to know how it was derived 
would make navigation easier.


Request from Ugis Sarkans, EBI, that the Target association be 
navigable from QuantitationType to QuantitationTypeMap.  The 
association end would be named quantitationTypeMaps.


(MAGE ISSUE 108)

Request from Ugis Sarkans, EBI, that the Target association be navigable from QuantitationType to QuantitationTypeMap. The association end would be named quantitationTypeMaps.

This also provides a workaround for Issue #5552, in that a Ratio, for instance, can reference a QuantitationTypeMap whose protocol describes how it was derived and the Map also references the QuantitationTypes used to derive the Ratio.

Currently, if software, for instance, calculates a Ratio 
from two channel images, there is no direct way to record how it was 
derived, other than burying it in the protocol.    


Request from Michael Miller, Rosetta Biosoftware, that there be an
association from FeatureExtraction to QuantitationTypeMapping.  
The association would have the same names and characteristics as 
the Transformation to QuantitationTypeMapping Mapping association 
with a constraint of "rank: 3" on the QuantitationTypeMapping end.  
This association would allow a natural way to describe additional 
work of FeatureExtraction beyond reading the image.


(MAGE ISSUE 109)

Currently, if software, for instance, calculates a Ratio from two channel images, there is no direct way to record how it was derived, other than burying it in the protocol.

It should be possible to assign default values to parameters


Request from Hilmar Lapp, GNF, that default values can be associated with
a Parameterizable's Parameters.  This could be done by replacing the
current Unit association to an association called "DefaultValue" to
Measurement.  The Parameterizable end would aggregate the Measurement
end and have a cardinality of 1.  The Measurement end would have a 
cardinality of 0..1 and be named "defaultValue".


(MAGE ISSUE 113)

Request from Hilmar Lapp, GNF, that default values can be associated with a Parameterizable's Parameters. This could be done by replacing the current Unit association to an association called "DefaultValue" to Measurement. The Parameterizable end would aggregate the Measurement end and have a cardinality of 1. The Measurement end would have a cardinality of 0..1 and be named "defaultValue

Need a way to model features that are associated with a BioMaterial
rather than a BioSequence


Request from several sources that there be a way to specify that
a Feature is associated with something other than Biosequences, 
such as solutions, Cy5, etc., when that decision is made at the
ArrayDesign stage.  


(MAGE ISSUE 114)

Request from several sources that there be a way to specify that a Feature is associated with something other than Biosequences, such as solutions, Cy5, etc., when that decision is made at the ArrayDesign stage.

ExperimentFactor needs an OntologyEntry association for describing
additional information.


Request, made at MGED IV, that ExperimentFactor have an association 
to OntologyEntry to capture things like concentration of Tamoxafin 
with a CASRegistry #.


(MAGE ISSUE 116)

Request, made at MGED IV, that ExperimentFactor have an association to OntologyEntry to capture things like concentration of Tamoxafin with a CASRegistry #.

Request, made at MGED IV, to modify the model:
* add association from FactorValue to OntologyEntry named "Value"
    FactorValue end:
    - aggregates OntologyEntry end
    - cardinality: 1..1
    OntologyEntry end:
    - name: value
    - cardinality: 0..1
    - navigable
* make cardinality of association from FactorValue to Measurement
  become 0..1
* add a rule that FactorValue has *either* a Measurement *or* a
OntologyEntry
  (exclusive)
  

Request, made at MGED IV, to modify the model. Not all FactorValues are strict measurements. By adding the 

OntologyEntry association named Value, it will allow more robust specification of the value for the experiment factor. A rule should be added to the model that either Value or Measurement can be used, but not both.

Some ontologies, such as GeneOntology, don't have this concept but others,
such as MGED's, do.
  
Request from a number of sources to modify the model:


* add a new class named "Slot" to the Description package with the
following:
  - attribute: "name" of type String, required
  - parent base class: Extendable
  - association to Measurement named "Measurement"
    Slot end:
    - aggregates Measurement end
    - cardinality: 1..1
    Measurement End:
    - name: "measurement"
    - cardinality: 0..1
    - navigable
  - association to OntologyEntry named "SlotValue"
    Slot end:
    - aggregates OntologyEntry end
    - cardinality: 1..1
    OntologyEntry end:
    - name: slotValue
    - cardinality: 0..1
    - navigable
  - add rule that Slot has either measurement or ontologyEntry, exclusive
* OntologyEntry has association to Slot named "Slots"
    OntologyEntry end:
    - aggregates Slot end
    - cardinality: 1..1
    Slot end:
    - name: slots
    - cardinality: 0..N
    - navigable
    
An simpler alternative would be an association from OntologyEntry to 
itself named "Associations":
    1st OntologyEntry end:
    - aggregates 2nd OntologyEntry end
    - cardinality: 1..1
    2nd OntologyEntry end:
    - name: associations
    - cardinality: 0..N
    - navigable
  
(MAGE ISSUE 7) 

Some ontologies, such as GeneOntology, don't have this concept but others, such as MGED's, do. There ws a lot of discussion on this issue and two proposed modifications. The alternative presented for a vote was the simpler of the two, which was to add a nested association to itself.

Request from Catherine Ball, from Stanford University, that a database 
role be associated with person/organization.  These roles will describe 
the types of privileges a person has with the data, not the type of 
occupation the person has.  (see also MAGE ISSUE 103)


(MAGE ISSUE 121)

Request from Catherine Ball, from Stanford University, that a database role be associated with person/organization. These roles will describe the types of privileges a person has with the data, not the type of occupation the person has.

The proposed change would have required an extensive reworking of the AuditAndSecurity package
An alternative proposed change that made the Security and SecurityGroup association more general. The SecurityGroup instance could then provide more information through its association to Description.

Request from Hilmar Lapp, GNF, and Michael Miller, Rosetta Biosoftware,
that an attribute be added to Parameter to describe its type:
  - name: type
  - required: true
  - enumeration: {IN, INOUT, OUT}
  - default: IN
  
This would allow Protocol/ProtocolApplication to allow return values.

Request from Hilmar Lapp, GNF, and Michael Miller, Rosetta Biosoftware, that an attribute be added to Parameter to describe its type:

- name: type

- required: true

- enumeration: {IN, INOUT, OUT}

- default: IN

This would allow Protocol/ProtocolApplication to allow return values

Request from Michael Miller, Rosetta Biosoftware, for clarification
on how numbers should be formatted:
* integer values are just digits
* floating point numbers use a '.' (period), with an optional leading
  zero and an optional leading +/- sign:
  * -0.912
* scientific notation: optional leading zero, optional leading +/-
  sign on the exponent and mantissa:
  * -2.34E-12

Request from Michael Miller, Rosetta Biosoftware, for clarification on how numbers should be formatted. Jason Stewart, Open Informatics, suggested the following:

* integer values are just digits

* floating point numbers use a '.' (period), with an optional leading

zero and an optional leading +/- sign: -0.912

* scientific notation: optional leading zero, optional leading +/-

sign on the exponent and mantissa: -2.34E-12

It would be useful to have a way to group BioSequences that share the same
Type, PolymerType, and Species information.


Request from Steve Chervitz, Affymetrix, that the model be modified in
some way to make it possible to group together sequences that shared these
common characteristics.

Request from Steve Chervitz, Affymetrix, that the model be modified in some way to make it possible to group together sequences that shared these common characteristics. That would produce much smaller files that contained BioSquence information

Discussion:
A draft was created by Cathy Ball and her group that is included 
as a separate document


Issues:
The changes were done on a previous version of the standard and 
need to be merged to the available standard


The changes need to be backed merged into the UML model to keep
the documentation in synch in the generated DTD and code.

Cathy Ball and her group at Stanford revised and expanded the documentation.

Issues:

The changes were done on a previous version of the standard and need to be merged to the available standard.

The changes need to be backed merged into the UML model to keep the documentation in synch in the generated DTD and code.

The association ExperimentDesign should be 
Experiment(1..1)-->ExperimentDesign(1..n)


instead of


Experiment(1..1)-->ExperimentDesign(1..1)


and the association name and end role should become 'ExperimentDesigns' 
and 'experimentDesigns'


Discussion:
Raised by Angel Pizarro 9/9/02 and requested by the Ontology Group

Raised by Angel Pizarro 9/9/02 and requested by the Ontology Group

Change to the association ExperimentDesign as follows:

Experiment(1..1)-->ExperimentDesign(1..n)

instead of

Experiment(1..1)-->ExperimentDesign(1..1)

and the association name and end role should become 'ExperimentDesigns' and 'experimentDesigns'

Features should be able to know what their Reporter is.  The model 
currently has no way to navigate from a Feature to its Reporter


Discussion:
Raise by Michael Dondrup 10/2/02


"Given a particular Feature (eg. by selecting a spot on a image of an
array),  try to retrieve data for the BioSequence via its Reporter. I
would suggest a direct association from Feature to Reporter. Or is this
only adding redundancy to the model?'


Reply from Paul Spellman 10/4/02


"there is a very good reason for this association not to exist.  
Features are immutable and confined to a single array, Reporters are 
flexible and can be present on multiple arrays.  Requiring Features to 
know which Reporters they are in could in some cases be a logistical 
nightmare.


This is best solved using a database query rather than the model."

Raise by Michael Dondrup 10/2/02:  Features should be able to know what their Reporter is.  The model currently has no way to navigate from a Feature to its Reporter.

Applications are free to add (or not) explicit relationships outside the model.  The model, as is, provides sufficient support for queries between Features and Reporters

The rule in the ExperimentDesign package that only allows a single
FactorValue per TopLevelBioAssay hinders proper description of
multi-channel experiments and should be dropped


Discussion:
Raised by Angel Pizarro 3/4/03 


"During the MGED Ontology workshop, we came across a situation that does
not allow you to describe certain ExperimentDesigns. For instance in a
loop design, you compare conditions A,B,C as follows:
A -> B
B -> C


If A,B & C represent different values of the same ExperimentalFactor, how
do you encode that a single top-level BioAssay is A -> B? Remember that
there is a Rule in the ExperimentDesign package that states that each
TopLevelBioAssay can only have a single FactorValue per
ExperimentalFactor."

Raised by Angel Pizarro 3/4/03: The rule in the ExperimentDesign package that only allows a single FactorValue per TopLevelBioAssay hinders proper description of multi-channel experiments and should be dropped

This rule doesn't exist.  It was probably in some previous version but is not in the available specification

BibliographicReference needs to be able to point to multiple 
database entries.  An association will be added between 
BibliographicReference and DatabaseEntry which will be named 'Accessions'
with the end role name of 'accessions' on the DatabaseEntry end.  It will 
be navigable from BibliographicReference to DatabaseEntry and its
aggregation
will be of type composite.  The cardinality of the BibliographicReference 
end will be 1..1 and the cardinality of the DatabaseEntry end will be 0..n

Raised by Helen Parkinson 3/18/03: BibliographicReference needs to be able to point to multiple database entries.

We have come across a problem adding id's for papers to eg Medline and PubMed.  Accession is not an attribute of Bibliographic reference and it's hard to explicitly link to an accession if the uri has already been used for the journal.

Add an optional association from BibliographicReference to OntologyEntry.  The association should be 0..n and named Accession.

The MerckIndex association between Compound and OntologyEntry is too
specific.  The association should become more general and allow more 
than one kind of Index.   The name of the association and end role will
change to 'CompoundIndices' and 'compoundIndices' and the OntologyEntry end
will change its cardinality to 0..n

The MerckIndex association between Compound and OntologyEntry is too specific.  The association should become more general and allow more than one kind of Index.   The name of the association and end role will change to 'CompoundIndices' and 'compoundIndices' and the OntologyEntry end will change its cardinality to 0..n

Issue was raised for the FTF on the mailing list but was overlooked.

The Type association between BioSample and OntologyEntry needs to be
optional.
The cardinality of the OntologyEntry end will change from 1..1 to 0..1.

Requested by the Ontology group 1/15/03: The Type association between BioSample and OntologyEntry needs to be optional.  The cardinality of the OntologyEntry end will change from 1..1 to 0..1.