MAGE Software

Member

Organization

Michael Miller, chair

Rosetta Biosoftware Business Unit

Steve Chervitz

Affymetrix, Inc.

Charles Troup

Agilent Technologies

Richard Scott

De Novo Pharmaceuticals

Ugis Sarkans

European Bioinformatics Institute

Karl Konnerth

Incyte Genomics, Inc.

Tony Parsons

Pfizer

Disposition Value

Number of Occurences

Meaning of Disposition

Accepted

21

Change made as requested

Unresolved

5

FTF couldn't agree on a resolution

Rejected

0

FTF agreed NOT to do what was requested, or anything like it

Issue 5486: transformed DTD should keep dimensions in content list

of the BioAssayData (archive)

Source

Rosetta Biosoftware (Mr. Michael D Miller, michael_miller@rosettabio.com)

Summary

Transformed DTD should keep dimensions in content list of the BioAssayData

Discussion

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.

Resolution

Changes to the Specification:

Section 3.1.4, Transforming BioDataValues of the submission

Changes to section 3.1.4.4:

Currently:

"The code to produce this transformation takes the list of CreateFiles generated by the parsing of the XML.

1. It searches for the representations of the original classes involved in the transformation, BioAssayData, BioDataCube, BioDataTuples, and BioAssayDatum. BioAssayDatum is removed from the CreateFile list.

2. The association to the three dimension classes and the cube are removed from BioAssayData.

3. The CreateFiles to represent the DataInternal and DataExternal elements are created and their attributes are added. DataInternal also has #PCDATA added for its content list for the white-space delimited data.

4. BioDataCube has the Dimension associations 1..1 added with a rank of -1 specified. The -1 will be interpreted by the generating code to produce all the possible orderings of the Dimensions as the first part of the content list of the BioDataCube after the base class content. Associations 1..1 to DataInternal and DataExternal are both added with a rank of 2 which will cause the generating code to add them as a Choice group to the content list after the Dimensions.

5. The tag-delimited form of the data representation, BioAssayTuples, now is transformed. Associations 0..1 to the three Dimensions are added to BioAssayTuples, in order of ranking, BioAssayDimension, the DesignElementDimension and the QuantitationTypeDimension. The association to BioAssayDatum is removed.

6. The CreateFile to represent the Datum element is created with a value attribute.

7. The CreateFile to represent the QuantitationTypeTuple is created with an association 1..1 to Datum and the association 1..1 to QuantitationType from the BioAssayDatum.

8. The CreateFile to represent the DesignElementTuple is created with an association 1..n to QuantitationTypeTuple and the association to DesignElement from the BioAssayDatum.

9. The CreateFile to represent the BioAssayTuple is created with an association 1..n to DesignElementTuple and the association 1..1 to BioAssay from the BioAssayDatum.

10. An association 1..n to BioAssayTuple is added to BioAssayTuples.

11. Lastly, the new CreateFiles are added to the list of CreateFiles."

Becomes:

"The code to produce this transformation takes the list of CreateFiles generated by the parsing of the XML.

1. It searches for the representations of the original classes involved in the transformation, BioAssayData, BioDataCube, BioDataTuples, and BioAssayDatum. BioAssayDatum is removed from the CreateFile list.

2. The CreateFiles to represent the DataInternal and DataExternal elements are created and their attributes are added. DataInternal also has #PCDATA added for its content list for the white-space delimited data.

3. BioDataCube has the associations 1..1 to DataInternal and DataExternal added with a rank of 2 which will cause the generating code to add them as a Choice group to the content list.

4. The tag-delimited form of the data representation, BioAssayTuples, now is transformed. The association to BioAssayDatum is removed.

5. The CreateFile to represent the Datum element is created with a value attribute.

6. The CreateFile to represent the QuantitationTypeTuple is created with an association 1..1 to Datum and the association 1..1 to QuantitationType from the BioAssayDatum.

7. The CreateFile to represent the DesignElementTuple is created with an association 1..n to QuantitationTypeTuple and the association to DesignElement from the BioAssayDatum.

8. The CreateFile to represent the BioAssayTuple is created with an association 1..n to DesignElementTuple and the association 1..1 to BioAssay from the BioAssayDatum.

9. An association 1..n to BioAssayTuple is added to BioAssayTuples.

10. Lastly, the new CreateFiles are added to the list of CreateFiles."

Changes to Section 3.1.4.5:

Currently:

"<!ELEMENT BioDataCube ((%BioDataValues_content;),

((BioAssayDimension_assnref,

((DesignElementDimension_assnref,

QuantitationTypeDimension_assnref) |

(QuantitationTypeDimension_assnref,

DesignElementDimension_assnref))) |

(DesignElementDimension_assnref,

((QuantitationTypeDimension_assnref,

BioAssayDimension_assnref) |

(BioAssayDimension_assnref,

QuantitationTypeDimension_assnref))) |

(QuantitationTypeDimension_assnref,

((BioAssayDimension_assnref,

DesignElementDimension_assnref) |

(DesignElementDimension_assnref,

BioAssayDimension_assnref)))),

(DataInternal_assn | DataExternal_assn)) >

<!ATTLIST BioDataCube %BioDataValues_attrs; >

<!ELEMENT DataExternal_assn (DataExternal) >

<!ELEMENT DataExternal EMPTY >

<!ATTLIST DataExternal dataFormat CDATA "whitespace"

dataFormatInfoURI CDATA #IMPLIED

filenameURI CDATA #REQUIRED >

<!ELEMENT DataInternal_assn (DataInternal) >

