November 2000 - tdwg-content

Re: Delta-like descriptions for Thiele 0.3 draft
by Robert A. (Bob) Morris 07 Nov '00

07 Nov '00

Kevin Thiele writes: > Date: Tue, 7 Nov 2000 22:14:33 +1100 > Bob Morris wrote: > > | II. Global feature values (This may be a Delta question). > | > | In 0.3's Examples 8 and 9 there do not seem to be any global feature > | values. Instead, all possible values are completely local to > | features. For example, can there be a list of feature values > | containing both "present" and "absent" to which any feature can refer, > | whether or not those values are in that feature's local list of > | values? Or rather, must every feature that wishes to allow those > | values name them in its list of possible values> > Kevin replied > I think all values should be specifically named. It would be silly to have a > global "present", then have a feature "Flower colour" that allows this > feature value. > Bob writes: Having global named values doesn't imply that an application *must* use them, only that it *may* use them. Also, this is one of those places where having a schema (= DTD or X Schema) can help because it is possible to define the schema in such a way that 'Flower colour present' would be prohibited. In this case a validating XML parser would signal exactly where the "error" lies, in case you care. But even better, an application that was built to the schema but did not enforce the schema would just ignore the silly statement.

1 0

Re: TDWG-SDD XML proposals of Kevin Thiele
by Jim Croft 07 Nov '00

07 Nov '00

Leszeck wrote: >What is referred to as "species" value="alfari"/ is actually the specific >epithet. The "species" value in this instance would actually be "Azteca >alfari" You're probably familiar with this protocol of referring to the >scientific name of an organism which implies citing the genus name & the >specific epithet which together comprise the species names - as per the >Linnean system of binomial nomenclature. Should I have the 'wrong end of the >stick' of the discourse at this stage then please advise me. Isn't this merely a matter of how we look at things and the insoluble legacy of the Linnean system? Conceptually one of way of dealing dealing with things is to consider we are dealing with taxa, <taxon>, and that each taxon has a <name/>, <rank/> and a context or parentage <parent/> which happens to be another <taxon> at a higher <rank>. Computers do not have any trouble with such a model and can build wonderful and tidy tree-like hierarchies. However, to make the thing humanly intelligible for the purposes of communication, Names below the genus have to be specified with their context because the same name are allowed in different genera. Conceptually the species can be thought of as the thing - the taxon at the rank of species. it handle if the combination of its name and its context: genus name plus species epithet, as you describe. We could always use an name in connection and sometimes do, e.g. Blechnaceae: Woodwardia, or Woodwardia (Blechnaceae), but mostly above the level of genus we do not bother, maybe because people can remember where a smaller number of things fit. But there are undoubtedly equally valid ways of modelling species and their names... jim

1 0

Re: TDWG-SDD XML proposals of Kevin Thiele
by Robert A. (Bob) Morris 06 Nov '00

06 Nov '00

Steve Shattuck writes: > <soap_box_on> and that's partly why > this discussion has drawn out for sooooo long - the BioLink team built a > complete XML representation of the BioLink database, some 400 fields in 50 > tables, in 3 weeks and are now using it to move data between BioLink > databases and between Platypus and BioLink - and, surprise surprise, we > don't have a DTD or Schema because you don't actually need one to make this > stuff work <soap_box_off/>). [Hey Steve, my soapbox is bigger than your soapbox... :-) ] I reply: Absolutely right. However, you almost never will see a need for a Schema (or DTD) when you have a single data model and your applications know it, as in the case you describe. If on the other hand, you want to combine data from multiple data sources, you have an advantage if there is a schema (small 's', meaning either an XML Schema or a DTD). You can always infer a schema from an instance of XML, (see Michael Kay's DTD generator at http://users.iclway.co.uk/mhkay/saxon/saxon5-5-1/dtdgen.html), but if you have an instance that isn't general, you'll get a schema that isn't general. In addition, if you are trying to write an application that manipulates the node tree represented by an application, you also have an advantage having a schema or otherwise knowing the data model. I'll be startled if you wrote your exchange program with no knowledge of the data model. The fact that such a program works independently of a schema is part of the requirements of XML, but this says nothing about what aid such a schema can offer either in writing applications, or more interestingly, in generating applications. For those in the camp that believe in publishing static XML---and there are a lot of them---having a schema also is a big win for using markup editors like XMLSpy. With a schema, these offer you only valid tags at every point. Writing an application that is assured of working against validated XML will often result in more robust applications because they will not miss XML elements that are in the "wrong" place. Validating against an XML Schema provides strong data typing and so can help detect data errors. Finally, XML Schema provides robust inheritance mechanisms. Consequently if people derive a Schema from some series of base Schemas, they automatically gain the use of applications written against the base, even if they do nothing interesting to their extensions. In my opinion, this reusability is highly valuable. --Bob (Soapy) Morris p.s. I'd be interested to see what Kay's DTD generator gives against your XML.

