MAGE/ MO policies and examples (March 22, 2004): The policies for representing the MGED Ontology in MAGE-ML are incorporated in the following pseudocode for generating MAGE (courtesy Angel Pizarro). This is followed by a series of examples. DatabaseEntry (OntologyEntry) { create MAGE DatabaseEntry that references whatever is in OntologyEntry.value, if applicable } CreateOE(Term ) { if (Term == Instance) => { OE.category = parent of Term , OE.value = instance term OE.OntologyReference = DatabaseEntry(OE); } elsif (Term == Class || Term == Property ) => { OE.category = term , OE.value = term, OE.OntologyReference = DatabaseEntry(OE); OE.Association = [ foreach ChildTerm of Term { CreateOE(ChildTerm) } ] } else (Term == user-defined ) => { OE.category = parent of Term || base type of Term || Term OE.value = Term } } Notice that the third rule is pretty much the Instance or the Class rule, but with no DatabaseEntry() call. Also note that this only covers what to do once you have a MO specified completely before hand, not how you go about applying MO term as OE's in the first place. 1. all MO terms are to be database referenced in the following way: ... Note: If the database reference is omitted, then the term is assumed to be user-defined. If a database reference is not for MO, MO terms may still be used for the MAGE category (to enhance searches) although these are not strictly speaking acting as MO terms. 2. When the MAGE category in the OntologyEntry tag is a MO class with individuals, then the MAGE value is one of those individuals. For example: 3. When the MAGE category in the OntologyEntry tag is a MO class without individuals because it is an abstract class, then the MAGE value is the MO class. Two examples are provided. In the first (3A), an abstract class is followed by a subclass with instances. In the second (3B), an abstract class has a property with filler "thing." 3A. Note: The above example might occur when it is desirable to provide a full path to an instance to facilitate searching. In this case, the MAGE association "Characteristics" from BioMaterial to OntologyEntry is directed to "IndividualGeneticCharacteristics" instead of directly to "diploid." 3B. Note that in the example above, the abstract class was followed by a MO property "has_ID" whose filler is "thing". The MO property "has_ID" has an OntologyReference _assn whereas "mouse123" does not because it is essentially free text. The coding of properties is fully described in the next example. 4. When the MAGE category in OntologyEntry tag is a MO property then the MAGE value is the MO property. If the property filler is a class, then the class is associated with the property. If the filler is of the type, one-of, then the instance is associated with the property. If the filler is a thing (or string, integer, etc.), then the "thing" is associated with the property as illustrated in example 3B. The MO class Age provides examples of all three cases. Note: in the above example, InitialTimePoint and TimeUnit are classes with instances, Age, Measurement and Unit are abstract classes, initial_time_point, has_measurement, and has_units are properties with classes as fillers, has_measurement_type is a property with a one-of filler, value is a property with 'thing' as filler. Also note that all terms used for values are database referenced except for '48'. In these cases, the MO classes and properties are database referenced. 5. The MO OntologyEntry class and its subclasses follow the previous policies. This class has a property 'value' with filler 'thing'. The filler is taken from an external database or is user-defined. For example: Note: The above example was taken from the file(GilertoTestAnnotationValidated.xml. Also note that a reference is made to the nci_thesaurus as well as to MO and that "C7857" is an accession in the nci_thesaurus but is simply a "thing" filler for the property "has_accession" in MO.