- tdwg-content - lists.tdwg.org

Re: Draft Spec mark 2
by Kevin Thiele 02 Sep '00

02 Sep '00

Following several comments from the list: Any and all comments about the syntax in my document and examples: I SHOULD have said that I'm not trying to make this "proper" XML yet. My intention is just to determine the data elements needed - it seems to me that once we've done that the best-practice XML (e.g. should this data element be content or attribute) can be done by you people with the knowledge to do it properly. So please read anything that looks like XML in the examples as pseudo-XML. Perhaps there's a better way of writing the examples to make it clear they're not supposed to be XML yet. I'm sure I'm going to regret not having done this. Cheers - k

1 0

Re: Philosophy; Was: Re: Draft Spec mark 2
by Kevin Thiele 02 Sep '00

02 Sep '00

| Bob Morris | | p.s. After about a year of hanging out with a variety of biologists, | I've come to think of the taxonomists as the of grammarians | and etymologists (not /entomologists/) of Life: Another way of looking at it: It's quite possible that the ability to construct (determine?) the etymology of Life is the best definer for the human condition - tool-using is no good, language is no good, even logic is no good, because animals do all these things. But there's no indication that a chimpanzee in a forest has a TAXONOMY of the forest (though they may have representations and tags in their minds for things that are good to eat, something quite different). If this is correct, then perhaps taxonomists are the highest form of organic life. |Taxonomists, God bless 'em. You can't live with 'em and you can't |live without 'em.

1 0

Re: Draft Spec mark 2
by Jim Croft 01 Sep '00

01 Sep '00

> >Plant descriptive data is much to complex to be captured in XML which is > >more geared towards presentation than representation. > >I'll second that. I use LaTeX, and previously used a precursor to SGML, >to typeset all my printed documents. These *typesetting* languages are >great for defining the appearance of the content of documents, but they >are utterly inadequate for representing the content (ie., data) itself. This is not my understanding at all... I thought the theory behind XML was to describe content, structure and relationships of data elements, quite independently of presentation as with typesetting languages... Having defined an issue with XML, or similar, you can present it however you want... Having defined an issue with a typesetting language, all you can do is typeset it... jim

1 0

Re: Draft Spec mark 2
by Eric Zurcher 01 Sep '00

01 Sep '00