1 0

Re: TDWG-SDD XML proposals of Kevin Thiele
by Robert A. (Bob) Morris 06 Nov '00

06 Nov '00

Jim Croft writes: > Date: Tue, 7 Nov 2000 08:16:11 +1100 > Leszeck wrote: > >What is referred to as "species" value="alfari"/ is actually the specific > >epithet. The "species" value in this instance would actually be "Azteca > >alfari" You're probably familiar with this protocol of referring to the > >scientific name of an organism which implies citing the genus name & the > >specific epithet which together comprise the species names - as per the > >Linnean system of binomial nomenclature. Should I have the 'wrong end of the > >stick' of the discourse at this stage then please advise me. > Jim Croft replied > ... > Computers do not have any trouble with such a model and can build wonderful > and tidy tree-like hierarchies. The truth is that we secretly conceptualize nodes in such trees as the full path from the root of the tree. Hence to us the <speciesName> object is the full taxonomy. However, it is quite easy in any of the languages with which one might process XML to turn one form into the other. We didn't intend to propose that markup as a standard. In each biological community, the biologists will set a standard if they can't live with one some other community has already made. And we computer scientists get to clean up the mess. :-) Whether or not this is a good example, it is widely understood that you can't force a single standard on a group just because they seem to have common interests. Biologists seem to be an ornery lot. If they don't like something they go do it a new way. Which often actually tends to advance matters! Bob

1 0

Delta-like descriptions for Thiele 0.3 draft
by Robert A. (Bob) Morris 06 Nov '00

06 Nov '00

Ah, Jun Wan reminds me that uniqueness of ID attribute values is imposed by XML itself. So in the Delta-like descriptions, the choices I see are to generate unique ID's that encode the context or to use a different attribute than ID, perhaps something like TDWGID. In the former case one might have something like: ID="F.1" to mean that this is an id for feature 1 ID="F.V.1.2" to mean that this is value 2 for feature 1 In XSLT, these are parseable with the XPath string functions, so that nothing more than XSLT is needed to associate an IDREF with the object having the associated ID. If the main issue is conversion back and forth between DELTA and a more XMLish tree-based representation, or generating from a database, the complexity of such ID's is insignificant, because they are easily managed programattically. However, if people actually *like* a list-like format, and intend to markup XML by hand, then managing id's may be more of a nuisance. Robert A. (Bob) Morris writes: > Date: Mon, 6 Nov 2000 11:49:40 -0500 > From: "Robert A. (Bob) Morris" <ram(a)cs.umb.edu> > To: TDWG-SDD(a)usobi.org > Subject: Delta-like descriptions for Thiele 0.3 draft > > > III. Unique ID's (Non XML hackers please avert your eyes). We can not > see where XML-Schema Schema syntactically enforces uniqueness of > ID's. If this is so, ID uniqueness must either be ignored, enforced by > context, or enforced by semantics at processing time. For example, in > draft 0.3, several objects have id="1". The XPath function library is > strong enough to use an ID as key when its uniqueness is given only by > context as in Examples 8 and 9 in draft 0.3, but if we accept this > approach, will we end up with a Schema against which validity testing > is hard? OTOH, if we are wrong and XML-Schema Schema does enforce > global uniqueness of ID, then must we uniqify the proposal by encoding > the context in the ID itself? That seems fragile. >

1 0

Re: TDWG-SDD XML proposals of Kevin Thiele
by Vincent, Leszek 06 Nov '00

06 Nov '00

