February 2000 - tdwg-content

Re: SDD Specifications Document
by Eric Zurcher 24 Feb '00

24 Feb '00

At 16:02 23/02/2000 +1100, Kevin Thiele wrote: >Dear list_eners > >attached find SDDspecs.rtf. This is my attempt to formalise the discussion >so far into a set of specifications for a new descriptive data standard. > and requested comments his proposal. I've not had time to think this through in detail, but I'd nonetheless like to offer a few scattered observations. 1) One "pattern" that recurs in the document in the use of "attachments" to entities. These consist of a name, type, path, public notes, and private notes. Presumably one could define some sort of generic "attachment" object and avoid the multiple (4) redefinitions currently given in the outline. This would shorten the outline appreciably. 2) ID numbers crop up in a number of places. But it's not obvious how "unique" these various IDs need to be. For example, must character IDs be unique only with the context of the set of all character IDs, or of all IDs used anywhere within the treatment? Or perhaps they are intended be used across treatments (to facilitate merging, etc.), and must be unique (but consistent) in an even broader sense? (But perhaps this is an area this is best left deliberately ambiguous for now.) 3) Character (and taxon) sets - these should probably be defined hierarchically, so that sets would be able contain other sets, as well as the base elements (characters or taxa). Note that there seems to be another "up vs. down" problem here - is it better to define a set by listing the members within it, or for the each of the members to list the sets to which it belongs? 4) I'm rather confused by footnote 3, regarding the nesting of character names, and the restriction of "properties" to only the lowest level. What it the reason for this restriction? But certainly there seems to be merit in separating the "properties" of a character from it's textual representation. This is almost essential when attempting to generate natural-language descriptions in multiple languages. Similarly, different wordings may be appropriate in different application contexts (natural-language vs. interactive keys vs. conventional keys, or keys of the layman vs. the specialist). 5) This draft allows for a "score" only within the context of a "state name". It is not obvious how characters with non-discrete values (e.g. numeric values) would be handled. 6) I'm intrigued by the notion of a "Progressive Revelation model" (footnote 5). It sounds terribly theological - or perhaps that's Thiele-logical? (my apologies to Kevin, but I really can't resist bad puns). 7) For purposes of natural-language generation (and perhaps other applications), it is desirable to have some sort of "connection operator" between states within a character (e.g., "flowers blue or violet" vs. "flowers blue and violet" vs. "flowers blue to violet" all carry slightly different meanings). This and other requirements of generating natural-language descriptions might be an argument for generally preferring a "characters within taxa" representation to "taxa within characters". Cheers, Eric Zurcher CSIRO Division of Entomology Canberra, Australia E-mail: ericz(a)ento.csiro.au

1 0

Re: <XML> Abstract Data Model for Taxonomy
by Jean-Marc Vanel 24 Feb '00

24 Feb '00

Leigh Dodds a écrit : > 1. Firstly is it possible to express items like > "Feature often present by mis-identification" Sorry, my english is too weak. Does this mean a character value that is often reported by confusion with another taxon ? > I note you've already highlighted seasonal variations as a problem. My solution: the default for a Property is to record the state for: - middle of active season - adult specimen Otherwise, create a new Property. Note that beside the specified sub-elements of tax:Property (appliesTo, appliesToClasses, name), it is possible to add extra information like, say, <bio:season>spring</bio:season>. This is a property (rdf:Property) about a property (tax:Property). > To that I'd add geographical, My (simple) solution: if anything is different in some region, create a lower level tax:TaxonomicClass, containing just the differing Features; according to model, other Features will be inherited. > 2. It seems to presuppose a Linnean viewpoint i.e. Kingdom, > Phylum, etc. I didn't write that, in fact this model is so generic that it could almost be applied to car models! > Gregor has previously pointed out that the > reality is much more complex. Multiple hierarchies > can be produced. For example, how would the model be used to express > DNA/Protein data? Physiological versus Molecular hierarchies? And belonging to phytosociological associations, also. Although I didn't think of that, this is no problem. You just have to publish on the Web a Schema with, say, a ProteinClass and a ProteinSubClass, declaring that both are rdfs:subClassOf of tax:TaxonomicClass, and connecting them using tax:lowerClasses and tax:upperClass, etc. And hoping that many will connect to your Schema... Well, this is the freedom of the Web, but I hope that a standard will be found. But I wanted to show that extendibility is perfectly possible, with the possibility that the new semantic is declared as such, so that tools can understand the new semantic. > 3. I assume that the list of Feature/Properties will not be > fixed, but can be extended at will? Yes > However I'm concerned that the presence of items like 'TaxonomicClass' in > the model doesn't > capture the range of flexibility that Kevin, Gregor and the others > have stated as a requirement. Is this requirement like the Molecular hierarchies, or something else ? Cheers Jean-Marc -- <person> <first_name>Jean-Marc</first_name> <name>Vanel</name> <project>Worlwide Botanical Knowledge Base - making botany available on Internet <a href="http://wwbota.free.fr/" >site</a> </project> <homePage>http://jmvanel.free.fr/</homePage> <a href="mailto:jmvanel@free.fr">mail (eventually put "wwbota" in subject to route your mail in relevant folder)</a> </person>

