(Note: I am trying to split the discussion "SDD Schema in relationship to Prometheus_Response to Kevin"; please respond to this).
The good news I suppose is that since SDD is (hopefully) more
general,
there should be no problem rendering your data in SDD. The more interesting question is whether your data *model* (the part-
structure
stuff) would come out the other end of an SDD roundtrip.
It should be possible, if you represent you part-structure stuff in
a
character hierarchy, and assume after roundtripping that the
hierarchy
you get back can still be interpreted in the same way. That is, you would need to check whether the hierarchy you receive conforms with your model (and I suppose reject it if it does not).
I am very interested in how well this can be achieved. The character hierarchies contain enumerated attributes that attempt to describe what kind of hierarchy a given tree represents. This may be a purely presentational hierarchy, or a part/structure, a property, a method. Please compare ConceptTreeDefType/Type with enumerated list in the schema. Is this appropriate/sufficient?
I addition to these we have all the time recognized the need for more exact definition of descriptive objects, and we call the objects that should achieve this Glossary/GlossaryEntries. Despite being within terminology, and next to characters they can be used fully separate to describe
Two of Trevor's questions in the word document regarding the Glossary were:
1. "I am also unsure as to how well defined the terminology MUST be within SDD (e.g. does a glossary entry require a definition and authority - or could bare words with no definition or relation ship to other terms be included)"
2. "I am still quite confused about HOW PRECISELY a terminology CAN be defined within a SDD document. e.g. how accurately can a term be defined in terms of relationships with others, I understand that these relationships are captured by the concept trees, although again a (visual) model detailing this would clarify."
Ad 1: Glossary entries are always optional, otherwise it would be impossible to express DELTA / Lucid / etc. legacy data in SDD. If a glossary entry exists, it currently must provide a head term (formalated independently, and perhaps redundantly from the character, state, modifier, hierarchical concept etc. it refers to) and either of a free-form text definition or a URI pointing to such a definition on the web. The "ontological" relationships are optional. The assumption is that a glossary will "grow" over time while a project matures.
(Trevor: your argument about rigorous definition of data is quite valid. I would assume that either the application controls that, or that somebody derives a local version of the SDD schema for fully schema driven data entry. However, quality enforcement can not be an issue for a schema focussing on data exchange. We enforce completeness questions only if we believe not doing so would break application interoperability. We do rigourously enforce consistency questions such as that a state must be defined before using it).
Ad 2. I cannot answer this, other than that we try to provide both operational and ontological/fundamental means of expression. We believe that much can be expressed, but these are only our scenarios. Thus:
TO ALL: Please do provide scenarios you would like to try to express, which you think may be difficult. We urgently need such examples!
I am rather worried about the relationship between these two mechanisms in SDD. I believe there is a very good point in separating fundamental ontology from operational definitions, in fact given our task to be able to also represent legacy data (including printed information) it is unavoidable.
However, there is clearly much overlap in creating character hierarchies expressing a part-hierarchy, and having an unconstrained method to express any part hierarchy in the Glossary/*/PartOf method. One current result of this is, that we are not yet expressing Property/State relations in Glossary; these only exist because Glossary and Character/states may be linked. It would probably be a good idea to separate them as well. Any opinions on that?
Gregor ---------------------------------------------------------- Gregor Hagedorn (G.Hagedorn@bba.de) Institute for Plant Virology, Microbiology, and Biosafety Federal Research Center for Agriculture and Forestry (BBA) Koenigin-Luise-Str. 19 Tel: +49-30-8304-2220 14195 Berlin, Germany Fax: +49-30-8304-2203
Often wrong but never in doubt!