Dear TDWG folk - I sent the following note to Bob Morris but have since thought that maybe I should have sent it to the whole list. So here it is. ----------------------- Dear Bob Something in the mail below caught my eye & I thought I should mention it lest something at the foundation level be incorporated which is incorrect. What I'm referring to is just below a row of *******'s below and copied here: > > <taxonomy> > > <rank="species" value="alfari"/> > > <rank="genus" value="Azteca"/> > > <author value="Emery"/> What is referred to as "species" value="alfari"/ is actually the specific epithet. The "species" value in this instance would actually be "Azteca alfari" You're probably familiar with this protocol of referring to the scientific name of an organism which implies citing the genus name & the specific epithet which together comprise the species names - as per the Linnean system of binomial nomenclature. Should I have the 'wrong end of the stick' of the discourse at this stage then please advise me. Sincerely, - Leszek Vincent xoxoxoxoxoxoxoxoxoxoxoxoxoxoxox P. Leszek D. Vincent Ph.D., FLS Plant Science Unit, Dept. of Agronomy, 209 Curtis Hall, University of Missouri-Columbia, Columbia, MO 65211-7020, USA. Ph: (573) 884-3716 (Agronomy), Fax:(573) 884-7850; Ph/Fax (Home): (573) 441-1228; Email: Leszek(a)missouri.edu Plant Systematist on the Missouri Maize Project - NSF award 9872655 - (http://www.cafnr.missouri.edu/mmp/ and http://www.agron.missouri.edu/) xoxoxoxoxoxoxoxoxoxoxoxoxoxoxox ----------------------------------------------------- > -----Original Message----- > From: Robert A. (Bob) Morris [mailto:ram@CS.UMB.EDU] > Sent: Monday, October 30, 2000 12:20 PM > To: TDWG-SDD(a)USOBI.ORG > Subject: Re: TDWG-SDD XML proposals of Kevin Thiele > > > Jim Croft writes: > > Date: Mon, 30 Oct 2000 23:57:44 +1100 > > From: Jim Croft <jrc(a)anbg.gov.au> > > To: TDWG-SDD(a)usobi.org > > Subject: Re: TDWG-SDD XML proposals of Kevin Thiele > > > > >The material at > > >http://www.cs.umb.edu/efg/ThieleDraft/thiele_0_3.html > illustrates our > > >efforts to draft an XML Schema from Thiele's draft > proposal version > > >0.3 ("TDD0.3") and illustrate its utility with simple > > >applications manipulating a taxonomic treatment. > > > > No-one seems to be commenting on this, at least on the > list... is it all > > too scary? With Halloween just around the corner, do > these guys deserve to > > be tricked or treated? > > > > Unless people are commenting directly to Kevin/Bob/Jun, I > would imagine > > they would be feeling pretty disappointed so far... > > > > I have been through this a number of times, still trying > to come to grips > > with the various options that have been used from the > draft specs of a few > > weeks ago... and why... > > > > This is a great attempt at implementation and surely > demonstrates that we > > are on the right track... doesn't it? > > > > Yes, the format does seem a bit verbose, but from what I > gather Bob and Jun > > are saying, let the software, applications and databases > worry about that... > > > > Personally I prefer something like: > > ************** > > <taxonomy> > > <rank="species" value="alfari"/> > > <rank="genus" value="Azteca"/> > > <author value="Emery"/> > > <year value="1893"/> > > </taxonomy> > > > > to something like: > > > > <DESCRIPTION name="Taxonomic Information"> > > <FEATURE name="Species Name"> > > <FEATURE_VALUE>alfari</FEATURE_VALUE> > > </FEATURE> > > <FEATURE name="Genus Name"> > > <FEATURE_VALUE>Azteca</FEATURE_VALUE> > > </FEATURE> > > <FEATURE name="Namer"> > > <FEATURE_VALUE>Emery</FEATURE_VALUE> > > </FEATURE> > > <FEATURE name="Name Year"> > > <FEATURE_VALUE>1893</FEATURE_VALUE> > > </FEATURE> > > </DESCRIPTION> > > > > but if we never have to read it in this format, I do not > suppose it really > > matters... > > > > Anyway, it looks as though we are settling on an > architecture allows both > > discursive descriptions accommodated by 'narrative' > elements, and for the > > compulsive obsessives, a nested set of 'features' that can have > > 'feature_values', 'qualifers' and associated 'narrative'... Right? > > > > And that the competing architecture of a list of > 'feature_values' that can > > be present, absent, unknown, doubtful, present by > misinterpretation, absent > > by misinterpretation, imaginary, etc. has been given the flick? > > Not really. We believe that it is pretty straightforward to translate > between this kind of format and the one more spiritually akin to XML > and will illustrate that Real Soon Now. The biggest thing we need to > think about is exactly how the XML id reference mechanisms should be > used to implement things as in Kevin's examples. > > My own view is that there should actually be a single standard > representation with a bunch of ways to transform between it and other > desired representations. The advantage of this is that you need fewer > translators to go between representations A and B if everything has a > bidirectional representation with a common one, X. The disadvantage is > that you change X at the risk of breaking X<->A, thereby breaking > A<->B when neither A nor B changed. That said, I think that this issue > should not have lots of philosophical discussion until we, or somebody > else, demonstrates the conversion between list-like formats and > tree-like formats. > > > > > > Or having coded the data in this manner, is this > distinction in data > > representation employed by different interactive > identification products, > > not really relevant or meaningful? > > > > Sorry about the rambling - just trying to come to grips > with what has been > > done here... I am pretty sure it is good stuff once I > work out what it all > > means... > > > > One vague background concern I have is with things like: > > > > <FEATURE name="Page Author"> > > <FEATURE name="name"> > > <FEATURE_VALUE>John T. Longino</FEATURE_VALUE> > > </FEATURE> > > <FEATURE name="efg address"> > > <FEATURE_VALUE>The Evergreen State College, Olympia WA 98505 > > USA</FEATURE_VALUE> > > </FEATURE> > > <FEATURE name="email"> > > <FEATURE_VALUE>longinoj(a)elwha.evergreen.edu</FEATURE_VALUE> > > </FEATURE> > > </FEATURE> > > > > which seems on the surface to correspond to ye olde > library cataloguing > > metadata stuff. Is there a wheel here we do not need to reinvent? > > Absolutely. Per our remarks in the web page, we mainly did this out of > time constraints. For metadata, there is no doubt that the Dublin Core > and its extension the Darwin Core should be looked at. For > bibliographic things, the American Publishers Association has an SGML > DTD which is likely to be XML by now, etc. I'll write some references > to those for people to consider. > > > > > Related to this there are a number of projects around to > place using XML to > > mark up and display descriptive data and taxonomic > treatments and they seem > > to inventing rafts of 'feature' names for what appear to > be the same things > > in terms of blocks onf information. At the higher and > metadata level, is > > it too early to talk about rationalizing these? Being > very wary here, not > > wanting to open the Pandora's character-list box of worms again... > > Can we start assembling a list? > > > > > jim > > > > Bob Morris