<!ELEMENT DataInternal (#PCDATA) >

<!ELEMENT BioDataTuples ((%BioDataValues_content;),

BioAssayDimension_assnref?,

DesignElementDimension_assnref?,

QuantitationTypeDimension_assnref?,

BioAssayTuples_assnlist?) >

<!ATTLIST BioDataTuples %BioDataValues_attrs; >

<!ELEMENT BioAssayTuples_assnlist (BioAssayTuple+) >

<!ELEMENT BioAssayTuple (BioAssay_assnref,

DesignElementTuples_assnlist) >

<!ELEMENT DesignElementTuples_assnlist (DesignElementTuple+)

>

<!ELEMENT DesignElementTuple (DesignElement_assnref,

QuantitationTypeTuples_assnlist) >

<!ELEMENT QuantitationTypeTuples_assnlist (QuantitationTypeTuple+)

>

<!ELEMENT QuantitationTypeTuple (QuantitationType_assnref,

Datum_assn) >

<!ELEMENT Datum_assn (Datum) >

<!ELEMENT Datum EMPTY >

<!ATTLIST Datum value CDATA #REQUIRED >"

Becomes:

"<!ELEMENT BioDataCube ((%BioDataValues_content;),

(DataInternal_assn | DataExternal_assn)) >

<!ATTLIST BioDataCube %BioDataValues_attrs; >

<!ELEMENT DataExternal_assn (DataExternal) >

<!ELEMENT DataExternal EMPTY >

<!ATTLIST DataExternal dataFormat CDATA "whitespace"

dataFormatInfoURI CDATA #IMPLIED

filenameURI CDATA #REQUIRED >

<!ELEMENT DataInternal_assn (DataInternal) >

<!ELEMENT DataInternal (#PCDATA) >

<!ELEMENT BioDataTuples ((%BioDataValues_content;),

BioAssayTuples_assnlist?) >

<!ATTLIST BioDataTuples %BioDataValues_attrs; >

<!ELEMENT BioAssayTuples_assnlist (BioAssayTuple+) >

<!ELEMENT BioAssayTuple (BioAssay_assnref,

DesignElementTuples_assnlist) >

<!ELEMENT DesignElementTuples_assnlist (DesignElementTuple+)

>

<!ELEMENT DesignElementTuple (DesignElement_assnref,

QuantitationTypeTuples_assnlist) >

<!ELEMENT QuantitationTypeTuples_assnlist (QuantitationTypeTuple+)

>

<!ELEMENT QuantitationTypeTuple (QuantitationType_assnref,

Datum_assn) >

<!ELEMENT Datum_assn (Datum) >

<!ELEMENT Datum EMPTY >

<!ATTLIST Datum value CDATA #REQUIRED >"

MAGE-ML.dtd

(by modifying the generating code:

generate_dtd\TransformBioAssayData.java):

Currently:

"<!ENTITY % BioAssayData_content "(%Identifiable_content;),

SummaryStatistics_assnlist?,

BioDataValues_assn?" >"

Becomes:

"<!ENTITY % BioAssayData_content "(%Identifiable_content;),

SummaryStatistics_assnlist?,

BioAssayDimension_assnref,

DesignElementDimension_assnref,

QuantitationTypeDimension_assnref,

BioDataValues_assn?" >"

Currently:

"<!ELEMENT BioDataCube ((%BioDataValues_content;),

((BioAssayDimension_assnref,

((DesignElementDimension_assnref,

QuantitationTypeDimension_assnref) |

(QuantitationTypeDimension_assnref,

DesignElementDimension_assnref))) |

(DesignElementDimension_assnref,

((QuantitationTypeDimension_assnref,

BioAssayDimension_assnref) |

(BioAssayDimension_assnref,

QuantitationTypeDimension_assnref))) |

(QuantitationTypeDimension_assnref,

((BioAssayDimension_assnref,

DesignElementDimension_assnref) |

(DesignElementDimension_assnref,

BioAssayDimension_assnref)))),

(DataInternal_assn | DataExternal_assn)) >"

Becomes:

"<!ELEMENT BioDataCube ((%BioDataValues_content;),

(DataInternal_assn | DataExternal_assn)) >"

Currently:

"<!ELEMENT BioDataTuples ((%BioDataValues_content;),

BioAssayDimension_assnref?,

DesignElementDimension_assnref?,

QuantitationTypeDimension_assnref?,

BioAssayTuples_assnlist?) >"

Becomes:

"<!ELEMENT BioDataTuples ((%BioDataValues_content;),

BioAssayTuples_assnlist?) >"

Issue 5487: Order attribute be be added for BioDataCube in model (and, hence, the DTD) (archive)

Source

Rosetta Biosoftware Business Unit (Mr. Michael D Miller, michael_miller@rosettabio.com)

Summary

Order attribute be be added for BioDataCube in model (and, hence, the DTD)

Discussion

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.

Resolution

Changes to the specification:

Section 2.1.12, "BioAssayData":

Figure 2.13 will be updated

The BioAssayCube documentation will add to its Associations section after the documentation of its cube attribute:

\border\b : Order (default: \iBDQ\i)

enumeration {\iBDQ\i | \iBQD\i | \iDBQ\i | \iDQB\i | \iQBD\i | \iQDB\i}

The order to expect the dimension. The enumeration uses the first letter of the three dimensions to represent the six possible orderings.

(where \b...\b indicates bold and \i...\i indicates italics)

Changes to Section 3.1.4.5.

The ATTLIST declaration for BioDataCube is replaced.

Currently:

"<!ATTLIST BioDataCube %BioDataValues_attrs; >"

Becomes:

"<!ATTLIST BioDataCube %BioDataValues_attrs;

order (BDQ|BQD|

DBQ|

DQB|

QBD|

QDB) "BDQ" >"

The model and MAGE.xmi file is modified to add the order attribute to BioDataCube.

The MAGE-ML.dtd:

Modify the Element and Attlist declarations for BioDataCube

Currently:

" Attributes

Inherites attributes from base class BioDataValues."

Becomes:

" Attributes

Inherites attributes from base class BioDataValues.

order: The order to expect the dimension. The enumeration uses

the first letter of the three dimensions to represent the six

possible orderings."

Currently:

"<!ATTLIST BioDataCube %BioDataValues_attrs; >"

Becomes:

"<!ATTLIST BioDataCube %BioDataValues_attrs;

