Schema SDD_09.xsd

Provides root element. Note that the version of the SDD standard used is defined in the namespace declaration and needs no separate data element.

Note: until xInclude is sufficiently widespread implemented to combine data from different documents, terminology, descriptions, and resources must be in the same document!

Defines the terminology (parts, characters, states, etc.) in which
the descriptions are expressed.

The classes (biology: taxa) and objects (biology: specimens) that are being described.

Descriptions of either an abstract class concept (taxon, disease, etc.) or a physical object (individual specimen, part of individual, etc.).

Dichotomous or multifurcating authored keys (including legacy data)

A collection of AgentRefType elements, i. e. Agents forming a team like an author team.

(The xml sequence of
elements in this collection
is informative!)
[ATTR: ref]

Defines an element with a ref attribute pointing to an Agent (Resources/Agents/Agent)

Base type; defines an element with a ref attribute pointing to Audience definitions (different data type from generic ref!)

Similar to CharacterStateDataType, this one is intended for CodingStatus references.

The ref attribute points to the key of Terminology/CodingStatusValues/CodingStatus

@@Is it ok to inherit the ref attribute from the state base type, even though it points elsewhere?

Abstract base type for character
data in coded descriptions. It
primarily contains a reference
to a Character definition key, plus
a set of references to character
state definition keys.

@@This base type may be redundant. Is Sequence really relevant both in coded synthetical data as well as in raw data?@@

Constrained to 'description' or 'terminology' (default). If Sequence = description the sequence of states in the xml document is considered to be meaningful and can be used to distinguish between, e. g. 'round or elliptic' and 'elliptic or round'.

Used in coded descriptions to make statements covering a single
character of a class or object.

The type provides a ref to the definition of a character (it is derived from CharacterRefType)

States are 'scored' in a description by referring to a state in the character definition. All notes and modifiers are applicable to this element.
[ATTR: ref]

Statistical measures contain synthetic information like distribution parameters, sample size, etc. Refers to a StatisticalMeasure defined for the current character. It may have associated Notes (public notes) and Probability modifiers, but no general or frequency modifiers.

The value is stored in an attribute of type double.
[ATTR: ref, Value]

Inapplicable, unknown, etc. It may have associated Notes, but no modifiers.
[ATTR: ref]

Note: In an object (= specimen) description only a single indicator may occur per character. However, for a class (e. g. a genus) it is up to the aggregation/generalization process whether to create multiple coding status values or not. For example, an expression "unknown or not applicable" may be useful for analytical purposes.

Media specific to the
character and the current
object or class described.
Example: microscopic picture
of spore shape in a specimen.

Defines a character in the terminology

Label includes abbreviations
(e. g. for tabular reports)
but no natural language wording.

(Natural language wording for
characters is available through
concept trees!).

