Kevin and colleagues,
As per our discussions at the US-Australia Workshop, I would again reiterate a few general observation with respect to the list and express my agreement with specific comments made by you, Bryan Heidorn, and Stan Blum. However, with your indulgence, I would also like to provide what may be a somewhat different perspective.
The focus on "requirements" for a descriptive data standard for taxonomy, as you and Stan emphasize is a critical one, even though as Bryan points out there remains a number of issues that need to be dealt with that may not be fully accounted for in the draft standard you have kindly provided. I would agree that we need a mechanism (structure?) for subsequent discussion on the list to permit both general, theoretical issues to be addressed, while simultaneously breaking down the practical realities of dealing with the complexity of specific issues involved that at times dictates useful "digression" into jargon-laden specifics that might be relevant for particular implementation issues that require vigorous discussion. I'm not sure at this stage whether it is possible, at least in my own mind, to distinguish structure from content, since dealing with existing structure and content may be necessary to define what we perceive are requirements. My own sense of the previous discussion is that there are a variety of perspectives as to what constitutes "descriptive data" and "requirements" in this context, as well as what are the specific priorities (aspects of "standards") that are necessary for specific applications (eg DELTA and LUCID) to intercommunicate in an application-neutral manner. However, mixing them into a common thread proved a bit overwhelming.
My own bias is for a better understanding of how we can construct such a "draft standard" so that it is open to considerable extension for the incorporation of meta-language descriptors for more esoteric data structures, while maintaining a flexible general framework needed to associate existing "character" data, while also addressing the practical necessity of managing various "annotations" of qualitative characters. I believe this is important primarily because we ultimate want machines to do most of the translating among formats, with minimal loss of information or human intervention. I believe it is also important for the more difficult task that lies ahead of encoding means for machines to "feature extract" across a multiplicity of representations of character data.
As a taxonomists/morphologist I am constantly confronted with new data formats and widely different data sources. Virtually all are created in specific contexts and do not generally have a "web-wide" mechanism for associating their content. For example, it is difficult for me to determine if there exist data sets that encompass different "encodings" of information pertaining to specific structures for specific taxa. I need a dyanamic mechanism that will permit me to become aware of data sets pertaining to say the pectoral fins of a particular scorpionfish, without having to know in advance that such data may exist in the form of 1) a collections record of a skeleton in a particular collection, 2) a published data set characterizing the measurements taken from a particular study, 3) a CAT scan of such a critter, 4) an archive containing the representation of specific character states used in a phylogenetic analysis, 5) numerous gif/jpg files of radiographs of specimens, 6) a text based description of the pectoral fins in a fossil, 7) the title of a paper describing the sensory innervation of the fin, or 8) a database of specific HOX genes involved in fin formation.
Certainly, the Rich Attribution component of your document is critical element for this, but I do not yet see how I can use this document to establish the "meta-data wrapper" needed to compile such a list, much less establish to what extent I can use such a text based "wrapper" to associate these disparate kinds of taxonomic data. How do I deal with data that are largely numeric in content or purely graphic (pixel encoded)? Nonetheless, I would agree that there is a need for a series of "collation rules" to establish scope at different hierarchical levels or for specific context-oriented activity. I would, for example, add several lower levels still in this context (including parts of specimens as described at the organ, tissue, and cellular, subcellular, and molecular level). Of course, the difficulty here is that resolution and context may create data structures that are not entirely hierarchical, particularly for objects of composite origin or study. For the nervous system in chordates one can break down the system into units with respect to various elements that could in one sense be heirarchical (perhaps brain, spinal chord, ramus lateralis accessorius, neuron, motor unit, motor endplate, etc.). However, with respect to a physiological classification dealing with action at the level of specific neurons this classification scheme would not work since the nerve is composite and composed of both sensory and motor elements. Likewise, it would be difficult to place neuroendrocrine components, specific neuropeptides, or developmental anlagen, such as placodes, however important, into a parallel heirarchy. Likewise, usefully descriptive properties could not be easily restricted to specific components. I found the discussion at the workshop regarding the use of acyclic directional graphs as a fundamental data structure most interesting, but I'm not sure that morphological descriptors, perhaps unlike gene products, are necessarily acyclic. For example, a specific bone such as the mandible can be classified as an element of the visceral skeleton as well as a composite element containing both endochondral as well as dermal bone. If one looks early enough in development, one can't even recognize these anatomical distinctions, although they may exist at a molecular level. How should structures that change with development or function be tagged and associated? Would this not depend upon context? Nonetheless, following from your document, it might be a useful excercise to consider to what extent certain classes of morphological descriptors can be considered in such a graph-theoretical framework from which we might be able to establish certain constructs as useful in associating otherwise disparate, yet specific data (glossaries?). Trees certainly are a useful data structure for description of many morphological features, but not the only ones.
Consequently, it might be useful to break up the discussion into sub-discussions or threads for which specific requirements can be more readily circumscribed and for which the makings of a "meta-language" needed to search and assimilate alternate representations might be more quickly forthcomming. This is important because the universe of potentially different data structures for encoding character data is very large. There is no need for those interested primarily in DELTA - LUCID translations, or LUCID - PHYLIP, etc. transformations to be held up by more specific requirements concerning translations/annotations of more arcane data structures, even though some, like Bryan and I, may feel that transformations between "other kinds" of data structures must also be incorporated in a way that allows their potential richness to be exploited. However, acheiving such extensibility will require the "standard discriptors" to be be quite general (but not ambiguous) in construction.
Such an approach might permit us to generalize across a number of possibly highly specific topics and requirements that are not universally applicable and with which many of us are differentially fluent. This approach would be especially useful, should we begin at a latter point begin to use them to construct XML schema or to outline what might be necessary using XSLT to transform them from one XML format to another. Since XML is promising as a data neutral specification language, we might want to maintain a separate "XML thread", and perhaps even various XML (alternative)-implementaton subthreads (Java XML API's vs MS XML API's, vs "others? or DTD's vs Schemas, "elements" vs "atributes", etc.) that will influence how such a "standard" could currently be implemented. Although certainly I would agree that we do not want implementations to drive the standards, it is important to have an understanding of how potential implementation might affect the utility of the standards. It might be useful here to draw an analogy to the presentation made at the workshop by Sue Rhee in her discussion of the need for an "ontological" database for common annotation of gene function across molecular databases. Likewise, we need a generalized means of characterizing the "language" used to describe the various entries in different "glossaries" used to describe character data. The need for such "cross molecular" databases would not arise, except for specific implementation issues that are not presently adequately addressed. Likewise, your "External lexica" might be usefully encompassed in the concept of XML name spaces. Although I can't think of specific examples off the top of my head, some anatomical terms are used differently in different contexts ("viens" in animals and plants might be a simple example). We need to be able to distinguish the contexts. Perhaps this is what you mean by global versus local characters?
Hence, from my perspective it might be useful for the dialog to move forward along several separate, yet not entirely distinct threads, where folks with specific interests could provide input as they see fit, ignoring that which seems irrelevant. A few may even want to keep their thumbs in all the pies. In glancing over what has come before, we might consider as possible threads: 1) general theoretical perspectives on "taxonomic data", 2) one or more application specific threads (ie DELTA, LUCID, "phylogeny packages", NEXUS, others?, etc.), 3) issues pertaining to description and characterization of qualitative data, 4) issues pertaining description and characterization of quantitative characters, 5) issues pertaining to text based description (semi-structured data), 6) issues pertaining to structured data (ie relational or object modeled data structures), and 7) meta-language requirements (headers, tagging architecture, XML etc.). No doubt you or others might be able to amend these or to add a few others from within which we might eventually reach consensus on assembly of a few key requirements that are general to all and from which interoperable implementation could proceed so as to be able to assess the usefulness of our work. Perhaps some threads could rule out discussion of "content" and others "structure". In any event, it might be useful to let natural selection act to allow the most productive threads to survive and "establish focus", while the others die out, without letting the whole wither because of the complexity and interconnection of the fundamental issues.
No doubt some of these threads will might morph into monsters not anticipated. Consequently, to keep it all coordinate, there must be some general agreement/understanding to focus on common requirements (GOALS) that we are trying to acheive. However, at this early stage, these might be largely implict so as not to lock ourselves into unnecessarily narrow perspectives. For this to work, perhaps one or two "ring masters" or "virtual ushers (bouncers?)" are needed to keep the various performers and audience on cue, to summarize progress from time to time, and to remove, add, or combine threads at key moments (ie oversee and exert some "administrative" control over the various threads). This is important so that a specific set of useful general requirements is forthcomming in a timely fashion. I nominate you and Bryan (actually you guys nominated yourselves in Boston or was it unanimous proclamation?). Subsequent to such general and specific discussion, I believe we would then be in a better position to respond to specific requests for comments on documents, such as that you have put forth outlining draft standards.
Stuart
Kevin Thiele wrote:
Dear Colleagues,
you will all be aware that the SDD list fell over several months ago. My interpretation of this is that many of the taxonomists on the list were left behind, perhaps early on, by the energetic discussions over issues of data structuring (XML, schemas, RDF etc). Most of this was certainly way over my head. Things got too top-heavy, and attempts to structure the discussion using message tags didn't seem to provide much focus.
Recent discussions (at a meeting on US-Australian cooperation in bioinformatics in Washington, July 2000, attended by several SDD contributors) has again highlighted the great need for an SDD standard and shown that the lack of a new, inclusive standard is holding back progress on descriptive databasing and software design.
We need to restart the list with better focus. I'd like to suggest that the way forward is to entirely set aside (for the time being) any discussion of data structure and focus entirely on content (the requirements analysis) for a while. We should agree on an outline of the data that we need to capture, then pass this on to the computerheads to provide a best-practice structure for storing and managing this captured data.
The attached document was put up to the list shortly before it fell over. It's attached again here, slightly edited. ANY TAXONOMISTS STILL OUT THERE
- please look at this. What data that you need to capture aren't handled
here? Will this work? Is this the way to proceed?
I think that the document subsumes the data requirements of the DELTA and Lucid programs, plus a bit more particularly in the areas of data attribution and hierarchical nesting of treatments. The intention is that the elements in this list should provide a way of storing any data needed to describe the morphology or anatomy of any organism or taxon.
Note that this should be read merely as a list of data elements - the structure of the list does not imply a structure for the data file (XML or otherwise) used to store the data.
It may be the case that this document can be jointly modified to produce a final document, or we may need to start from scratch with another. Any ideas?
Cheers - k
Name: DDST Specifications.docDDST Specifications.doc Type: Microsoft Word Document (application/msword) Encoding: base64