order (BDQ|

BQD|

DBQ|

DQB|

QBD|

QDB) "BDQ" >"

Issue 5488: Dimension elements be transformed to be optional (archive)

Source

Rosetta Biosoftware Business Unit (Mr. Michael D Miller, michael_miller@rosettabio.com)

Summary

Dimension elements be transformed to be optional

Discussion

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

Resolution

Changes to Section 3.1.4.4 of the specification:

An additional rule is added between the current rules 1 and 2:

"2: The dimension associations of BioAssayData are transformed to have cardinalities 0..1 from 1..1"

The DTD

(by modifying the generating code:

generate_dtd\TransformBioAssayData.java,

generate_classes\CreateFile.java)

Currently:

"<!ENTITY % BioAssayData_content "(%Identifiable_content;),

SummaryStatistics_assnlist?,

BioAssayDimension_assnref,

DesignElementDimension_assnref,

QuantitationTypeDimension_assnref,

BioDataValues_assn?" >"

Becomes:

"<!ENTITY % BioAssayData_content "(%Identifiable_content;),

SummaryStatistics_assnlist?,

BioAssayDimension_assnref?,

DesignElementDimension_assnref?,

QuantitationTypeDimension_assnref?,

BioDataValues_assn?" >"

Issue 5489: Changing name of Association from "featureShape" to "FeatureShape" (archive)

Source

Rosetta Biosoftware Business Unit (Mr. Michael D Miller, michael_miller@rosettabio.com)

Summary

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

Discussion

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

to be consistent with naming convention of initial capitals for Association

names.

Resolution

Changes to specification: Figure 2-7 is updated

Changes the Model and the generated MAGE.xmi file by renaming the association.

Issue 5490: Change in the DesignElement package (archive)

Source

Rosetta Biosoftware Business Unit (Mr. Michael D Miller, michael_miller@rosettabio.com)

Summary

Change in the DesignElement package

Discussion

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)

Resolution

Changes to specification:

Figure 2-7 is updated

Changes effects the Model and the generated MAGE.xmi file by modifying the DistanceUnit association..

Issue 5491: Parent association from Organization to itself is marked incorrectly (archive)

Source

Rosetta Biosoftware Business Unit (Mr. Michael D Miller, michael_miller@rosettabio.com)

Summary

Parent association from Organization to itself is marked incorrectly

Discussion

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.

Resolution

Changes to the specification:

Update Figure 2-3

Changes the Model and the generated MAGE.xmi file to update the Parent Association.

Changes to MAGE-ML.dtd:

Currently:

"<!ELEMENT Parent_assn (Organization) >"

Becomes:

"<!ELEMENT Parent_assnref (Organization_ref) >"

Currently:

"<!ELEMENT Organization ((%Contact_content;),

Parent_assn?) >"

Becomes:

"<!ELEMENT Organization ((%Contact_content;),

Parent_assnref?) >"

Issue 5528: Abstract base classes should be removed from ref entity declarations in DTD (archive)

Source

Rosetta Biosoftware Business Unit (Mr. Michael D Miller, michael_miller@rosettabio.com)

Summary

Abstract base classes should be removed from ref entity declarations in DTD

Discussion

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.

Resolution

Changes to the specification:

Section 3.1.2.4, "Entity Declarations"

Currently:

1st paragraph, 2nd sentence

"One, for those roles this base class is the end class, the *_class or *_ref (where * is replaced by the base class name) entity is used and is a choice group of all the instantiable classes of this base class for *_class and all classes for the *_ref."

Becomes:

"One, for those roles this base class is the end class, the *_class or *_ref (where * is replaced by the base class name) entity is used and is a choice group of all the instantiable classes of this base class for *_class and for the *_ref."

Entity ref example

Currently:

<!ENTITY % BioAssay_ref "BioAssay_ref |

PhysicalBioAssay_ref |

DerivedBioAssay_ref |

MeasuredBioAssay_ref" >

Becomes:

<!ENTITY % BioAssay_ref "PhysicalBioAssay_ref |

DerivedBioAssay_ref |

MeasuredBioAssay_ref" >

MAGE-ML.dtd

(through a change to WriteDTDClassElement)

Currently:

"<!ENTITY % QuantitationType_ref "QuantitationType_ref |

SpecializedQuantitationType_ref |"

Becomes:

"<!ENTITY % QuantitationType_ref "SpecializedQuantitationType_ref |"

Currently:

"<!ENTITY % ConfidenceIndicator_ref "ConfidenceIndicator_ref |

Error_ref |"

Becomes:

"<!ENTITY % ConfidenceIndicator_ref "Error_ref |"

Currently:

"<!ENTITY % Contact_ref "Contact_ref |

Person_ref |"

Becomes:

"<!ENTITY % Contact_ref "Person_ref |"

Currently:

"<!ENTITY % BioMaterial_ref "BioMaterial_ref |

BioSource_ref |"

Becomes:

"<!ENTITY % BioMaterial_ref "BioSource_ref |"

Currently:

"<!ENTITY % BioAssay_ref "BioAssay_ref |

PhysicalBioAssay_ref |"

Becomes:

"<!ENTITY % BioAssay_ref "PhysicalBioAssay_ref |"

Currently:

"<!ENTITY % BioAssayData_ref "BioAssayData_ref |

DerivedBioAssayData_ref |"

Becomes:

"<!ENTITY % BioAssayData_ref "DerivedBioAssayData_ref |"

Currently:

"<!ENTITY % DesignElementDimension_ref "DesignElementDimension_ref |

CompositeSequenceDimension_ref |"

Becomes:

"<!ENTITY % DesignElementDimension_ref "CompositeSequenceDimension_ref |"

Currently:

"<!ENTITY % DesignElementMap_ref "DesignElementMap_ref |

CompositeCompositeMap_ref |"

Becomes:

"<!ENTITY % DesignElementMap_ref "CompositeCompositeMap_ref |"

Currently:

"<!ENTITY % DesignElement_ref "DesignElement_ref |