- cardinal data scale = integer (incl. negative values, although these are extremely rare in descriptive biological data; DELTA: type 'IN')
- interval = real numeric = floating point values (DELTA: type 'RN')
- nominal = unordered categorical states (DELTA: type 'UM')
- ordinal-discrete = ordered categorical states (DELTA: type 'OM')
@@ Should we make a distinction between ordinal-discrete and ordinal-interval [= ordered categorical states (DELTA: type 'OM'). Like ordinal-discrete but states can intergrade. Example: no / few / many hairs, ovate / ellipsoid. However, also intergrade without order:
- Color @@ introduce a separate datatype for color? Exact value are not very practical, but polygons in color space would be very usefull!

Only applicable if
character type is
cardinal or interval
(not controlled by
schema!)

Constrains which project-wide StatisticalMeasure definitions can appear in descriptions of this character.

Note: Some statistical measure definitions (min, median, mode, etc.) could apply also to ordinal or even nominal types. This is, however, not yet supported in SDD.

The key attribute must be unique and is referred to in the descriptions. The ref refers to the semantics defined in the project-wide statistical measure definitions.
[ATTR: key, ref]

Unit like mm, µm, °C. The content allows some xhtml formatting to support e. g. "mm<sup>2</sup>".

A Postfix attribute may be set to false to output string before a value (e. g. 'pH 7.0').

Applicable to all character types; categorical states can be defined in addition to statistical measures!

(States are defined outside the type specific tree, since categorical states may be present in addition to numerical data)

Local definition of a state
[ATTR: key]

Reference to a single generic
state (as defined project-wide
at a concept tree node).
[ATTR: key, ref]

The project-wide modifier definitions become applicable to the current character only if a modifier set containing them is referenced here.

Modifier usage in descriptions is not controlled by the schema, i. e. modifiers not present in any set may be present in descriptions for this character. Additional validations are, however, possible.

Multiple modifier sets can be referenced in each character. The applicable modifiers are the union of all modifiers in the referenced sets (duplicates are ignored)
[ATTR: ref]

Similar to CharacterStateDataType, this one is intended for statistical measures. The ref attribute points to a statistical measure definition inside a character definition.

@@Note: the necessity of Note inside statistical measures needs to be discussed. On measures like min, max, mean this will be difficult to support during natural language reporting! However, on measures like sample size they may be valuable.

Expressions of probability:
'probably', 'perhaps', etc. are
defined for numeric values and statistical measures. Frequency expressions are considered not applicable to statistical measures!
[ATTR: ref]

Refers to a character (e. g. from within concept trees or from Descriptions). It consists only of a reference to a Character definition key.

The abstract base type defines the common attributes that are used in both coding status (not modifiable) and normal categorical state (modifiable) references.

Public notes or comments,
for multiple audiences.
Applications may, e. g.,
report the text in brackets
after the character state.

If a new description is created as a child of the current description (in the class hierarchy or through an object identification), the current state will be inserted. This may be a normal state or a coding status. The inserting mechanism is available in addition to the dataless inheritance mechanism in the class hierarchy.
@@ Open issue: Name for this element needs to be decided@@

Like CharacterStateData_BaseType,
but allows expression of state
probability, frequency,
and general modifiers.

Expression of probability:
'probably', 'perhaps', etc.
[ATTR: ref]

Numeric statement, single Value attribute

Numeric frequency range (Lower/UpperEstimate attributes)

Reference to globally defined
frequency modifier (ref attribute).

General modifiers of intensity ('very', 'weakly'), location ('at the tip'), timing ('spring', 'autumn'), etc.
(The seq. of modifiers is informative!)
[ATTR: ref]

Based on StateDefBaseType,
for categorical states.
Used in generic
(= 'project-wide')
and local character
state definitions.

Any use of a character state in
descriptions is a reference to an
object of this type or one of its derivations.

If present and true, the current state/ category allows unconstrained text not tied to a truly analytical state. Such states (which may be labeled: 'Text', 'Other:', 'none of the above, please specify:') prevent, especially if the terminology is still under development, that during data entry potentially inappropriate category must be chosen. DELTA text character are modeled using these states, but they also can occur in combination with categorical states.

UnconstrainedText states are somewhat similar to the 'unknown' coding status, since the free-form text information is not available to most analytical processors (incl. identification programs).

(This 2nd annotation contains detailed informations not entered in the first annotation, which is visible in the standard schema diagrams.)

The name for this data element was contentious. Proposals were:
Bob: IsIsolatedState with default false.
Gregor: IsAnalyticalState, StateComparisonIsRecommended, or IsWellDefinedState, all with default true.
ImpreciseEqualitywith default false?

Furthermore, one may want to make a distinction between a category saying "enter free form text here" and one explicitly saying "none of the above". However, the action of choosing a separate free form text state instead of scoring a category (if available) and adding free-form note text, implies that choosing free-form text is always of the type "none of the above", whether this is explicitly stated in the text state label or not.

A collection of state references (CharacterStateRefType)

[ATTR: ref]

Refers to a character state (e. g. from Descriptions). It consists only of a reference to a Character state definition key.

Used inside the character definition, it refers to a generic statistical measure in Terminology/StatisticalMeasures.
In addition to the ref it defines a new key and formatting information.

Combines a publication resource reference with a detail location within that reference (esp. page number)

Refers to a publication as defined under Resources/Publications
[ATTR: ref]

Location within publication where the cited data can be found : Page, table, figure number, database record, html document bookmark, etc. (not the inclusive pages of the article).

Used for class names (taxon names). Provides either a simple free-form text, or a connection to an external resource

The resource connector here may be changed to a derived type that also allows to enter a structured form of taxonomic names (Genus/Higher taxon, rank, optional specific/subspecific epithets, authors). However, note that simply splitting into taxon name and authors does not work, because authors may be in the middle of the parts of the taxon name (e. g. in botanical autonyms).

Note that class is not restricted to accepted class names (compare Synonyms in ClassHierarchyNodeType)

@@ For biological taxonomic names: order, family, species
Needs discussion: should this be constrained vocabulary, or in any language?

Defines an element with a ref attribute pointing to a Class in Resources (in biology: Class = Taxon)

Descriptions entered as data referring to the terminology elements. CodedDescriptions must fulfill more rigorous consistency requirements than natural language descriptions and are more suitable for analysis. Furthermore, language-dependent annotations are minimized so that data can be easily reorganized and translated into multiple languages.

The coded description is entirely controlled by the vocabulary and structures defined in the Terminology section. It contains keyrefs to descriptors and modifiers (plus numerical values for measurements). Free-form text is allowed in Notes or Annotation only. Separating data and terminology allows rearranging and refactoring the terminology, multilingual support through central terminology translations, and multiple hierarchical views.

(a uniqueness constraint guarantees that (except in ObservationSets) a character may occur only once in each description and that each State, StatisticalMeasure,  and CodingStatus occurs only once!)
[ATTR: ref]

Based on StateDefBaseType; for CodingStatus values

Properties describing a coding status value. They are provided to support generic application code that continues to function if new codes are added.

To be coded / Not to be coded / Cannot be coded / coded successfully

NotEvaluated / CannotExist / DoesNotExist / Exists

Defines an entire concept tree
(which may be a single tree node containing a flat list)

Label to identify the
current object in the
user interface

The type of a tree is constrained to an enumerated list to support application interoperability.

Usage of concept tree intended by its designers; constrained to an enumerated list to support application interoperability.

The root node of the tree. Note that it has a label in addition to the tree label. The tree label uniquely identifies a tree when selecting it among a list of all trees, whereas the root node label can be very short and is shown when a single tree is displayed.
[ATTR: key]

A node in a concept tree

Project-wide state definitions tied to the part (e. g. for fruit: capsule, berry, nutlet, etc.), property (e. g. for color: red, green, etc., for shape: round, ovate, etc.), method, etc. described in the current tree. GenericStates become operational for descriptions only when binding or instantiating them in specific characters.

The definition of generic states is identical to the local definition of states within a character. Using generic states simplifies the management of terminology and improves data analysis (states from different characters can be compared if they refer to generic states).
[ATTR: key]

Element may be missing, which results in the option to have empty nodes with neither a character nor further nodes.

[ATTR: key]

Characters are the 'leaves' of the tree. Each character is embedded in a node providing labeling information in the context of the current tree (which is usually different from the default character label). A single character may appear in several places in the tree, if this is desired.
[ATTR: ref]

Used to define objects that are described (collected and preserved objects as well as objects that have only been observed). In biology a collected object is called a specimen.

Provides either a simple free-form text, or a connection to an external resource.

Identification of specimen object. The information may come from the service provider, but it must be converted to refer by ref to Resource/taxon names.

If unidentified this may point to a higher taxon or a special class "unknown" introduced for that purpose.

[ATTR: ref, IdentificationIsCertain]

False = object has not been collected and preserved (it may still be databased in an observation database and have an ExternalID!). The default for this element is true, i. e. if the element is missing the object has been collected/preserved.

Defines an element with a ref attribute pointing to a Specimen defined in Resources
@GH@: Discuss whether to add a separate element for collection abbreviation (cached information form provider or from 

Abstract base type for NaturalLanguageDescriptionType
and CodedDescriptionType.

The key attribute is currently not used in keyrefs from within this schema. However, it is considered generally useful to uniquely identify descriptions in federated situations.

Refers to a class name
(in biology a taxon name)
[ATTR: ref]

Refers to an individual object (e. g. a biological specimen). Objects may refer to observed objects as well as to collected and preserved objects. The identification of a specimen is stored in the resource section.
[ATTR: ref]

A description may be further defined through a published data source for the nat. language or coded description.
If Citation is missing, it is assumed that the compiler or editor of the data is the original source of information.

Contains multiple resources (e. g. images).

@@ In previous versions, a description may consist of resources alone, this is not possible after Paris - may need discussions! @@

@@ Also, it is no longer clear whether the images are also created by Creators, or who has the IPR to them! @@

(Section within the SDD root)

A strict and largely language- independent description entirely controlled by the terminology defined in the current project.
[ATTR: key]

Defines a guided key (dichotomous or multifurcating key) that has been manually created with expert knowledge.
Note that guided keys may also be automatically created by applications based on information in terminology and using shortest search criteria in the coded descriptions.

Label to identify the
current object in the
user interface.

If the key is derived from a published data source this is cited here.
If Citation is missing, it is assumed that the compiler or editor of the data is the original source of information.

The root node of the designed key.

Note: Applications will generally ignore the Statement element in the root node when the key is selected as a whole. However, if a key shall be used both as independent key and as a branch node in another key, Statement must be defined. In both cases CodedStatements may be used to define statements that are applicable to the entire key (i. e. they are implied in the selection of the key).
[ATTR: key]

Refers to a node in a DesignedKey (e. g. for reticulating keys)

A node in a designed key, containing the lead statement to follow and optionally the next question, or terminating at class identification, subkey, or node reference.

The key attribute for nodes in a designed Key is required because an xs:key constraint exists on this attribute. It seems impossible in xml schema to make existence of keys optional but require those present to be unique and the target of keyrefs that point to these existing keys.

If the user agrees with the statement (expressed as free-form text), then the node will be followed.
(The audience-specific representations provide abbreviations, which in picture keys may be used as alt-text of the image. ExportToken will usually not be used, but a separate type seemed to be unnecessary.)

Statements in coded terminology equivalent to the text in Statement. This information is used when switching between guided and multiple entry keys.

Each state listed in the collection is considered scored when the lead text is followed. Note that in the case of "A or B" statements in the key it is not possible to convert that into coded statements.

Optional question that is answered by the Statement elements in each of the Leads below. Note that in most trad. keys the question is empty and only the alternative statements are written.

The set of alternative
statements (which may
be answers to
QuestionText) 

At least two alternatives leading further on in the key must be provided. This element defines the tree recursively.

Refers to a class name
(in biology a taxon name)
[ATTR: ref]

Refers to another designed key in the Keys section. This feature allows cross references between keys.
[ATTR: ref]

Refers to arbitrary key nodes within the current or other keys, to allow building reticulations into the key. @@ This may need further discussion and testing! Allowing to jump into other keys requires the leads (=node) key to be unique across all keys, not only within a key!@@
[ATTR: ref]

Refers to an entire designed Key (e. g. if a key is referenced as a subkey from within another key)

The term 'Entities' is used to refer to the things that are being described. These may be classes (biology: taxa) or objects ('instances'; biology: specimen).

Note: Classes and Objects contain lists of external Resources, similar to the lists in the Resources section. Entities are separated from Resources because they have such a central role for the descriptive data.

Internal list of class (biology: taxon) names used in the project, each one may optionally link to an external data source. These connectors are reused multiple time in the description.

For biology: Object in a nomenclator
[ATTR: key]

Internal list of objects (biology: specimens) used in the project, each object is either described in free form text, or refers to external data source.

Biology: Object in a collection
(= specimen) or observation
[ATTR: key]

Allows basic character formatting using xhtml elements plus three semantic elements (citationauthor, taxonauthor, taxon; intended to be rendered formatted and for analysis). Note that no further formatting is supported within the semantic elements (taxon etc.).

'Emphasis' logical markup (phrase):
usually rendered italic.

'Strong' logical markup (phrase):
usually rendered bold.

Logical markup: subscript

Logical markup: superscript