XDELTA and LucID

[Kevin Thiele]

Leigh

>> 2. Character state notes
>>
>> DELTA stores all notes as plain text, sometimes marked up with its own
>> typesetting marks, but pretty plain nonetheless. LucID allows builders of
>> keys to associate a formatted file (txt, rtf, html) with a
>> character state,
>> to hold explanatory notes. One option would be to include xml markup as
>> comment (would this be messy if the notes included embedded
>> images, hotlinks
>> etc). Another would be to treat state notes as you do images, with an href
>> pointer to a file. LucID also allows sound files to be associated with a
>> state (imagine a key to cicadas or frogs with calls as characters).
>
>How about if the text allowed (X)HTML markup to me used. This would
>allow the full range of HTML expression (tables, bold, images, etc).
>However it would mean tht processors (e.g. a stylesheet) would need to
>understand HTML. I suggest that a subset of the available markup
>would be enough in most cases. A pointer to additional document(s)
>would also be useful.


Yes, I think we'd need to allow for both - embedded (X)HTML and pointers to
external documents, from which an application could fetch stuff if
necessary. I have a key with 800 states each with html notes, images etc.
Embedding all this would make for one hell of a document.


>> 3. Taxon multimedia
>>
>> LucID allows any number of multimedia files (images, videos, sounds, txt,
>> rtf, html).
>
>Ideally an XML format would allow this as well. A generic 'link' to
>additional information could be used. It then depends on the application
>to decide whether it can fetch, and handle the particular
>multimedia format.

Ditto as for state notes


>> 6. Taxon subkeys
>>
>> In LucID keys one key may be linked as a child to another. A
>> taxon thus has the name of a subkey associated with it, so that a user on
>> reaching the taxon can ask the program to automatically drop to the subkey
>to
>> continue the identification.
>
>If I understand this correctly you mean that the subkey provides additional
>information regarding the taxon. To take a trivial example, the first
>key may identify a plant to the Family level, whilst the subkey had
>additional information - e.g. to the species?
>
>If so, then this is related to the document linking problem below...


Yes it's a linking issue. By allowing links from one document to another you
can build hierarchies of documents e.g. I have a key to Families of
Flowering Plants of Australia: the family Solanaceae has a link to a
separate key to genera and species of that family, and some of these taxa
have further subkey links. The hierarchy of keys-subkeys is being built up
in an ad hoc fashion.



>> 8. General Information
>>
>> Not all information in a key or other treatment can be associated with
>> character states or taxa. Some is associated with the treatment as a whole
>> e.g. introductory notes, notes on using the key, general notes for the
>> parent taxon of the key (e.g. a key to genera of Grossulariaceae
>> may have a description of the family) etc. In LucID this information may
>> comprise html files, images etc just as with taxa and states. This could
>be
>> easily dealt with by expanding your DTD. A special case is an "About this
>key"
>> file. This needs much more than is allowed in the document description:
>
>This is one area that I don't think we've touched upon to a great extent
>(I could be wrong). Heres a question:
>
>- is it enough to just have an 'additional information' element
>so that any required explanatory notes, etc can be added there.
>
>Heres my answer (and I'd welcome comment):
>
>No its not. It would be useful to try to quantify this additional
>information,
>so that a generic catch-all placeholder isn't used. This sidesteps issues
>such as that shown by the comment marker in DELTA which ends up being
>used for all sorts of other uses. Its this kind of information which is
>highly useful both to the user, and the application developer: the user
>has a defined place to add his/her information, the developer has explicit
>cues on how particular sections of information should be used.
>
>So to start a running list:
>        - introduction
>        - about this key?
>        - parent taxon / related keys
>        - usage guidelines
>        - other meta information?
>                (see above - copyright, funding body, author, change
history, etc).
>
>Anything else?

I wouldn't like to try to force people into boxes here. It may be that there
are some "General Info" topics that are fairly common, but you can't predict
how someone will want to structure this. For instance, someone writing a key
to insects might want to have a topic covering collecting techniques,
another would want general info on biological control. A user here who has
published a key to eucalypts of Australia has included a synoptic
classification.

Best option again I think would be to be very general and allow flexible
links to external files with topic names.



>You've commented that you're just getting to grips with DTDs, is
>it going to cause a great problem if I design the next version of
>XDELTA using XML Schemas [1,2]? Schemas provide a great deal more
>flexibility
>when defining document structures, as well as validation (not
>that I expect the latter issue to matter to a huge degree in this
>context). The are some structures in the XDELTA DTD which I'm not
>particularly happy with, but are imposed by the limitations of
>DTD syntax. I'm hoping that Schemas will remove some of these constraints.
>
>When I get chance to attempt another iteration of XDELTA (hopefully
>quite shortly), I can fully document the Schema to bring people
>up to speed - i.e. use XDELTA as a tutorial piece.


Great, and you're a bloody marvel!



>I also don't want to appear to be leading everyone by the nose
>towards an XML based format, or one which I've produced myself.
>So please consider XDELTA, as I've always maintained, as a discussion
>point.

I agree it's still a discussion point but it's the best we have so far to
start bringing this discussion towards a product, doing which will bring out
extra points, flaws, limitations etc. If you're willing to do the work on
it, then I'm sure we're willing to comment and pick the holes.

Cheers - k