Reporter_ref |"

Becomes:

"<!ENTITY % DesignElement_ref "Reporter_ref |"

 Issue 5529: Change owner association from Security to Contact from 1..1 to 0..n (archive)

Source

Rosetta Biosoftware Business Unit (Mr. Michael D Miller, michael_miller@rosettabio.com)

Summary

Change Owner association from Security to Contact from 1..1 to 0..n

Discussion

This will allow both no owner and shared ownership.

Resolution

 Section 2.1.2, "AuditAndSecurity" of the documentation

Figure 2-3 will be updated

In the documentation for Security the first Association is changed.

Currently:

"\bowner\b : Contact (1..1)"

Becomes:

"\bowner\b : Contact (0..n)"

(where \b...\b indicates bold)

MAGE-OM and the generated MAGE.xmi are updated for the Owner association

MAGE-ML.dtd

Currently:

"<!ELEMENT Owner_assnref ((%Contact_ref;)) >"

Becomes:

"<!ELEMENT Owner_assnreflist ((%Contact_ref;)+) >"

Currently:

"<!ELEMENT Security ((%Identifiable_content;),

Owner_assnref,

ReadGroups_assnreflist?,

WriteGroups_assnreflist?) >"

Becomes:

"<!ELEMENT Security ((%Identifiable_content;),

Owner_assnreflist?,

ReadGroups_assnreflist?,

WriteGroups_assnreflist?) >"

Issue 5530: Recommend that FeatureLocation derive from Extendable (archive)

Source

Rosetta Biosoftware Business Unit (Mr. Michael D Miller, michael_miller@rosettabio.com)

Summary

Recommend that FeatureLocation derive from Extendable

Discussion

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

Resolution

Section 2.1.7, "DesignElement" of the documentation

For the documentation of FeatureLocation.

Currently:

"FeatureLocation

Specifies where a feature is located relative to a grid."

Becomes:

"FeatureLocation

Specifies where a feature is located relative to a grid.

Derived from Extendable"

MAGE-OM and the generated MAGE.xmi are updated to derive FeatureLocation from Extendable.

 MAGE-ML.dtd

Currently:

"<!--

Element and Attlist declarations for FeatureLocation

Specifies where a feature is located relative to a grid.

Attributes

row: row position in the Zone

column: column position in the Zone.

-->

<!ELEMENT FeatureLocation_assn (FeatureLocation) >

<!ELEMENT FeatureLocation EMPTY >

<!ATTLIST FeatureLocation row CDATA #REQUIRED

column CDATA #REQUIRED >"

Becomes:

"<!--

Element and Attlist declarations for FeatureLocation

Specifies where a feature is located relative to a grid.

Associations

Inherites associations from base class Extendable.

Attributes

Inherites attributes from base class Extendable.

row: row position in the Zone

column: column position in the Zone.

-->

<!ELEMENT FeatureLocation_assn (FeatureLocation) >

<!ELEMENT FeatureLocation ((%Extendable_content;)) >

<!ATTLIST FeatureLocation %Extendable_attrs;

row CDATA #REQUIRED

column CDATA #REQUIRED >"

Issue 5531: Attribute to be added to Description called URI of type string and optional (archive)

Source

Rosetta Biosoftware Business Unit (Mr. Michael D Miller, michael_miller@rosettabio.com)

Summary

Attribute to be added to Description called URI of type string and optional

Discussion

This will allow a description to reference an external MIME type

Resolution

Section 2.1.3, "Description" of the documentation

Figure 2-4 will be updated (see Description.png)

The documentation for Description will add the URI attribute

description.

Currently:

" Attributes:

\btext\b : String (optional)

The description."

Becomes:

" Attributes:

\btext\b : String (optional)

The description.

\bURI\b : String (optional)

A reference to the location and type of an outside resource."

(where \b...\b indicates bold)

MAGE-OM and the generated MAGE.xmi are updated to add the URI attribute to Description

 MAGE-ML.dtd

Comment for Description is modified

Currently:

" Attributes

Inherites attributes from base class Describable.

text: The description."

Becomes:

" Attributes

Inherites attributes from base class Describable.

text: The description.

URI: A reference to the location and type of an outside

resource."

Declaration for the attribute list of Description is modified

Currently:

"<!ATTLIST Description %Describable_attrs;

text CDATA #IMPLIED >"

Becomes:

"<!ATTLIST Description %Describable_attrs;

text CDATA #IMPLIED

URI CDATA #IMPLIED >"

Issue 5532: Recommend adding StandardQuantitationType, 'Failed' of type boolean (archive)

Source

Rosetta Biosoftware Business Unit (Mr. Michael D Miller, michael_miller@rosettabio.com)

Summary

Recommend adding StandardQuantitationType, 'Failed' of type boolean

Discussion

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

Resolution

2.1.17, "QuantitationType" of the documentation

Figure 2-20 will be updated (see QuantitationType.png)

Add documentation section for Failed after documentation for Ratio

Currently: does not exist

Becomes:

" Failed

Values associated with this QuantitationType indicate a failure of some kind for a particular DesignElement for a BioAssay. Of type boolean.

Derived from StandardQuantitationType"

MAGE-OM and the generated MAGE.xmi are updated to add the new class named Failed

 MAGE-ML.dtd

Currently:

"<!ENTITY % QuantitationType_classes "SpecializedQuantitationType |

DerivedSignal |

MeasuredSignal |

Error |

PValue |

ExpectedValue |

Ratio |

PresentAbsent" >

<!ENTITY % QuantitationType_ref "QuantitationType_ref |

SpecializedQuantitationType_ref |

DerivedSignal_ref |

MeasuredSignal_ref |

Error_ref |

PValue_ref |

ExpectedValue_ref |

Ratio_ref |

PresentAbsent_ref" >"

Becomes:

"<!ENTITY % QuantitationType_classes "SpecializedQuantitationType |

DerivedSignal |

MeasuredSignal |

Error |

PValue |

ExpectedValue |

Ratio |