Kevin has offered us not just 1, but 4, different document models for comment. That's a lot to consider, and I won't attempt to offer detailed criticism on each alternative. But from my point of view, the first several appear far too "weak" to be of much use. In particular, I think it is essential that there be a mechanism for specifying a universe of the character and state values (or, mapping roughly from Kevin's terminology, "elements" and "values", respectively) which may appear within a description. That is, we need to be able to define (or, rather, provide a mechanism for the dataset designer to define) the equivalent of a DELTA "character list". This is needed to enforce consistency and to disallow nonsensical constructs. For example, a portion of Document 1 reads: <STATEMENT> <ITEM> <ITEM_NAME> Gouania exilis </ITEM NAME> </ITEM> <ELEMENT> <ELEMENT_NAME> Flower colour </ELEMENT_NAME> </ELEMENT> <VALUE> green </VALUE> <QUALIFIER> rarely </QUALIFIER> </STATEMENT> There needs to be a way to preclude a nonsensical entry like: <STATEMENT> <ITEM> <ITEM_NAME> Gouania exilis </ITEM NAME> </ITEM> <ELEMENT> <ELEMENT_NAME> Flour colur </ELEMENT_NAME> </ELEMENT> <VALUE> Puerto Rico </VALUE> <QUALIFIER> anchovies, please! </QUALIFIER> </STATEMENT> I might also note that I strongly question the way the above is organized. I think a rearrangement better expressing the relationships (but still not really addressing the problem of a lack of meaningful validation) would be more along the lines of: <ITEM> <ITEM_NAME> Gouania exilis </ITEM NAME> <ELEMENT> <ELEMENT_NAME> Flower colour </ELEMENT_NAME> <VALUE> green <QUALIFIER> rarely </QUALIFIER> </VALUE> </ELEMENT> </ITEM> And I'd be inclined to make a bit more use of attributes, rather than element content, though as Bob Morris points out, that is largely (though not entirely) a matter of stylistic convention. I don't really see any great difficulties is implementing some sort of "character list" within the XML syntax. "Document 4" appears to be heading in that direction, but doesn't (in my opinion) go quite far enough. What I think we need is a Schema definition that would allow a validating parser to detect obvious data errors, and assist editing software in enforcing "correctness" of the data. I've recently been looking through the description of XML Schema, and it seems to have the expressive power needed for this sort of thing. Cheers, Eric Zurcher CSIRO Division of Entomology Canberra, Australia E-mail: ericz(a)ento.csiro.au

1 0

Re: Draft Spec mark 2
by Leigh Dodds 01 Sep '00

01 Sep '00

> -----Original Message----- > From: TDWG - Structure of Descriptive Data [mailto:TDWG-SDD@usobi.org]On > Behalf Of Una Smith > Sent: 01 September 2000 13:18 > To: TDWG-SDD(a)usobi.org > Subject: Re: Draft Spec mark 2 > > > On Fri, 1 Sep 2000, Erik Westlin wrote: > > >Plant descriptive data is much to complex to be captured in XML which is > >more geared towards presentation than representation. > > I'll second that. I use LaTeX, and previously used a precursor to SGML, > to typeset all my printed documents. These *typesetting* languages are > great for defining the appearance of the content of documents, but they > are utterly inadequate for representing the content (ie., data) itself. XML is *not* a typesetting language. Its a meta-language for defining other languages, just as SGML was. It is *not* limited to describing documents, and its far from being a limited to describing layout. My own doodlings with XML and Taxonomic data [1] shows that the DELTA format can be expressed as XML without loss of information. Its probably too early to get mired in syntax discussions - at present it may be better to assume that all examples merely that - not formal proposals for how the serialised data should look. The model is the important issue at the moment. Once that is nearing completion, decisions on a serialisation syntax (XML or something else) can then be made in highlight of concrete examples and data. Personally speaking, I'd be surprised if there were aspects of a taxonomic data model which *couldn't* be adequately expressed in XML. At most I'd expect there to be some contortions in the syntax, rather than a complete inability to represent the data. The question is then, how much does the syntactic 'sugar' outweigh the network effect of embracing a standard like XML. My 2p. [1]. http://www.ldodds.com/delta/index.html L. -- Leigh Dodds, Systems Architect | "Pluralitas non est ponenda http://weblogs.userland.com/eclectic | sine necessitate" http://www.xml.com/pub/xmldeviant | -- William of Ockham

1 0

Re: Draft Spec mark 2
by Robert A. (Bob) Morris 01 Sep '00

01 Sep '00

If you care about the intricacies of the difference between programming languages and markup languages for document and data reprepresentation, see the ironically named "The Origin of (Document) Species", by Khare et al. at http://www.cs.caltech.edu/~adam/papers/www/origin-of-species.html Despite being one of the perpetrators, I'd observe we are wondering of the TDWG charter a little here....

1 0

Re: Draft Spec mark 2
by Una Smith 01 Sep '00

01 Sep '00

Una Smith wrote: >>I'll second that. I use LaTeX, and previously used a precursor to SGML, >>to typeset all my printed documents. These *typesetting* languages are >>great for defining the appearance of the content of documents, but they >>are utterly inadequate for representing the content (ie., data) itself. Jim Croft wrote: >This is not my understanding at all... > >I thought the theory behind XML was to describe content, structure and >relationships of data elements, quite independently of presentation as with >typesetting languages... > >Having defined an issue with XML, or similar, you can present it however >you want... > >Having defined an issue with a typesetting language, all you can do is >typeset it... Jim, I think your definition of a typesetting language is not the same as mine. If by "typesetting language" you mean RTF, then I would agree with you that XML is not a typesetting language. But I don't consider RTF to be a typesetting language because it cannot (to my knowledge) be used to write other languages. That's the important difference between RTF and XML (and LaTeX). LaTeX is a language that was designed for typesetting, and it is good at it: typesetting is relatively painless, using LaTeX. LaTeX can be (and has been) used to write simple text-based user interfaces, and to write new programs (yes, you can write LaTeX programs to write LaTeX programs, ad infinitum; you could also write LaTeX programs to write C programs, and vice versa). These other uses of LaTeX are quite contorted, though; such programs are not pleasant to write. GML was a markup language, like RTF; SGML and its derivatives, including XML, are (as I see it) typesetting languages. Sure, if we all agree with Leigh Dodd that we are just using XML for the convenience of it (though I don't personally find XML convenient), that's okay. But the discussion here keeps slipping into implementation issues and forgetting about the underlying abstractions. We could conduct this discussion in PERL code too. (Hey, why not?) Why not forget the codes (or pseudo codes) and use ordinary words that we all understand? *Then* decide which language (if any) to implement it in, *after* we all agree what "it" is. Una Smith una.smith(a)yale.edu Department of Ecology and Evolutionary Biology Yale University New Haven, CT 06520-8106

1 0

Re: Draft Spec mark 2
by Erik Westlin 01 Sep '00

01 Sep '00

Eric Zurcher wrote: > In my mind it's totally wrong to create a language for descriptions using XML. Instead create a dedicated language for descriptions - then construct a XML generator for this language if you like. I'm in computer science, my interrest in botany is just a small part time hobby But i hate to see a lot of energy go to waste and i would like to see a computer flora whith a deep knowledge i could interact with. I think you should consult some people in the knowledge representation field. Plant descriptive data is much to complex to be captured in XML which is more geared towards presentation than representation. ------------------------------------------------------------------------ Erik Westlin Manne Siegbahn Laboratory email: westlin(a)msi.se

1 0

Philosophy; Was: Re: Draft Spec mark 2
by Robert A. (Bob) Morris 01 Sep '00

