Kevin,
I think the approach that Stan outlines in looking at specific relationships among
entities should make much of the complication, seem a bit less of an obstacle. We
need to better understand the properties of our "data objects" and the various
ways they are associated. If we define our vision too narrowly, and here is
perhaps where I would disagree with you and Stan, we will end up with a result
that may not be as general and flexible as we might need later. We run the risk
that it will probably difficult to adapt to more complex relations. However, I do
believe Stan is correct in that we need to first focus on the simplest relations
among entities. This is probably a good idea for two reasons: 1) if we have
started with the right notion of "fundamental objects" at least some of their
interactions will be simple (also read general, ie less constrained), if we have
evaluated them correctly, and 2) simple relations will likely be more efficiently
implemented and at the core of our "hyperspace shuttle" (hyperbike?) we will
require efficiency, since the number of data sets and transformations are already
large.
If I understand the rationale for engaging in this exercise it is to permit users
to search, select and "interoperate" with a variety of different data types and
structures so that data mining and new insights can be gained. I believe we agree
that we need more than a translator, but how much more, I believe, will remain
unclear until we have a better handle on exactly what properties these various
entities (features and data structures used to represent them) actually have.
This is not to say that studying carefully how specific translators may work (ie
Lucid to DELTA or reverse or Lucid to NEXUS, etc.) will not be informative for
ellucidating the generalities that are required. On the contrarary, the approach
you suggest is quite a workable one and may well suffice for more limited ends.
My earlier comments were directed to permit the structure of the specifications to
extend to more general data types than we might be able to currently envision.
I reiterate the general structure of the "standard descriptor language" should not
restrict progress along the lines you suggest, only that it would be useful adopt
a general approach that could subequently incorporate such extended
functionality. I guess it stems from my need (hope) for mechanisms that will help
me integrate loosely structured text (in a web-based environment) and more
quantitative (operational) means of structuring data.
At the conceptual level, the notion of "character" is central to the dicussion of
what we mean by taxonomic information. I believe we need to have a recomendation
for a specification that taxonomists/systematists can adopt to include the
"universe" of such characters, not that all are equal or equally important, or
utilized by a given implementation. The recommendation probably also needs to be
simple enough that most can understand and use it. Nonetheless, there appear to
be many different kinds of characters and here is where things start to get hard.
Some such as cladistic characters will have a basis of comparison that maps the
characters into specific disjoint character states. Others will be mensural or
countable in nature, whose basis of comparison defines an axis of variation and
may or may not exhibit the property of disjunction (disjuction may be a property
of sampling). In both cases they could be represented by a vector. However, we
must understand the rules of accessing each element and whether or not specific
relations can be drawn from manipulation across vector types. In the case of the
former they can be represented by text or by tags (ie state A vs. B, or 0 and
1). The text used may be circumscribed via controled vocabularies to permit
analogy, if not direct comparision, with quantified characters (ie long vs short,
round vs square, etc). Admittedly, this will be difficult because most biologists
often have used "local" reference frames when using free text in this way, rather
than any sort of "universally" applicable frame that we might be speaking about
for the first time here. Consequently, "round" or "large" can have very different
meanings. However, even here we can probably safely conclude that the
dimensionality of primary interest is 3D, at least when attempting to characterize
the size and shapes of features.
While the number of permutations may be extremely large, it may well be possible
to circumscribe characters with relatively few "tags", if we can define common
rules for the use of these "tags". Perhaps the tags might define a
classification of characters (ie <qualitative character>, <quantitative
character>, in the former one may have <cladistic characters> and <general
qualitative> and among these <cladistic characters> might be further subdivided
<two state> or <multi-state> and the later may be tagged as <fully ordered> or
<partially ordered>, where as the former as well as the latter may also be tagged
as <directed> or <undirected>. Similarly, cladistic characters will have other
properties that could likewise be tagged <name>, <study used>, <basis of
comparison>, <textual description>, <date first proposed>, <represention of states
(ie 0's and 1's or some other tagging scheme)> some of which might have multiple
entries, such as <name (perhaps different for two different investigators, but the
same "character" nonetheless)> or <study used>. Not all tags might get used.
However, if they are used, a standard must specifiy how they are to be used.
Characters also have other properites such as scale. Although most informative in
a measured sense, (Angstroms, microns, millimeters, meters, and nanograms, grams,
kilograms, etc.), we would likely have to establish relations among a variety of
different kinds of reference scales (ie molecular, subcellular, cellular, tissue,
organ, organismal, ecosystem), which are variously defined in a broad array of
contexts. Where possible, it would be useful to attempt to at least loosely
interoperate across such reference frames, say for purposes of a broad search.
Characters also have scope in that they are mapped onto organisms. Consequently,
conventions are also necessary to circumscribe what we mean by taxon and how we
deal with issues of rank (and perhaps newer philosophies of "rankless"
classfication that seek to deprecate the concept of rank). Although multiple
classifications and synonyms make both kinds of mapping complex, "standardized"
lists of names for molecules, structures, and taxa do exist that we can use to
simplify some of the complexity. Characters also exist through time, but again
absolute scales are often wanting and we will likely need to deal with the period
of time in which a character exists (existed) in relation to relative reference
frames. Obviously, in each case we require a means to specify the nature of the
standardization, much as XML names spaces attempt to deal with the potential
confounding of elements of the same "name"). Here it would be helpful to have a
"standard list of standard lists" so that we can begin to understand how ungainly
such an approach might actually be. Some such as the geological reference scale
and ITIS names list are obvious candidates, but it would be nice begin to assemble
the URL's that we might have to visit to actually understand the details.
While not all implementations would need utilize all "implict" tags, specification
of the nestedness of a particular tagging scheme would require specification
(standardization). Such an approach does lend itself nicely to parsing and to
object-oriented definition. At the level of implementation, it would not be hard
to imaging for example Lucid or Delta passing their own internal representation to
the parser that uses the specification inherent in the internal representation to
wrap characters with (XML) tags that could then be either translated to other data
formats, or processed according to a previously specified search criteria or set
of processing instructions that might perform another kind of association, data
mining, or analysis. Similarly, it would be relatively easy to take range data
from a given CAT scan or structured light range-sensor or graphical data gif or
jpg files and similarly tag (annotate) it so that particular features of the data
could be given "equivalent" meaning for association with otherwise qualitative
data. Admittedly, getting the machine to do the annotation remains, except in
limited circumstances, a dream for the heavens, and I too would just settle for a
"hyperbike" (with training wheels) at this stage in the development of "hyperspace
shuttle archicture".
Stuart
Kevin Thiele wrote:
> Dear Stuart,
>
> I agree completely with everything you say, but it worries me all the same.
> You point out the complexity of descriptive data and the enormity of the
> task of completely capturing it. But we need to get something done, and I
> think we need some incremental stages.
>
> Your suggestion as to maintaining threads of discussion is not unlike the
> way the list was running before it fell over. Some of the threads did
> indeed morph into monsters, others got lost and I think many people with
> them. I'd really like to try for a while keeping the discussion focused on
> the document with the proposed list of elements, to glean suggestions from
> people as to whether it's completely inadequate or what. At the same time,
> of course, I don't want to constrain people to run with this or with my
> suggested way of doing things. I may well be way off the track of what's
> possible or achievable. Working up the document may provide us with an
> incremental advance, or it may be that such incremental advances are not
> worth achieving and your suggestion for a great leap forward is the way to
> go. My way of looking at it is that if DELTA is a bicycle, I'm proposing a
> motor bike, and you're sketching out plans for a space shuttle. Maybe I'm
> not being visionary enough?
>
> It seems to me that there's an old way of describing something, and many
> possible new ways. The old way is with a set of characters with values
> (states) applied to a set of taxa. This is the form of DELTA data, Lucid
> data, textual descriptions (in a way). Updating our standard for this way
> of describing is achievable now, I think.
>
> New ways of describing something, such as with 3-D tomographic imaging etc,
> may well be the way of the future. But I'm not sure that we can have one
> descriptive standard that encompasses both old and new ways under one roof.
> This is why we need extensibility - can we take an incremental step along
> the lines that I'm proposing while allowing for the future brave new world.
> Or can we have a set of linked standards - one for describing in the boring
> old characters/states/taxa way, and others for the more space-shuttle ways
> that can be linked in as they develop.
>
> Looking forward to responses
>
> Cheers - k
>
> At 06:07 PM 19/7/00 -0600, you wrote:
> >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.doc
> > > DDST Specifications.doc Type: Microsoft Word Document
> > (application/msword)
> > > Encoding: base64