PresentAbsent |

Failed" >

<!ENTITY % QuantitationType_ref "QuantitationType_ref |

SpecializedQuantitationType_ref |

DerivedSignal_ref |

MeasuredSignal_ref |

Error_ref |

PValue_ref |

ExpectedValue_ref |

Ratio_ref |

PresentAbsent_ref |

Failed_ref" >"

Currently:

Declaration for Failed doesn't exist

Becomes:

"<!--

Element and Attlist declarations for Failed

Values associated with this QuantitationType indicate a failure of

some kind for a particular DesignElement for a BioAssay. Of type

boolean.

Associations

Inherites associations from base class StandardQuantitationType.

Attributes

Inherites attributes from base class StandardQuantitationType.

-->

<!ELEMENT Failed_ref EMPTY >

<!ATTLIST Failed_ref identifier CDATA #REQUIRED

name CDATA #IMPLIED >

<!ELEMENT Failed ((%StandardQuantitationType_content;)) >

<!ATTLIST Failed %StandardQuantitationType_attrs; >"

Issue 5533: Recommend changing cardinality of BioSource:sourceContacts (archive)

Source

Rosetta Biosoftware Business Unit (Mr. Michael D Miller, michael_miller@rosettabio.com)

Summary

Recommend changing cardinality of BioSource:sourceContacts

Discussion

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

Resolution

2.1.10, "BioMaterial" of the documentation

Figure 2-11 will be updated

The documentation for BioSource will be updated.

Currently:

"\bsourceContact\b : Contact (0..1)"

Becomes:

"\bsourceContact\b : Contact (0..n)"

 MAGE-OM and the generated MAGE.xmi are updated to modify the SourceContact association

 MAGE-ML.dtd

Currently:

"<!ELEMENT SourceContact_assnref ((%Contact_ref;)) >"

Becomes:

"<!ELEMENT SourceContact_assnreflist ((%Contact_ref;)+) >"

Currently:

"<!ELEMENT BioSource ((%BioMaterial_content;),

SourceContact_assnref?) >"

Becomes:

"<!ELEMENT BioSource ((%BioMaterial_content;),

SourceContact_assnreflist?) >"

Issue 5534: Recommend adding optional association from Compound to DatabaseEntry (archive)

Source

Rosetta Biosoftware Business Unit (Mr. Michael D Miller, michael_miller@rosettabio.com)

Summary

Recommend adding optional association from Compound to DatabaseEntry

Discussion

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

Resolution

2.1.10, "BioMaterial" of the documentation

Figure 2-11 will be updated

Documentation for Compound will add a description of the new association.

Currently:

" Associations:

\bmerckIndex\b : OntologyEntry (0..1)

The Merck Index of this Compound.

\bcomponentCompounds\b : CompoundMeasurement (0..n)

The Compounds and their amounts used to

create this Compound."

Becomes:

" Associations:

\bmerckIndex\b : OntologyEntry (0..1)

The Merck Index of this Compound.

\bcomponentCompounds\b : CompoundMeasurement (0..n)

The Compounds and their amounts used to

create this Compound.

\bexternalLIMS\b : DatabaseEntry (0..1)

Reference to an entry in an external LIMS

data source."

(where \b...\b indicates bold)

 MAGE-OM and the generated MAGE.xmi are updated, adding the new ExternalLIMS association.

 MAGE-ML.dtd

Comment for Compound is updated

Currently:

" Associations

Inherites associations from base class Identifiable.

merckIndex: The Merck Index of this Compound.

componentCompounds: The Compounds and their amounts used to

create this Compound."

Becomes:

" Associations

Inherites associations from base class Identifiable.

merckIndex: The Merck Index of this Compound.

componentCompounds: The Compounds and their amounts used to

create this Compound.

externalLIMS: Reference to an entry in an external LIMS data

source."

Element declaration for Compound is updated

Currently:

"<!ELEMENT Compound ((%Identifiable_content;),

MerckIndex_assn?,

ComponentCompounds_assnlist?) >"

Becomes:

"<!ELEMENT Compound ((%Identifiable_content;),

MerckIndex_assn?,

ComponentCompounds_assnlist?,

ExternalLIMS_assn?) >"

Issue 5535: Make association from DerivedBioAssay to BioAssayMap navigable both ways (archive)

Source

Rosetta Biosoftware Business Unit (Mr. Michael D Miller, michael_miller@rosettabio.com)

Summary

Make association from DerivedBioAssay to BioAssayMap navigable both ways

Discussion

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

Resolution

2.1.11, "BioAssay" of the documentation

Update Figure 2-12

Update documentation for DerivedBioAssay, add description of new association.

Currently:

"\bderivedBioAssayData\b : DerivedBioAssayData (0..n)

The data associated with the

DerivedBioAssay."

Becomes:

"\bderivedBioAssayData\b : DerivedBioAssayData (0..n)

The data associated with the

DerivedBioAssay.

\bderivedBioAssayMap\b : BioAssayMap (0..n)

The DerivedBioAssay that is produced by

the sources of the BioAssayMap."

(where \b...\b indicates bold)

2.1.12, "BioAssayData" of the documentation

Update Figure 2-14

MAGE-OM and the generated MAGE.xmi are updated, changing the Target association between DerivedBioAssay and BioAssayMap.

 The comment for DerivedBioAssay is updated

Currently:

" derivedBioAssayData: The data associated with the

DerivedBioAssay."

Becomes:

" derivedBioAssayData: The data associated with the

DerivedBioAssay.

derivedBioAssayMap: The DerivedBioAssay that is produced by the

sources of the BioAssayMap."

The Element declaration for DerivedBioAssay is updated

Currently:

"<!ELEMENT DerivedBioAssay ((%BioAssay_content;),

Type_assn?,

DerivedBioAssayData_assnreflist?) >"

Becomes:

"<!ELEMENT DerivedBioAssay ((%BioAssay_content;),

Type_assn?,

DerivedBioAssayData_assnreflist?,

