Changes between Version 35 and Version 36 of PhyloWS_workgroup

Show
Ignore:
Timestamp:
2008/02/13 12:15:14 (11 years ago)
Author:
hlapp
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • PhyloWS_workgroup

    v35 v36  
    3232  * But we usually also have (possibly multiple) support values associated with tree branches 
    3333 
    34 == Tuesday session == 
     34== Services versus their Inputs and Outputs  == 
    3535 
    3636In a white board exercise, we identified plausible input and output data types for phyloinformatic webservices. Plausibility is defined by our being able to imagine [https://www.nescent.org/wg_evoinfo/PhyloWS#Use_Cases use cases] (no time line for implementation implied, the goal here is to come up with interfaces) 
     
    6060 * '''String''' - for metadata, e.g. descriptions 
    6161 * '''Stringvector''' - for metadata, e.g. a set of tags 
     62 
     63== Node metadata == 
     64 
     65There is an extensive number of metadata elements one might want to record for nodes in a tree. Beyond the basic gene name, sequence ID, and taxon, metadata range from biogeography (area, lat/long), to host species (for analyses of host/parasite co-evolution), to functional attributes (GO terms, expression, subcellular location).  
     66 
     67Some of these attributes may blur the line to actual character data for nodes (whether tips or internal). In fact, the notion of strictly distinguishing between node metadata and node character data may not be tenable or useful in reality; data may be metadata in one situation, and used as correlated character in another situation, and used for tree inference in a third situation. 
     68 
     69There are essentially two ways to represent node metadata: 
     70 * Using a metadata schema (for example, an XML Schema, or a XML document definition, similar to metadata schemas in use in the library sciences such as DC, MARC21, etc). 
     71  * Pros: provides a clear expectation for clients as to what metadata to expect, and the meaning of those elements can be (hard-)coded into applications. 
     72  * Cons: limited to whatever the metadata schema allows for, and any new metadata elements deemed useful by emerging research cannot be readily expressed (and rectifying that requires a metadata schema update, which in turn affects client applications rather directly). In addition, the meaning of metadata elements cannot be dynamically inferred or stated; it is implicit from the XML DTD or Schema definition. 
     73 * Using attribute/value pairs, where attribute names are drawn from a controlled vocabulary. 
     74  * Pros: allows for an unlimited number of metadata elements, and easy representation of new elements as necessitated by new research approaches. The semantics of a metadata element can be as richly represented as desired, in a readily machine-readable form, by relating the attribute term to other ontology terms. The metadata representation is readily amenable to an OWL or RDF representation. 
     75  * Cons: a client cannot know in advance which metadata elements it may encounter (though it may limit itself to only interpret a pre-defined number of them), and the full semantics of a metadata element may change solely by the underlying ontology changing. 
     76 
     77We feel that only using attribute/value pairs fits our and research requirements.