XDELTA and LucID

[Leigh Dodds]

> I've been looking through your XDELTA DTD. The group has already commented
> that it's "merely" a literal mapping of DELTA, but it's a very
> useful start :-)

Thanks I was hoping it would be a discussion point.

> 1. Character groups
>
> I assume that character groups here are equivalent to character sets in
> LucID - groupings of characters so that you can e.g. display only leaf
> characters in a random-access key. In LucID there is no requirement that
> characters in a set are consecutive in the character list. Further, any
> character may belong to more than one set - this is very useful
> so that e.g.
> you can have the sets "leaves", "flowers", "petals", "simple" in which
> "petal" characters also belong to the "flowers" set, and the "simple" set
> comprises a selection of characters from all the other sets.

Yes you've interpreted correctly, and XDELTA is limited in that
characters can only be within a single group, and must be grouped
together.

This did concern me when I was initially writing the DTD, but based on
the fact that DELTA had the same limitation I thought it would be good
enough for a first cut. LucID is obviously more flexible.

> 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.

> 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.

> 4. Images

> It's useful to allow an image to have both a title and associated
> text e.g.
> notes, credits, copyright notice. Defining the title separately from the
> text allows an application to retrieve and display just this
> without the rest.

More generally I think that (from other comments on the list), it would
be useful to attach this kind of information : notes, credit, copyright,
origin, etc in multiple places in the format - including textual
descriptions.

> 5. Character values
>
> LucID allows a richer assignation of character state values to
> taxa. Thus, a taxon may be scored as having state 1 as its normal state,
> state 2 rarely, state 3 by misinterpretation, and be unknown for state 4.
The
> full list is:
>
> normally present
> rarely present
> uncertain
> present by misinterpretation
> rarely present by misinterpretation
>
> These are important. Note that the proposed extensions to DELTA
> incorporate some or all of these. Gregor has already proposed a system of
> modifiers to allow this.

This sounds like a strong requirement then.

>
> 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...

> 7. A small point:
>
> >     A multistate character must contain at least one state.
>
> Surely a multistate character must contain at least two states.

Yes, You're quite right! :)

> 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?

> It will sometimes happen that several collaborators will share a common
> character list and score different taxa, as you describe. But it will also
> happen that the collaborators share a taxon list and score different
> characters. This may be simple, but the same issues (interdocument
> references, conflicts etc) need to be addressed.

I'd hadn't thought of this - its the reverse of what I'd originally
expected.

I expect the referencing and conflict resolution mechanism to be
tricky to solve, and I'm hoping we can delay some of those decisions
until such time as a document structure has been determined - mainly
because not all the issues will be obvious until that point.

------------------------------

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.

As an aside - if anyone wishes additional explanation of the current
DTD then I'm more than happy to oblige.

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.

L.