DerivedBioAssayMap_assnreflist?) >"

Element and Attlist declarations for BioAssayMap is updated

Currently:

<!ELEMENT BioAssayMaps_assnreflist (BioAssayMap_ref+) >

Becomes:

<!ELEMENT BioAssayMaps_assnreflist (BioAssayMap_ref+) >

<!ELEMENT DerivedBioAssayMap_assnreflist (BioAssayMap_ref+) >

Issue 5550: Allowing a person to belong to only one organization is too restrictive (archive)

Source

Rosetta Biosoftware Business Unit (Mr. Michael D Miller, michael_miller@rosettabio.com)

Summary

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

Discussion

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.

Resolution

No action taken.

Issue 5551: Allowing a QuantitationType to know how it was derived would make navigation easier. (archive)

Source

Rosetta Biosoftware Business Unit (Mr. Michael D Miller, michael_miller@rosettabio.com)

Summary

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

Discussion

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.

Resolution

Changes to the Specification:

Section 2.1.12, BioAssayData

Replace Figure 2-14

Section 2.1.17, QuantitationType

Add to the QuantitationType Association documentation:

Currently:

" \bconfidenceIndicators\b : ConfidenceIndicator (0..3)

The association between a

ConfidenceIndicator and the

QuantitationType its is an indicator for."

Becomes:

" \bconfidenceIndicators\b : ConfidenceIndicator (0..3)

The association between a

ConfidenceIndicator and the

QuantitationType its is an indicator for.

\bquantitationTypeMaps\b : QuantitationTypeMap (0..n)

The QuantitationType whose value will be

produced from the values of the source

QuantitationType according to the

Protocol."

(where \b...\b represents boldface)

Replace Figure 2-20

 MAGE-OM and the generated MAGE.xmi are updated, changing the Target association between QuantitationType and QuantitationTypeMap.

 Modify Entities for QuantitationType

Currently:

" confidenceIndicators: The association between a

ConfidenceIndicator and the QuantitationType its is an indicator

for."

Becomes:

" confidenceIndicators: The association between a

ConfidenceIndicator and the QuantitationType its is an indicator

for.

quantitationTypeMaps: The QuantitationType whose value will be

produced from the values of the source QuantitationType according to

the Protocol."

Currently:

"<!ENTITY % QuantitationType_content "(%Identifiable_content;),

Channel_assnref?,

Scale_assn,

DataType_assn,

ConfidenceIndicators_assnreflist?" >"

Becomes:

"<!ENTITY % QuantitationType_content "(%Identifiable_content;),

Channel_assnref?,

Scale_assn,

DataType_assn,

ConfidenceIndicators_assnreflist?,

QuantitationTypeMaps_assnreflist?" >"

Modify Element and Attlist declarations for QuantitationType

Currently:

" confidenceIndicators: The association between a

ConfidenceIndicator and the QuantitationType its is an indicator

for."

Becomes:

" confidenceIndicators: The association between a

ConfidenceIndicator and the QuantitationType its is an indicator

for.

quantitationTypeMaps: The QuantitationType whose value will be

produced from the values of the source QuantitationType according to

the Protocol."

Issue 5552: Association from FeatureExtraction to QuantitationTypeMapping needed (archive)

Source

Rosetta Biosoftware Business Unit (Mr. Michael D Miller, michael_miller@rosettabio.com)

Summary

Association from FeatureExtraction to QuantitationTypeMapping needed

Discussion

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.

Resolution

No Action Taken

Issue 5553: It should be possible to assign default values to parameters (archive)

Source

Rosetta Biosoftware Business Unit (Mr. Michael D Miller, michael_miller@rosettabio.com)

Summary

It should be possible to assign default values to parameters

Discussion

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

Resolution

Changes to the Specification:

Section 2.1.15, Measurement

The specification for the value attribute for Measurement is changed

Currently:

\bvalue\b : any (required)

Becomes:

\bvalue\b : any (optional)

(where \b...\b represents boldface)

Section 2.1.16, Protocol

The specification of the unit association for Parameter is replaced by

the new specification for defaultValue

Currently:

\bunit\b : Unit (0..1)

Unit the value is associated with

Becomes:

\bdefaultValue\b : Measurement (0..1)

Allows the optional specification of a default values and the unit for the Parameter

(where \b...\b indicates boldface)

 MAGE-OM and the generated MAGE.xmi are updated, adding the DefaultValue association and removing the current association.

 Element and Attlist definitions for Measurement changes

Currently:

<!ELEMENT ActionMeasurement_assn (Measurement) >

<!ELEMENT Measurement_assn (Measurement) >

Becomes:

<!ELEMENT ActionMeasurement_assn (Measurement) >

<!ELEMENT DefaultValue_assn (Measurement) >

<!ELEMENT Measurement_assn (Measurement) >

Element and Attlist declarations for Parameter

Currently:

unit: Unit the value is associated with

dataType: The type of data generated by the parameter i.e. Boolean, float, etc...

Becomes:

defaultValue: Allows the optional specification of a default values and the unit for the Parameter

dataType: The type of data generated by the parameter i.e. Boolean, float, etc...

Currently:

<!ELEMENT Parameter ((%Identifiable_content;),

Unit_assn?,

DataType_assn?) >

Becomes:

<!ELEMENT Parameter ((%Identifiable_content;),

DefaultValue_assn?,

DataType_assn?) >

Issue 5554: Need a way to model features that are associated with a BioMaterial (archive)

Source

Rosetta Biosoftware Business Unit (Mr. Michael D Miller, michael_miller@rosettabio.com)

Summary

Need a way to model features that are associated with a BioMaterial

Discussion

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.

Resolution

No Action Taken.

Issue 5555: ExperimentFactor needs an OntologyEntry association (archive)

Source

Rosetta Biosoftware Business Unit (Mr. Michael D Miller, michael_miller@rosettabio.com)

Summary

ExperimentFactor needs an OntologyEntry association

Discussion

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

Resolution