1 0

New distribution of FloraParse
by Jean-Marc Vanel 06 Nov '00

06 Nov '00

Hello New distribution of FloraParse, a parser for classical Floras generating XML markup. See Release Notes: http://wwbota.free.fr/FloraParse-ReleaseNotes.txt Download FloraParse distribution : http://wwbota.free.fr/FloraParse-1_3.tgz -- <person> <firstName>Jean-Marc</firstName> <lastName>Vanel</LastName> <motto>Veni, vidi, convici</motto> <conference>9th International World Wide Web Conference - Amsterdam, May 15-19, 2000 <a href="http://www.www9.org/">site</a> </conference> <project>Worlwide Botanical Knowledge Base - making botany available on Internet <a href="http://wwbota.free.fr/" >site</a> </project> <a href="http://jmvanel.free.fr/>home page</a> <a href="mailto:jmvanel@free.fr">mail (possibly put "wwbota" in subject to route your mail in relevant folder)</a> </person>

1 0

Delta-like descriptions for Thiele 0.3 draft
by Robert A. (Bob) Morris 06 Nov '00

06 Nov '00

We have a better grasp now of the id mechanisms and are thinking along lines described briefly below. If any XMLers will be in Frankfurt, I'd like to talk more about these lines. I. A general question for comment We think that Kevin's example 9 the <DESCRIPTION> is really meant to be <DESCRIPTION ID = "1"> <FEATURE IDREF="1"> <VALUE IDREF="3"> <FEATURE IDREF="2"> <VALUE IDREF="1"> </DESCRIPTION> rather than <DESCRIPTION ID = "1"> <FEATURE ID="1"> <VALUE ID="3"> <FEATURE ID="2"> <VALUE ID="1"> </DESCRIPTION> as written. That is, the features and values are *references* to features given ID's in earlier elements. Thus in this case such a description is equivalent to <DESCRIPTION ID = "1"> <FEATURE NAME="Habit"> <FEATURE_VALUE>Herb</FEATURE_VALUE> </FEATURE> <FEATURE NAME="Stolons"> <FEATURE_VALUE>Present</FEATURE_VALUE> </FEATURE> </DESCRIPTION> II. Global feature values (This may be a Delta question). In 0.3's Examples 8 and 9 there do not seem to be any global feature values. Instead, all possible values are completely local to features. For example, can there be a list of feature values containing both "present" and "absent" to which any feature can refer, whether or not those values are in that feature's local list of values? Or rather, must every feature that wishes to allow those values name them in its list of possible values> III. Unique ID's (Non XML hackers please avert your eyes). We can not see where XML-Schema Schema syntactically enforces uniqueness of ID's. If this is so, ID uniqueness must either be ignored, enforced by context, or enforced by semantics at processing time. For example, in draft 0.3, several objects have id="1". The XPath function library is strong enough to use an ID as key when its uniqueness is given only by context as in Examples 8 and 9 in draft 0.3, but if we accept this approach, will we end up with a Schema against which validity testing is hard? OTOH, if we are wrong and XML-Schema Schema does enforce global uniqueness of ID, then must we uniqify the proposal by encoding the context in the ID itself? That seems fragile.

