Jim wrote:
> 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?
There are two things mixed in here, surely.
1. Yes, I think an architecture that allows both discursive (read "natural
language" if you will) and coded (DELTA-like) descriptions is feasible. The
principal difference between discursive and coded forms is that one uses
idrefs and the other doesn't - so as Bob notes, once the XMLHeads work out
how to use idrefs here we will hopefully be able to accommodate the coded
form.
2. In either case, there is still a need for a limited set of qualifiers for
feature values (ie present, uncertain, present by misinterpretation etc).
This will surely simply be another layer of complexity that will be added to
the core once it's robust.
This is partially implemented already (using two rather curious qualifiers):
- <FEATURE name="color">
<FEATURE_VALUE QUALIFIER="highly">varies between colonies</FEATURE_VALUE>
<FEATURE_VALUE QUALIFIER="maybe">concolorous yellow-brown</FEATURE_VALUE>
<FEATURE_VALUE>bicolored with darker head</FEATURE_VALUE>
<FEATURE_VALUE>concolorous brown</FEATURE_VALUE>
</FEATURE>
Presumably, Bob's comments:
>As we represent it, TDD0.3 has only a few classes of objects:
>FEATURE a complex type with a name attribute and containing a string-based
FEATURE_VALUE,
>NARRATIVEs and, recursively, other FEATUREs.
>DESCRIPTION a container of FEATUREs and NARRATIVES.
>NARRATIVE a string-based type suitable for extension to more complex
markup.
>Our goal was the production and application of a Schema for TDD0.3, and
consequently in the
>sample applications we have forced some things into the model which are
likely, ultimately,
>to have their own Schema. The notable examples are publishing artifacts
such as markup for
>literature references, and some common scientific vocabulary deserving its
own tagging standards.
means that many things will eventually be moved out of the rather
featureless FEATURE and DESCRIPTION objects into more purpose-built
structures.
Cheers - k