Section 2.1.13, Experiment

The specification for ExperimentalFactors documents the new association

Currently:

\bfactorValues\b : FactorValue (0..n)

The pairing of BioAssay FactorValues with the ExperimentDesign ExperimentFactor.

Becomes:

\bfactorValues\b : FactorValue (0..n)

The pairing of BioAssay FactorValues with the ExperimentDesign ExperimentFactor.

\bannotations\b : OntologyEntry (0..n)

Allows describing additional information such as concentration of Tamoxafin with a

CASRegistry #.

(where \b...\b indicates boldface)

Update Figure 2-15

 MAGE-OM and the generated MAGE.xmi are updated, adding the Annotation association

 Element and Attlist declarations for ExperimentalFactor

Currently:

factorValues: The pairing of BioAssay FactorValues with the ExperimentDesign ExperimentFactor.

Becomes:

factorValues: The pairing of BioAssay FactorValues with the ExperimentDesign ExperimentFactor.

annotations: Allows describing additional information such as concentration of Tamoxafin with a CASRegistry #.

Currently:

<!ELEMENT ExperimentalFactor ((%Identifiable_content;),

Category_assn?,

FactorValues_assnlist?) >

Becomes:

<!ELEMENT ExperimentalFactor ((%Identifiable_content;),

Category_assn?,

FactorValues_assnlist?,

Annotations_assnlist?) >

Issue 5556: Specifying a FactorValue needs to be more flexible (archive)

Source

Rosetta Biosoftware Business Unit (Mr. Michael D Miller, michael_miller@rosettabio.com)

Summary

Specifying a FactorValue needs to be more flexible

Discussion

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.

Resolution

Changes to the Specification:

Section 2.1.13, Experiment

Specification of the associations for FactorValue is updated.

Currently:

\bmeasurement\b : Measurement (1..1)

The measured value for this factor.

Becomes:

\bmeasurement\b : Measurement (0..1)

The measured value for this factor.

\bvalue\b : OntologyEntry (0..1)

Allows a more complex value to be specified for a FactorValue than a simple Measurement.

(where \b...\b indicates boldface)

 MAGE-OM and the generated MAGE.xmi are updated, adding the Value association and the rule

 MAGE-ML.dtd

Element and Attlist declarations for FactorValue is updated

Currently:

measurement: The measured value for this factor.

Becomes:

measurement: The measured value for this factor.

value: Allows a more complex value to be specified for a FactorValue than a simple Measurement.

Currently:

<!ELEMENT FactorValue ((%Identifiable_content;),

Measurement_assn) >

Becomes:

<!ELEMENT FactorValue ((%Identifiable_content;),

(Measurement_assn? | Value_assn?)) >

Issue 5557: Instances of OntologyEntries need a way to be further qualified (archive)

Source

Rosetta Biosoftware Business Unit (Mr. Michael D Miller, michael_miller@rosettabio.com)

Summary

Instances of OntologyEntries need a way to be further qualified

Discussion

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.

Resolution

Changes to the Specification:

Section 2.1.3, Description

Add to the QuantitationType Association documentation:

Currently:

" \bontologyReference\b : DatabaseEntry (0..1)

Many ontology entries will not yet have formalized ontologies. In those cases, they will not have a database reference to the ontology. In the future it is highly encouraged that these ontologies be developed and ontologyEntry be subclassed from DatabaseReference."

Becomes:

" \bontologyReference\b : DatabaseEntry (0..1)

Many ontology entries will not yet have formalized ontologies. In those cases, they will not have a database reference to the ontology. In the future it is highly encouraged that these ontologies be developed and ontologyEntry be subclassed from DatabaseReference.

\bassociations\b : OntologyEntry (0..n)

Allows an instance of an OntologyEntry to be further qualified."

Replace Figure 2-4

MAGE-OM and the generated MAGE.xmi are updated, adding the association from OntologyEntry to itself.

MAGE-ML.dtd

Modify Element and Attlist declarations for OntologyEntry

Currently:

" ontologyReference: Many ontology entries will not yet have formalized ontologies. In those cases, they will not have a database reference to the ontology. In the future it is highly encouraged that these ontologies be developed and ontologyEntry be subclassed from DatabaseReference."

Becomes:

" ontologyReference: Many ontology entries will not yet have formalized ontologies. In those cases, they will not have a database reference to the ontology. In the future it is highly encouraged that these ontologies be developed and ontologyEntry be subclassed from DatabaseReference.

associations: Allows an instance of an OntologyEntry to be further qualified."

Currently:

"<!ELEMENT Annotations_assnlist (OntologyEntry+) >

<!ELEMENT Category_assn (OntologyEntry) >"

Becomes:

"<!ELEMENT Annotations_assnlist (OntologyEntry+) >

<!ELEMENT Associations_assnlist (OntologyEntry+) >

<!ELEMENT Category_assn (OntologyEntry) >"

Currently:

"<!ELEMENT OntologyEntry ((%Extendable_content;),

OntologyReference_assn?) >"

Becomes:

"<!ELEMENT OntologyEntry ((%Extendable_content;),

OntologyReference_assn?,

Associations_assnlist?) >"

Issue 5558: Database role to be associated with person/organization (archive)

Source

Rosetta Biosoftware Business Unit (Mr. Michael D Miller, michael_miller@rosettabio.com)

Summary

Database role to be associated with person/organization

Discussion

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.

Resolution

 Reject the change

Issue 5558(alt): Database role to be associated with person/organization (archive)

Source

Rosetta Biosoftware Business Unit (Mr. Michael D Miller, michael_miller@rosettabio.com)

Summary

Database role to be associated with person/organization

Discussion

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.

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.

Resolution

Changes to the Specification:

Section 2.1.2, AuditAndSecurity

Replace Figure 2-3

For Security, modify the Association documentation

Currently:

\breadGroups\b : SecurityGroup (0..n)

Specifies which security groups have read permission.

\bwriteGroups\b : SecurityGroup (0..n)

Specifies which security groups have write permission.

