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

Jira Issues

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

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.