01 Sep '00

<RAMBLING_PHILOSOPHY flame="occasionally" biology="rarely"> Erik Westlin writes: > In my mind it's totally wrong to create a language for descriptions > using XML. > Instead create a dedicated language for descriptions - then > construct a XML generator for this language if you like. One would do this only if one decided that XML and its associated languages did not have enough expressive power to solve the problem at hand. If it does, not using it is to abandon LOTS of existing tools for parsing, transformation, presentation, data exchange and data entry. > I'm in computer science, my interrest in botany is just a small part > time hobby > But i hate to see a lot of energy go to waste and i would like to see > a computer flora whith a deep knowledge i could interact with. This is a good goal for system architects, but I doubt that treatment representation will be the enabling technology for it. Rather only it must not preclude it. What taxonomists mean by a treatment is too narrow to be the sole support for what non-taxonomists, especially non-biologists, need from computer systems about organisms. Treatment data is only part of the knowledge that an author of, say, a field guide, must represent in the guide, or that is needed by projects as ambitious as the Global Biodiversity Information Facility (www.gbif.org), or many of the numerous efforts with intersecting goals (http://www.gbif.org/relafram.htm). Here's an example that can not(?) be represented in what Kevin is attempting, nor does it belong there: Some years ago on a rural road in upstate New York, I passed a litter of fox cubs who---at the likely cost of their own lives---would not leave their mother as she lay dying in the middle of the road, obviously hit by a car. There is a lot of important behavioral and ecological information encompassed in that scene: the age of the cubs; the rearing habits of the species; the impact of roads on populations; etc. etc. None of this matters to a taxonomist (well, maybe a little. Probably one can deduce from the behavior that foxes are mammals). Kevin's effort, and TDWG's charter, is foremost about data in the service of knowledge, rather than knowledge in the service of users. As such, his effort supports the system builders, especially those with a desire to exchange or federate data or (one hopes) to build extensible systems. > I think you should consult some people in the knowledge representation > field. <FLAME level="extreme" offense_intended="none"> This is the last thing one would do if one believes---as I do---that computer scientists should be building tools that /free/ biologists from computer science specialists rather than indenture biologists to computer scientists. Were it truly necessary, it would be analogous to advice to consult with automotive engineers, physicists and organic chemists before you buy a car. </FLAME> > Plant descriptive data is much to complex to be captured in XML which is I don't believe this. XML in particular and semi-structured data in general can support schema inference (See especially the literature referenced in "Data on the Web : From Relations to Semistructured Data and Xml" (Morgan Kaufmann Series in Data Management Systems) -- Serge Abiteboul, et al; 2000). This alone probably disproves your claim. > more geared towards presentation than representation. Ummm.... unless these terms mean something different in the Knowledge Representation field than in the Document Management field, this is the opposite of what most people believe: "Markup encodes a description of the document's storage layout and logical structure. XML provides a mechanism to impose constraints on the storage layout and logical structure." Sec. 1(Origin and Goals) of the XML1.0 Recommendation http://www.w3.org/TR/REC-xml#sec-origin-goals So much is the desire to separate presentation that only a small part of XSL, the XML Style Sheet language, addresses it (Section 6, "Formatting Objects", http://www.w3.org/TR/xsl/slice6.html#fo-section) In general, neither Kevin's goals nor XML impose any presentation or other semantics at all. That's good, because it leaves knowledge representation to the application builder---who one hopes has lots of help from biologists, all of whom are smarter than software. </RAMBLING_PHILOSPHY> Bob Morris p.s. After about a year of hanging out with a variety of biologists, I've come to think of the taxonomists the of grammarians and etymologists (not /entomologists/) of Life: "etymology n., pl. The origin and historical development of a linguistic form as shown by determining its basic elements, earliest known use, and changes in form and meaning, tracing its transmission from one language to another, identifying its cognates in other languages, and reconstructing its ancestral form where possible."[1] Taxonomists, God bless 'em. You can't live with 'em and you can't live without 'em. [1] The American Heritage. Dictionary of the English Language, Third Edition 1996, as cited after ALT-Click with software installed from from guruNet. This software is incredibly cool. It gives you information about any word in /any/ application on your Windows or Palm screen. See http://www.gurunet.com.

1 0

Draft Spec mark 2
by Kevin Thiele 01 Sep '00

01 Sep '00

Gentle list'eners Attached find another attempt at formulating a draft specification for discussion. I've reworked this from scratch rather than try to modify Mark 1 -following Bryan Heidorn's comments, I've realised that my attempt Mark 1 wasn't going very far (the first three elements, Version ID, date and name all caused problems!). I've tried in this to get to the basics of the structure of a description and work up from there. Before I go any further, can people look at this and tell me whether it looks promising or not. Obviously there's still much work to do. Cheers - k I've attached Word documents, a text and html copy of the main word document, and jpegs of the diagrams. Hope everyone can read at least some of these.

1 0