- tdwg-content - lists.tdwg.org

Re: Morphological Data Representation
by unknown＠example.com 26 Nov '01

26 Nov '01

First, I see Kevin has proposed a process slightly different to the one I started on Friday. I would suggest that we focus on one of these rather than running both at the same time. I don't think it matter which one we follow as they both have pros and cons. My idea was to start simple and build as we go while Kevin's is to scope the project first then fill in the details. Any strong views on the process. Guillaume commented that he's "always surprised seeing people recommend using proprietary stuff" in response to my suggestion of using Microsoft's XML Notepad (which, by the way, is actually free). The point I was trying to make was that XML can get complicated very quickly and using an XML view (of any sort) is better than using a text editor. Nothing more. He also commented that my example "was closely related to delta (as xdelta), whereas everyone seems to agree on building something from scratch". I fully agree, but I would suggest that DELTA has it basically right and that whatever we develop will look suspiciously like DELTA. For years taxonomists have talked about things called "characters" with "states" and have used these to build "descriptions" (= DELTA attributes). DELTA is firmly founded in taxonomic practices and since this is driving this process I would be surprised if they diverge too far. In other words there's a reason DELTA has been as broadly accepted as it has and we shouldn't ignore this. Guillaume's final comment, about the use of XML elements and attributes, is important but I still think it can wait. There often isn't a clear distinction between information that "has real-world meaning" and that which is "modelling artefacts." ["One person's data is another person's metadata."] The fact that "default XSLT transformation enforces this by outputting elements contents and ignoring attributes" is too application specific. Many people process XML using DOM tools and they shouldn't be constrained just because XSLT does it another way. Leigh's comments are good and worth a detailed look. His model/representation/syntax (or whatever you want to call it) of the same data I used (see http://www.bath.ac.uk/~ccslrd/delta/lep.xml) is exactly the kind of thing I had in mind. Does his representation make more sense than the one I proposed? What are the strengths/weaknesses of our approaches. Does one allow us to get to where we want to be? Again, I don't think the exact syntax is important at this stage. For example, both models describe the meaning of the numbers present in item descriptions for numeric characters, Leigh as "<value start="0.5" end="0.55" />" and myself as "<CodedState StateID=C3S1 Value=0.5 /> <CodedState StateID=C3S2 Value=0.55 />" with the meaning stored with the state rather than the item description. At the syntax-level these are very different but at the modelling-level they are the same - the same information is being managed (and both differ from the current DELTA-standard in this regard). We will need to work on the syntax but let's get the model agreed to first, then worry about specific syntax. >However, we must agree on model extend: will it concerns only concept >description (aka: characters) or also case description (aka: items) ? IMHO, >only the first one can be generalized, or we'll have to validate the case >description twice: against a generic model and against its concept. > >For using an example, if i have a description of the characters of >Pociloporidae familiy, and a description of the items of Pociloporidae >family, i'll have to make sure characters are really characters (validating >against generic character model), to make sure items are really items >(validating against generic items model), and make sure Pociloporidae items >are really Pociloporida (validating items against characters). I would prefer >to have only to validate characters against a generic character model, and >validate items against characters, meaning using a character description as a >suitable model for items description. I believe this misses the goals of this project in a number of important ways and we should avoid going down this path. It seems to mix the (i) processing of the data with (ii) the data representation with (iii) taxonomic work practices. I'm very uncomfortable going there. Finally, Peter's concerns are important for the next step, expanding the proposed representation to include information not currently managed. One of the strong recommendations from SDD Round 1 was to manage raw data. This needs to be housed under the summarized data (in this case, the actual measurements under the ratios). We WILL need to do this eventually. Peter also pointed out possibly our largest challenge. He noted that "having clear spots in wings is not very precise if the data is to be comparable beyond the group in question - which I suppose is part of the goal." At every TDWG meeting I've been to we decide that we can't build standards for specific character values and yet at every TDWG meeting I've been to we try to build standards for specific character values. We need to build mechanisms to allow sharing of character lists across projects IF THOSE PROJECTS WANT TO USE THIS FEATURE. If projects don't want to share character lists, for what ever reason, then they won't not matter how important we think it is to do so. <soapbox on> I think this focus on "standard character lists" is very much a "plant thing." In animals it would never occur to me to use "clear spots in wings" for anything other than the local context for which it was established. No one would suggest that "clear spots in wings" in bees has anything to do with "clear spots in wings" in butterflies and trying to use a single character coding for this would receive limited support at best. I think the problem is that it's common to talk about "identifying a plant" but very rare to talk about "identifying an animal." There are no "faunas" that are equivalent to "floras." This very fundamental difference between plants and animals and the way people view them has a huge impact on this very development - it's one of the reason's that the botanical community has accepted DELTA much more strongly than the zoological community. While a "global flora" is a completely reasonable goal, a "global fauna" isn't even a faint blip on distant radar. Zoologists work in relative isolation compared to botanists and have very different work practices and needs. Meeting the needs of both of these communities will be a significant challenge, one I'm not sure we can meet in a single set of tools. <soapbox off> Thanks, Steve Steve Shattuck CSIRO Entomology steve.shattuck(a)csiro.au

1 0

Re: Morphological Data Representation
by Peter Rauch 26 Nov '01

26 Nov '01

On Mon, 26 Nov 2001, Robert A. (Bob) Morris wrote: > My feeling is that taxonomic hierarchy is best got by web > applications from services such as ITIS or other web > services offering XML. There is a large community of > descriptive data consumers, e.g. field naturalists, that > find taxonomic hierarchy generally uninteresting. IMO, > trying to integrate it with descriptive data actually > addresses a small group of applications at a cost of added > complexity. "There is a large community of descriptive data consumers, e.g. field naturalists, that find taxonomic hierarchy generally uninteresting." Bob, this comment needs a little bit more explanation / discussion. Without arguing _where_ the field naturalist and other consumers should get their taxonomic hierarchical information, I'd want to argue that such information is (should be!) anything but "uninteresting" to many (most?, all?) consumers, in their work of understanding who is present in their study worlds and why. Having access to purported (evolutionary) relationships of their study organisms focuses a special, valuable, most "interesting" light on their studies. These users need to find these taxonomic relationships handily, somewhere. In that context, your question --Where?-- is probably a fair one to ask. Peter

1 0

Re: Morphological Data Representation
by Robert A. (Bob) Morris 25 Nov '01

25 Nov '01

Steve Shattuck writes: > Date: Mon, 26 Nov 2001 12:31:40 +1100 > From: Steve Shattuck <Steve.Shattuck(a)csiro.au> > To: TDWG-SDD(a)usobi.org > Subject: Re: Morphological Data Representation > > First, I see Kevin has proposed a process slightly different to the one I > started on Friday. I would suggest that we focus on one of these rather > than running both at the same time. I don't think it matter which one we > follow as they both have pros and cons. My idea was to start simple and > build as we go while Kevin's is to scope the project first then fill in the > details. Any strong views on the process. The "data challenges" process was what was agreed in Sydney. Also, it corresponds closely to processes generally regarded as successful in software design, namely Use Case analysis, though it focuses on the use and not the user (in the sense of both human and software). > > Guillaume commented that he's "always surprised seeing people recommend > using proprietary stuff" in response to my suggestion of using Microsoft's > XML Notepad (which, by the way, is actually free). The point I was trying > to make was that XML can get complicated very quickly and using an XML view > (of any sort) is better than using a text editor. Nothing more. Also, MSIE is a reasonable XML viewer, albeit not an editor. > > He also commented that my example "was closely related to delta (as xdelta), > whereas everyone seems to agree on building something from scratch". I > fully agree, but I would suggest that DELTA has it basically right and that > whatever we develop will look suspiciously like DELTA. For years > taxonomists have talked about things called "characters" with "states" and > have used these to build "descriptions" (= DELTA attributes). DELTA is > firmly founded in taxonomic practices and since this is driving this process > I would be surprised if they diverge too far. In other words there's a > reason DELTA has been as broadly accepted as it has and we shouldn't ignore > this. In Sydney it was agreed that DELTA experience and functionality should not be ignored, i.e. we should not start from scratch. [I don't happen to agree with that because of the large community outside TDWG that is already heavily involved in descriptive data if only informally. But it is what was decided, and it does leverage the experience of most of SDD. The trick will be to not arrive at something that only models DELTA] > > Guillaume's final comment, about the use of XML elements and attributes, is > important but I still think it can wait. There often isn't a clear > distinction between information that "has real-world meaning" and that which > is "modelling artefacts." ["One person's data is another person's > metadata."] The fact that "default XSLT transformation enforces this by > outputting elements contents and ignoring attributes" is too application > specific. Many people process XML using DOM tools and they shouldn't be > constrained just because XSLT does it another way. Not only can it wait, but these things are possibly technical enough that they shouldn't be initially in this mailing list. We are nearly finished an installation of vBulletin forum software and will offer to operate a forum off this list for discussion of the technical bits. > > Leigh's comments are good and worth a detailed look. His > model/representation/syntax (or whatever you want to call it) of the same > data I used (see http://www.bath.ac.uk/~ccslrd/delta/lep.xml) is exactly the > kind of thing I had in mind. Does his representation make more sense than > the one I proposed? What are the strengths/weaknesses of our approaches. > Does one allow us to get to where we want to be? Again, I don't think the > exact syntax is important at this stage. For example, both models describe > the meaning of the numbers present in item descriptions for numeric > characters, Leigh as "<value start="0.5" end="0.55" />" and myself as > "<CodedState StateID=C3S1 Value=0.5 /> <CodedState StateID=C3S2 Value=0.55 > />" with the meaning stored with the state rather than the item description. > At the syntax-level these are very different but at the modelling-level they > are the same - the same information is being managed (and both differ from > the current DELTA-standard in this regard). We will need to work on the > syntax but let's get the model agreed to first, then worry about specific > syntax. > > > >However, we must agree on model extend: will it concerns only concept > >description (aka: characters) or also case description (aka: items) ? IMHO, > >only the first one can be generalized, or we'll have to validate the case > >description twice: against a generic model and against its concept. > > To the extent these are separable, there would probably be less dispute about character representation. Probably this means that lots of case description models have to fit on the same character model. > >For using an example, if i have a description of the characters of > >Pociloporidae familiy, and a description of the items of Pociloporidae > >family, i'll have to make sure characters are really characters (validating > >against generic character model), to make sure items are really items > >(validating against generic items model), and make sure Pociloporidae items > >are really Pociloporida (validating items against characters). I would > prefer > >to have only to validate characters against a generic character model, and > >validate items against characters, meaning using a character description as > a > >suitable model for items description. As a not biologist, this sounds right to me. > > I believe this misses the goals of this project in a number of important > ways and we should avoid going down this path. It seems to mix the (i) > processing of the data with (ii) the data representation with (iii) > taxonomic work practices. I'm very uncomfortable going there. > > > Finally, Peter's concerns are important for the next step, expanding the > proposed representation to include information not currently managed. One > of the strong recommendations from SDD Round 1 was to manage raw data. This > needs to be housed under the summarized data (in this case, the actual > measurements under the ratios). We WILL need to do this eventually. > > Peter also pointed out possibly our largest challenge. He noted that "having > clear spots in wings is not very > precise if the data is to be comparable beyond the group in question - which > I suppose is part of the goal." At every TDWG meeting I've been to we > decide that we can't build standards for specific character values and yet > at every TDWG meeting I've been to we try to build standards for specific > character values. We need to build mechanisms to allow sharing of character > lists across projects IF THOSE PROJECTS WANT TO USE THIS FEATURE. If > projects don't want to share character lists, for what ever reason, then > they won't not matter how important we think it is to do so. I agree with this. Whether sharing character lists matters may be a function of the purpose of the list. For example, paper field guides to a given group of taxa often have a far greater commonality of description of characters than they do of characters. And they often come equipped with a character metadata section that explains how to use the characters. > > <soapbox on> > I think this focus on "standard character lists" is very much a "plant > thing." In animals it would never occur to me to use "clear spots in wings" > for anything other than the local context for which it was established. No > one would suggest that "clear spots in wings" in bees has anything to do > with "clear spots in wings" in butterflies and trying to use a single > character coding for this would receive limited support at best. I think > the problem is that it's common to talk about "identifying a plant" but very > rare to talk about "identifying an animal." There are no "faunas" that are > equivalent to "floras." This very fundamental difference between plants and > animals and the way people view them has a huge impact on this very > development - it's one of the reason's that the botanical community has > accepted DELTA much more strongly than the zoological community. While a > "global flora" is a completely reasonable goal, a "global fauna" isn't even > a faint blip on distant radar. Zoologists work in relative isolation > compared to botanists and have very different work practices and needs. > Meeting the needs of both of these communities will be a significant > challenge, one I'm not sure we can meet in a single set of tools. > <soapbox off> > > Thanks, Steve > > Steve Shattuck > CSIRO Entomology > steve.shattuck(a)csiro.au >

1 0

Challenge Cases
by Kevin Thiele 25 Nov '01

25 Nov '01

Welcome back! I actually posted this message a week ago, but my email address has changed slightly, and the list server rejected me. So here it is again. At the Sydney TDWG meeting we agreed that we would continue with the SDD discussion on this list, but try to keep a tighter focus. The last active period (about 12 months ago) was an important brainstorm session, but didn't seem to be very effective at actually getting us to the goal of a workable standard. We decided this time to try working through some challenge cases - real or made-up instances of descriptive data that need to be accommodated in the standard. By agreeing first on a +/- complete set of challenges, then working through the challenge cases in order from simple to difficult, we should be able to reasonably bound our problem while keeping an overview of the territory while actually sinking out teeth into the nitty-gritty. Attached is my first attempt at a set of challenge cases, presented in +/- this form to the Sydney meeting. The first challenge case has an exemplar, the others have not yet. This document as it's worked up will be placed on the TDWG web site for working reference. As the standard evolves, this will also be put up on the site, possibly with progressive status indicators for parts of the standard (e.g. working, proposed, normative - may we one day get to normative) I suggest that we should first add to or modify the list of challenges. Propose a challenge (with exemplar) to add to the list. Once we are happy with an approximate list of challenges (keeping in mind that others will become clear as we proceed, so there's no need to agonise over this step), we'll start with challenge 1. We'll throw up the challenge, give a week or so for contributors to propose data structures that can meet the challenge, then compare and discuss alternate solutions. Gregor I think will shortly be posting a summary of the meeting discussions. We agreed, I believe, that the goal is to provide a standard that can adequately address the descriptive data requirements (ie be a superset) of all existing programs (e.g. Lucid, DELTA, DELTA Access, Biolink) but not be limited to existing programs. It should be able to function as an interchange standard, but should not be limited to that. Bob Morris agreed to provide shortly a discussion on interchange vs interoperability standards and conflicts that may arise in trying to allow for both goals. We agreed that XML will be the basis for the standard. May the force be with us! Cheers - k

1 0

Re: Morphological Data Representation
by Leigh Dodds 23 Nov '01

23 Nov '01

This nicely demonstrates the point that the syntax is only a way to encode a particular model. I'd previously cast the same basic Lepidoptera data into XML (with some additional data, such as images) using XDelta: http://www.bath.ac.uk/~ccslrd/delta/lep.xml I'm sure the following is wrong in places and/or overly simplistic, and deliberately so: A Character has - a Character Type (one of Ordered or Unordered or Real, or ...) - a Character Identifier (a number) - a Short Description (free text) - a Long Description (free text) - an Order Identifier (a number) - a State Descriptor (free text) A State has - a State Value (free text) - a State Identifier (a number) - an Order Identifier An Item has - An Item Type (free text) - An Item Identifier (a number) - A Description (free text) - One or more Characteristics (observed values of states for specific characters) Characters describe a list of properties for some Type of Thing might have. States describe the list of (observed) values of that property for a specific Type of Thing (avoiding the word Class as it's an overloaded term). An Item is the specific instances of those properties, with some specific Thing. What did I get wrong? L.

1 0

Re: Modelling and XML
by Guillaume Rousse 23 Nov '01

23 Nov '01

Ainsi parlait Leigh Dodds : [..] > I'll also interject 2p/euro/cents at this point: > > I believe I'd tackle this problem firstly from a modelling perspective: > can we agree upon, and define a model for the data that we're > capturing. It seems like there is a conceptual model inherent in the > data currently captured by DELTA and other formats, that is > separate to the details of its syntax. I wholefully agree there: let's define first a conceptual model, then we should discuss of its implementation. However, we must agree on model extend: will it concerns only concept description (aka: characters) or also case description (aka: items) ? IMHO, only the first one can be generalized, or we'll have to validate the case description twice: against a generic model and against its concept. For using an exemple, if i have a description of the characters of Pociloporidae familiy, and a description of the items of Pociloporidae family, i'll have to make sure characters are really characters (validating against generic character model), to make sure items are really items (validating against generic items model), and make sure Pociloporidae items are really Pociloporida (validating items against characters). I would prefer to have only to validate characters againt a generic character model, and validate items against characters, meaning using a character description as a suitable model for items description. -- Guillaume Rousse <rousse(a)ccr.jussieu.fr> GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html

1 0

Re: Morphological Data Representation
by Guillaume Rousse 23 Nov '01

23 Nov '01

Ainsi parlait Steve Shattuck : [..] > I've translated this into the XML file that is attached. (Even this fairly > simple example is moderately large and I would recommend using an XML > viewer such as Microsoft's XML Notepad when working with it - see > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnxml/html >/ xmlpaddownload.asp.) I'm always surprised seeing people recommend using proprietary stuff, when they are plenty of free-software equivalents: http://freshmeat.net/search/?site=Freshmeat&q=xml+editor&section=projects sourceforge.net also also provide a complete list vim and emacs also have xml support, and are available on many platforms > The basic structure of the attached file is: > > <Morphology> > <Characters> > <Character> - ANY NUMBER > <Type> > <ID> > <Short_Descriptor> > <Long_Descriptor> > <State_Descriptor> > <Order> > <State> - ANY NUMBER > <Value> > <ID> > <Order> > <Items> > <Item> - ANY NUMBER > <Type> > <ID> > <Descriptor> > <CodedCharacter> - ANY NUMBER > <CharacterID> > <Description> > <CodedState> - ANY NUMBER > <StateID> > <Value> This is a mixed approach, whereas Gregor's proposition is to separate characters description and items. Morevoer, it's closely related to delta (as xdelta), whereas everyone seems to agree on building something from scratch. > Note that I've treated everything as elements and haven't used attributes. > Simplicity is the only reason for this and some elements would be better as > attributes; these can be converted when the dust settles. No, there is also a performance argument for attributes: as they make files less verbose, parsing is quicker. See xerces-j/xalan-j FAQ. However, from a modeling point-of-view, the rule should be: use elements for what is has real-world meaning use attributes for modeling artifacts (id, idrefs, etc...) Default XSLT transformation enforces this by outputting elements contents and ignoring attributes. -- Guillaume Rousse <rousse(a)ccr.jussieu.fr> GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html

1 0

Morphological Data Representation
by unknown＠example.com 23 Nov '01

23 Nov '01

Below and attached are a first attempt at representing simple, common DELTA-type data in an XML-based structure. I've used a selected set of characters and items from the Butterfly sample data on the DELTA web site. The DELTA-formatted data looks like this: ==== DELTA-Standard CHARS File ==== *SHOW: Lepidoptera demonstration characters. Revised 28-AUG-91. *CHARACTER LIST #1. main colour of inner part of front wing/ 1. white/ 2. cream/ 3. grey/ 4. brown/ 5. black/ 6. yellow/ 7. orange/ 8. blue/ 9. green/ #2. wings <transparency>/ 1. with transparent areas/ 2. without transparent areas/ #3. length of front wing/ mm/ #4. antennae <length>/ times length of front wing/ ==== DELTA-Standard ITEMS File ==== *SHOW: Lepidoptera demonstration items. Revised 18-OCT-94. *ITEM DESCRIPTIONS # Antheraea/ 1,4 2,2 3,43-50 4,0.15-0.2 # Ethmia/ 1,2-4 2,2 3,11-14 4,0.6-0.65 # Graphium/ 1,1-2/9 2,2 3,29-33 4,0.45-0.5 # Hecatesia/ 1,4 2,1<small, translucent window>/2 3,11-14 4,0.8-0.9 ==== DELTA-Standard SPECS File ==== *SHOW: Lepidoptera demonstration specifications. Revised 28-AUG-91. *NUMBER OF CHARACTERS 4 *MAXIMUM NUMBER OF STATES 9 *MAXIMUM NUMBER OF ITEMS 4 *CHARACTER TYPES 3,RN 4,RN *NUMBERS OF STATES 1,9 ==== For these files, the DELTA-generated natural language would look something like this: Antheraea Main colour of inner part of front wing brown. Wings without transparent areas. Length of front wing 43-50 mm. Antennae 0.15-0.2 times length of front wing. Ethmia Main colour of inner part of front wing cream to brown. Wings without transparent areas. Length of front wing 11-14 mm. Antennae 0.6-0.65 times length of front wing. Graphium Main colour of inner part of front wing white to cream, or green. Wings without transparent areas. Length of front wing 29-33 mm. Antennae 0.45-0.5 times length of front wing. Hecatesia Main colour of inner part of front wing brown. Wings with transparent areas (small, translucent window), or without transparent areas. Length of front wing 11-14 mm. Antennae 0.8-0.9 times length of front wing. ==== Hand-generated natural language would be essentially the same except for the last item, where it might look more like this: Hecatesia Main colour of inner part of front wing brown. Wings with or without transparent areas (when present, forming a small window). Length of front wing 11-14 mm. Antennae 0.8-0.9 times length of front wing. ============================================ I've translated this into the XML file that is attached. (Even this fairly simple example is moderately large and I would recommend using an XML viewer such as Microsoft's XML Notepad when working with it - see http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnxml/html/ xmlpaddownload.asp.) The basic structure of the attached file is: <Morphology> <Characters> <Character> - ANY NUMBER <Type> <ID> <Short_Descriptor> <Long_Descriptor> <State_Descriptor> <Order> <State> - ANY NUMBER <Value> <ID> <Order> <Items> <Item> - ANY NUMBER <Type> <ID> <Descriptor> <CodedCharacter> - ANY NUMBER <CharacterID> <Description> <CodedState> - ANY NUMBER <StateID> <Value> Note that I've treated everything as elements and haven't used attributes. Simplicity is the only reason for this and some elements would be better as attributes; these can be converted when the dust settles. I've tried to generalise as much as possible and use only two main elements: <character> and <item>. Each character is assigned a <type> that tells what it is (ordered multistate, unordered multistate, real, integer, etc). Similarly the item <type> can be specified as taxon or specimen (or potentially something else). A couple of points are probably worth making: The <Short_Descriptor> and <Long_Descriptor> are used to support DELTA comments. This probably needs to be generalised further to support any number of alternate phrasings. <State_Descriptor> is used for the units of numeric characters and isn't needed (?) for other character types - it's an attempt at keeping <character> general. The <Description> element in <CodedCharacter> is used to house natural language representations. Codes for the states (when needed) are placed in square brackets, these being translated during generation. As noted above, this may been to be generalised to support any number of phrasings. In <CodedState>, <Value> is used to hold numeric values, the <character> <state> being used to define what the number means (minimum, maximum, etc., rather than using placement in the attribute string as in the DELTA standard). This element won't (?) be needed for multistate characters. I think/hope the remainder is fairly clear. ** The Next Step ** I would suggest the following path from here: 1) Make sure the above representation makes sense for the data given. 2) Expand the above data to support LucID-specific requirements (without adding additional complexity). Once this is finished we can: Add additional DELTA features (dependencies, default values, etc.) Add more complex data sets and examples Add new features on our assorted "wish lists" I look forward to comments and forward progress! Thanks, Steve Steve Shattuck CSIRO Entomology biolink(a)ento.csiro.au

1 0

Re: is there an "xml-include"
by unknown＠example.com 22 Nov '01

22 Nov '01

There seems to be a number of problems being addressed in the current discussion: 1) Gregor's original post asked for a solution ("how do I do an include in XML") without posing a problem ("how do I maintain a separate global character list and link a number of independent taxon descriptions to it"). I would suggest that using an "include" is only one of a range of solutions to this problem. And if this isn't the problem then we should revisit it before spending too much time coming up with a solution. 2) Whether XML is hierarchical or relational is of little importance in practice. All major relational databases can suck in and spit out XML - it's a non-issue from an implementation standpoint (which is what we are ultimately concerned with here). IDs and RefIDs are primary and foreign keys - the mapping is one-to-one if you want to structure the XML that way. 3) Leigh is spot-on when he says "define a model for the data" as this is "separate to the details of its [the model's] syntax". The syntax (= XML model) will be useless if it doesn't manage the information that's important to us no matter how "rigorous" or "technically accurate" it is. 4) At the Sydney meeting I thought we agreed to restart this discussion with specific examples based on real-life characters (in the biological sense). This current thread would seem to be very much a continuation of the one started 2 years ago: 80% focus on solutions (largely round XML syntax) and 20% on specific problems (addressing business needs). I fear we'll end up the same place we were before. Thanks, Steve Steve Shattuck CSIRO Entomology biolink(a)ento.csiro.au P.S. - A solution to Gregor's problem would be to use unique identifiers (GUIDs) in his global character list. Any one using this list would then include these identifiers as part of taxon descriptions along with metadata (a citation) to find where the global list is housed. If you then want to combine separate description datasets you can compare the character identifiers: if they are the same then it's the same character, if they are different then it's not the same character. It's a simple, foolproof solution that's easy to implement technically (whether people will actually do this is a completely different matter ;-) ). P.P.S. - I'm well aware that I have the power to direct this discussion by actually doing what I suggest in No. 4 above. And I really, really intend to do it. I just have one more meeting to get through, and then another 10 emails, and then ....

1 0

Re: is there an "xml-include"
by Robert A. (Bob) Morris 21 Nov '01

21 Nov '01

Steve Shattuck writes: > Date: Thu, 22 Nov 2001 10:41:55 +1100 >[...] > 4) At the Sydney meeting I thought we agreed to restart this discussion with > specific examples based on real-life characters (in the biological sense). > This current thread would seem to be very much a continuation of the one > started 2 years ago: 80% focus on solutions (largely round XML syntax) and > 20% on specific problems (addressing business needs). I fear we'll end up > the same place we were before. Amen. More explicitly, what was posed was to provide "data challenges", i.e. (as I understood) problems about characters that the poser feels important to model. Implicit (as I understood) in that discussion---and in almost all of this recent thread---is that a particular representation (e.g. XML) is NOT what is initially desired. If, indeed, my understandings were correct, and if a sufficiently inclusive set of challenges were identified, what would then be accomplished sets the stage exactly for the modeling Leigh urges. Further, this complies with one of the admonitions in Rob Atkinson's talk to first find out what you are trying to make a standard about, i.e.: <not> <adage>XML is the answer. What is the question?</adage> </not> Finally, I would paraphrase what I understood the subgroup meeting arrived at: The first job is to identify with these data challenges the strengths and the limitations of what DELTA-motivated applications can accomplish, rather than throw out the experience of DELTA and start over. Probably Gregor's meeting minutes will reveal whether that understanding is correct and perhaps how it came to be. --Bob Morris

1 0