1 0

Re: TDWG-SDD XML proposals
by Kevin Thiele 02 Nov '00

02 Nov '00

Bob and Jim, surely the problem is that the "information" in a natural-language description and the "data" needed for e.g. an interactive key are not completely, and never will be completely, mappable. To try to make them fully mappable involves forcing a massively parallel supercomputer (the one sitting in front of the screen) to be content with the data potentials of an electronic calculator. | Workers: scapes and tibiae lack erect hair | | mapped as | | <FEATURE name="scapes and tibiae erect hair"> | <FEATURE_VALUE>lack</FEATURE_VALUE> | </FEATURE> | | reverse-mapped to: | | scapes and tibiae erect hair lack. makes me cringe. And this after all the shit heaped on taxonomists! :-) We gotta do a whole lot better than this. I'm sure we will. Cheers - k

1 0

Re: TDWG-SDD XML proposals
by Jim Croft 01 Nov '00

01 Nov '00

Bob wrote: >The >distinction we are presently thinking about is purely syntactic. It is >whether the XML data representation is tree structured (by a >non-linear tree) and without idref's or is linearly structured and with >idrefs. In fact all trees can be flattened into lists if by nothing >else than adding references to the mix. But this would seem to be to be a pretty important distinction and something that would have to be decided one way or the other in the Recommendation that we are going to come up with. Or are we thinking of a Recommendation that would allow both? It would be nice to be able to say, here is the one true path, wouldn't it? >It's easy to be convinced of >this: trees can be represented in the conventional linear memory >supplied with most computers, so it is clearly possible (and not that >hard). What we want to get right is not whether this can be >done---since we know it can---but specifically whether XML's reference >mechanisms will capture the requirements of the intended stakeholders >in the enterprise. We hope it does, because there is a BIG advantage >to using XML: there is an abundance of tools, protocols, databses and >services available to those who adopt it. Bob can you post an example of what a tree stucture represented linearly with idrefs _might_ look like? >For me, what is lurking under the covers here is this: I don't think >that high quality human readability of the naked markup is that >important. I think it is the job of application software to render >markup palatable to humans if that is the problem, or to other >software if that is the problem. At the end of the day we unfortunately have to deal with humans, and taxonomic humans which are even worse, so readability of final output is going to be a *major* issue. The data will need to be in a form that appropriate tools can transmute into something as close to natural language as possible. Otherwise the punters will walk away... >We extracted "highly" and "maybe" from the original. This raises an >interesting point. It may well be good to recommend a specific set of >qualifiers. That allows more intelligent applications. For example, >(and neglecting that "highly variable" and "frequently variable" are >probably not acceptable as nearly equivalent ) it might be easier to >guide identification software if "frequently" is uniformly used where >appropriate, thus perhaps identifying some initially more (or less) >important feature. However, (a).An author might not be completely >satisfied with that qualifier and (b) an author may be satisfied but >prefer something else in natural language discourse. I was thinking the exact same thoughts and even started preparing a list of suggested qualifiers but quickly gave up because the list would end as infinite as individual human vaguery and indecision and preferences for particular turns of phrase. It started to look too much like the trying to standardize character lists exercise. Lucid appeared to offer one - the by misinterpretation thing. Delta appeared to offered infinite - through the comment thing. Or are these conceptually different attributes? Perhaps it might be possible to come up with a manageable list of qualifiers? Qualifiers In Current Use? To have any useful application you would have to come up with a limited list of recommended qualifiers, and a mountain of possible synonyms, or almost synonyms, beneath them. All too scary for me... >Probably this >entails recommending a mechanism for specifying alternatives to the >'official' qualifier. Those mechanisms could guide applications that >were aware of them. For example > ><FEATURE_VALUE QUALIFIER="frequently" RENDER_QUALIFIER_AS="highly"> Why would you want to say this sort of thing in the XML dataset rather than the XML aware application? If your preferred qualifier is 'highly' rather than 'frequently', why wouldn't you just code the data that way in the first place? Surely the most appropriate place for these sort of translations is in the application that is designed to render data in a particular way for a particular purpose (as it the wont of those fascist editor types and other control freaks)? I guess you might want to tell an application this if the only choice of qualifiers you have is this, in this instance, use this particular one. Sort of like converse of how style sheets can specify a font, but give the application a choice of what to use if that font can not be found. Nope... still too scary... jim

1 0