Becomes:

\bsecurityGroups\b : SecurityGroup (0..n)

Specifies which security groups have permission to view the associated object.

(where \b...\b represents boldface)

MAGE-OM and the generated MAGE.xmi are updated, eliminating the current associations from Security to SecurityGroup and adding a more general association.

MAGE-ML.dtd

Modify Element and Attlist declarations for Security

Currently:

readGroups: Specifies which security groups have read permission.

writeGroups: Specifies which security groups have write permission.

Becomes:

securityGroups: Specifies which security groups have permission to view the associated object.

Currently:

<!ELEMENT Security ((%Identifiable_content;),

Owner_assnreflist?,

ReadGroups_assnreflist?,

WriteGroups_assnreflist?) >

Becomes:

<!ELEMENT Security ((%Identifiable_content;),

Owner_assnreflist?,

SecurityGroups_assnreflist?) >

Modify Element and Attlist declarations for SecurityGroup

Currently:

<!ELEMENT ReadGroups_assnreflist (SecurityGroup_ref+) >

<!ELEMENT WriteGroups_assnreflist (SecurityGroup_ref+) >

Becomes:

<!ELEMENT SecurityGroups_assnreflist (SecurityGroup_ref+) >

Issue 5559: Attribute to be added to describe its type (archive)

Source

Rosetta Biosoftware Business Unit (Mr. Michael D Miller, michael_miller@rosettabio.com)

Summary

Attribute to be added to describe its type

Discussion

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.

Resolution

 No Action Taken.

Issue 5560: For interoperability, need a rule for formatting numbers (archive)

Source

Rosetta Biosoftware Business Unit (Mr. Michael D Miller, michael_miller@rosettabio.com)

Summary

For interoperability, need a rule for formatting numbers

Discussion

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

Resolution

Reject the change

Issue 5560 (alt) : For interoperability, need a rule for formatting numbers (archive)

Source

Rosetta Biosoftware Business Unit (Mr. Michael D Miller, michael_miller@rosettabio.com)

Summary

For interoperability, need a rule for formatting numbers

Discussion

After the first solution was suggested, Jason Stewart, Open Informatics, suggested that referencing the W3C XML specification would be better.

Resolution

 Changes to the Specification:

Add a section in Section 1.1, General Remarks, between Section 1.1.4 and

Section 1.1.5 and title it "Number Format"

Text for added section:

"In order to foster interoperability, it is necessary to agree on a common

lexicographical representation of numbers in valid MAGE-ML XML documents.

Since the W3C recommendation, "XML Schema Part 2: Datatypes", contains

definitions for such representations, they are the recommended form.

Below are the definitions from that specification:

"3.2.2 boolean

...

3.2.2.1 Lexical representation

An instance of a datatype that is defined as ·boolean· can have the following

legal literals {true, false, 1, 0}."

"3.2.3 decimal

...

NOTE: All ·minimally conforming· processors ·must· support decimal numbers with

a minimum of 18 decimal digits (i.e., with a ·totalDigits· of 18). However,

·minimally conforming· processors ·may· set an application-defined limit on the

maximum number of decimal digits they are prepared to support, in which case that

application-defined maximum number ·must· be clearly documented.

3.2.3.1 Lexical representation

decimal has a lexical representation consisting of a finite-length sequence of

decimal digits (#x30-#x39) separated by a period as a decimal indicator. If

·totalDigits· is specified, the number of digits must be less than or equal to

·totalDigits·. If ·fractionDigits· is specified, the number of digits following the

decimal point must be less than or equal to the ·fractionDigits·. An optional leading

sign is allowed. If the sign is omitted, "+" is assumed. Leading and trailing zeroes

are optional. If the fractional part is zero, the period and following zero(es) can

be omitted. For example: -1.23, 12678967.543233, +100000.00, 210."

(·totalDigits· would be documented for an attribute by the exporting organization of

the XML)

"3.3.13 integer

...

3.3.13.1 Lexical representation

integer has a lexical representation consisting of a finite-length sequence of decimal

digits (#x30-#x39) with an optional leading sign. If the sign is omitted, "+" is assumed.

For example: -1, 0, 12678967543233, +100000."

"3.2.4 float

...

3.2.4.1 Lexical representation

float values have a lexical representation consisting of a mantissa followed, optionally,

by the character "E" or "e", followed by an exponent. The exponent ·must· be an integer.

The mantissa must be a decimal number. The representations for exponent and mantissa must

follow the lexical rules for integer and decimal. If the "E" or "e" and the following

exponent are omitted, an exponent value of 0 is assumed.

The special values positive and negative zero, positive and negative infinity and

not-a-number have lexical representations 0, -0, INF, -INF and NaN, respectively.

For example, -1E4, 1267.43233E12, 12.78e-2, 12 and INF are all legal literals for float."

"3.2.5 double

...

3.2.5.1 Lexical representation

double values have a lexical representation consisting of a mantissa followed, optionally,

by the character "E" or "e", followed by an exponent. The exponent ·must· be an integer.

The mantissa must be a decimal number. The representations for exponent and mantissa must

follow the lexical rules for integer and decimal. If the "E" or "e" and the following

exponent are omitted, an exponent value of 0 is assumed.

The special values positive and negative zero, positive and negative infinity and

not-a-number have lexical representations 0, -0, INF, -INF and NaN, respectively.

For example, -1E4, 1267.43233E12, 12.78e-2, 12 and INF are all legal literals for double."

Add to Appendix A, References, in alphabetical order:

"Paul V. Biron, Ashok Malhotra, eds. 2001. XML Schema Part 2: Datatypes, W3C Recommendation.

2 May 2001.""

Issue 5561: Group BioSequences that share the same type, PolymerType, and Species information (archive)

Source

Rosetta Biosoftware Business Unit (Mr. Michael D Miller, michael_miller@rosettabio.com)

Summary

Group BioSequences that share the same type, PolymerType, and Species information

Discussion

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.

Resolution

No Action Taken