1 0

Re: <XML> Abstract Data Model for Taxonomy
by Leigh Dodds 24 Feb '00

24 Feb '00

Hi, > The spring is coming, the crocuses are in bloom, it's time to come up > with a formal model. Some questions: 1. Firstly is it possible to express items like "Feature often present by mis-identification" (I came across this somewhere, but can't recall the posting/webpage) I note you've already highlighted seasonal variations as a problem. To that I'd add geographical, and developmental (i.e. age of item). 2. It seems to presuppose a Linnean viewpoint i.e. Kingdom, Phylum, etc. Gregor has previously pointed out that the reality is much more complex. Multiple hierarchies can be produced. For example, how would the model be used to express DNA/Protein data? Physiological versus Molecular hierarchies? [See (RQT) Character and item hierarchy from Gregor posted on 1/12/99 - I'd include a URL, but the ListServ archive seems to require a username/password] 3. I assume that the list of Feature/Properties will not be fixed, but can be extended at will? Apologies if this seems overly critical, I'm just trying to get my head around things. Fundamentally I think that an RDF (or even Groves) model of the data will be extremely useful. However I'm concerned that the presence of items like 'TaxonomicClass' in the model doesn't capture the range of flexibility that Kevin, Gregor and the others have stated as a requirement. I'd welcome some further discussion/information of your model. Cheers, L.

1 0

<XML> Abstract Data Model for Taxonomy
by Jean-Marc Vanel 24 Feb '00

24 Feb '00

Hello dear group The spring is coming, the crocuses are in bloom, it's time to come up with a formal model. Look at http://wwbota.free.fr/UML_diagrams.htm -- <person> <first_name>Jean-Marc</first_name> <name>Vanel</name> <project>Worlwide Botanical Knowledge Base - making botany available on Internet <a href="http://wwbota.free.fr/" >site</a> </project> <a href="mailto:jmvanel@free.fr">mail (eventually put "wwbota" in subject to route your mail in relevant folder)</a> </person>

1 0

Re: SDD Specifications Document
by Jean-Marc Vanel 24 Feb '00

24 Feb '00

Dear contributors It's good to see a new debate begining! Undefined terms in SDD Specifications Document: * "Progressive Revelation model" * Treatment * score It seems that this Specification mixes data and Specification of processing to be done on this data by an application. Processing is a very interesting subject (see transforms), but good design is layered design, and processing seems an upper and distinct layer. Eric Zurcher a écrit : > 1) One "pattern" that recurs in the document in the use of "attachments" to > entities. .... > 2) ID numbers crop up in a number of places. But it's not obvious how > "unique" these various IDs need to be. I agree. > some sort of "connection operator" > between states within a character (e.g., "flowers blue or violet" vs. > "flowers blue and violet" vs. "flowers blue to violet" "flowers blue and violet" will have to be covered by my proposed "Abstract Data Model for Taxonomy". <person> <first_name>Jean-Marc</first_name> <name>Vanel</name> <project>Worlwide Botanical Knowledge Base - making botany available on Internet <a href="http://wwbota.free.fr/" >site</a> </project> <a href="mailto:jmvanel@free.fr">mail (eventually put "wwbota" in subject to route your mail in relevant folder)</a> </person>

1 0

Re: SDD Specifications Document
by Jean-Marc Vanel 24 Feb '00

24 Feb '00

Bob Morris a écrit : > (a).On theoretical and practical grounds, DTD's > are now understood to be a weak way to describe the schemata > > (b). Mixed content (a mixture of text and elements) is a really > bad idea, Yes and yes; DTD is an old technology from SGML, if we want a standard for at least 10 years, it's better to avoid it. -- <person> <first_name>Jean-Marc</first_name> <name>Vanel</name> <project>Worlwide Botanical Knowledge Base - making botany available on Internet <a href="http://wwbota.free.fr/" >site</a> </project> <a href="mailto:jmvanel@free.fr">mail (eventually put "wwbota" in subject to route your mail in relevant folder)</a> </person>

1 0

Re: SDD Specifications Document
by Leigh Dodds 24 Feb '00

24 Feb '00

> (a).On theoretical and practical grounds, DTD's > are now understood to be a weak way to describe the schemata > (small 'S') of XML documents. The specialists should argue > about whether RDF or XML-Schema's (uppercase 'S') work > better (or try each on for size) and if there is a compelling > reason to have a DTD then derive one from the Schema. I agree, and will use the W3C XML-Schema syntax to produce an XML interpretation of Kevins document. I'll refrain from using any complicated Schema features so at to not detract from the core discussion. The debate in the developer community concerning Schemas is currently something of a hot topic [1]. I hope to be able to present something shortly. Cheers, L. [1]. http://www.xml.com/pub/2000/02/23/xmldeviant/index.html

1 0

Re: SDD Specifications Document
by Leigh Dodds 24 Feb '00

24 Feb '00

Hi, Just to respond to the following mentioned by Bob: > (b). Mixed content (a mixture of text and elements) is a really > bad idea, as is well known in the SGML community. Our own > limited experience has been that dealing with it in display code > necessitates to code obscurely. I can't tell whether anything > in the proposal would lead this way. Maybe some pseudo-code > XML-like examples would enlighten. Mixed content can certainly be difficult to manage, although people are using it on a daily basis when they write HTML, so it can't all be bad! Seriously though, I had been thinking that the 'notes' and other free text sections in the format would use XHTML derived tags to describe its presentation. Perhaps its worth exploring this further. Firstly, for non-markup people. Mixed content is markup which contains free text interspersed with additional tags. e.g. <notes>This is mixed content</notes> An (trivial) example using XDELTA syntax: <character number="2"> <description>main colour of inner part of front wing</description> <image num="2" mime="image/jpeg" href="lepc02.jpg" /> <multi type="unordered"> ...states removed... </multi> <notes>I should stress here that there may be other wings colours yet to be determined</notes> </character> Where denotes emphasised text. This facilitates the production of a nicely formatted display, at least for HTML. An alternative which removes mixed content (I'll just reproduce the notes tag for clarity: <notes> <text>I should stress here that there </text> may be <text>other wings colours yet to be determined</text> </notes> I believe this is less readable, and involves more markup effort from the user. Of course I might be barking up the wrong tree, and this kind of markup isn't a requirement. The issue is related to how the textual content in the data is to be presented to the user, and isn't something we've explored yet. The main problem with mixed content is it makes life difficult for parser and tool writers. It does make some things easier for the user, like readability. Cheers, L.

1 0

Re: <XML> Abstract Data Model for Taxonomy
by Noel Cross 24 Feb '00

24 Feb '00

On Thu, 24 Feb 2000, Jean-Marc Vanel wrote: > > > 2. It seems to presuppose a Linnean viewpoint i.e. Kingdom, > > Phylum, etc. > > I didn't write that, in fact this model is so generic that it could almost > be applied to car models! > This is puzzling. In that case why would a TaxonomicClass need to have a member named "botanicalAuthor" as in your UML diagram? -Noel

1 0

SDD Specifications Document
by Kevin Thiele 23 Feb '00

23 Feb '00

Dear list_eners attached find SDDspecs.rtf. This is my attempt to formalise the discussion so far into a set of specifications for a new descriptive data standard. Leigh has explained that his XDELTA is a first-cut approach to such a standard, done more to show what's possible than as a serious suggestion for a final cut. He has offered to revisit and rework "XDELTA" in light of the list's discussions. To make his job easier, I think it wold be a good idea for those of us still out there to work up a structured specification document for Leigh to work his magic on. If it works OK, the attached may be the first step to this specification. Again, this is a first cut. It incorporates my ideas, and those I've been able to trawl from the list that have made sense to me. I may have got things all wrong, and it will almost certainly not be exhaustive, but I think at this stage it's better for the authors of other ideas to work on this directly rather than for me to try to understand what they were saying. I hope the document's self-explanatory - if not, ask me to explain. Any suggestions as to the best way to work up the document? If we all edit bits and repost we'll end up with diverging versions. Anyway, see if this makes sense to you. Cheers - k

1 0