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)

see below

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)

no action taken

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)

see below

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.

No action taken

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

see below

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

see below

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)

see below

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)

see below

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

reject the change but then see below

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

see below

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

see below

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.

No Action Taken.

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)

reject the change

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)

see below

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)

no action taken

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.

No Data Available

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

Reject the change.

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

see below

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

see below

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

Reject the Change

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

see below

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.

see below

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.

no action taken

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

see below

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

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)

see below

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

see below

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

see below

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

see below

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

see below

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"

see below

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"/>

see below

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>

see below

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

[Association]

see below