XML schema to encode descriptive data in biology and other subjects. The primary goal of the design is to increase the knowledge and availability of knowledge about the diversity of life on earth. However, it may be used in many other areas (including medicine, pathology, archeology, anthropology) wherever objects or classes of objects are described for later reidentification.

The schema was designed by the Structure of Descriptive Data (SDD, http://160.45.63.11/Projects/TDWG-SDD/index.html) group. SDD was established 1999 as a subgroup of the Taxonomic Databases Working Group (TDWG, www. tdwg.org) of the International Union of Biological Sciences (IUBS). The author of the current schema version and of all annotations is G. Hagedorn, Berlin. The requirements for an SDD schema where elaborated in 6 major meetings of the SDD group and in discussions over the SDD email list. Over 60 people contributed to these discussions. However, the help, criticism and energy of Bob Morris, Kevin Thiele, Bryan Heidorn, Guillaume Rousse, Steve Shattuck, Donald Hobern, Trevor Patterson and Nicolas Bailly is specially acknowledged!

Copyright © TDWG, 26. June 2004. Licensed under GNU GPL 2 (http://www.gnu.org/licenses/gpl.html) - with the following restriction: This is a preliminary version (0.91!) for testing purposes. Permission to use this schema is granted to all scientific or commercial projects for a testing period of up to 3 years. After this time computer programs using this schema must either be discontinued or converted to the final version of this schema.

Conventions:
Element or attribute names starting with underscores (__) are present in the schema for discussion purposes only and should be only experimentally used. Annotations containing @@ indicate unfinished points of discussion.

Note: blockDefault="#all" in xs:schema prevents substitution and that in instance documents derived types can be used in elements typed to the base type (which otherwise is possible using xsi:type=""). - finalDefault is not set, further type derivation is currently not considered problematic. Please contact us if you believe otherwise. Note that according to the w3c discussion forum, the developers of xml Schema consider to drop the final attribute in the upcoming XML Schema version 1.1. - Nillable: xsi:null is not supported in SDD documents (schema declaration nillable="false" is default, not explicitly stated).

 This imports the UBIF schema file (SDD uses the same namespace as UBIF!). Due to problems with key/keyrefs when using two namespaces (see documentation on the SDD WIKI: http://efgblade.cs.umb.edu/twiki/bin/view/SDD/UBIFDesignRequirements), the SDD schema is based on the UBIF namespace, and thus uses include rather than import! Contains relation IDs derived from the RelationID base type. Used for locally unique identifiers (local to a specific object type). To better communicate the ID scope, for each object type a derived RelationID has been used, although technically this is redundant. DescriptiveData must be placed inside the UBIF top-level Datasets/Dataset structure as the last element. Because of keyref constraints, this schema depends on the imported UBIF root! Descriptive data itself that are specific to SDD, i. e. descriptive terminology, coded and natural language descriptions and stored identification keys. The labels of audience definitions are required and must be unique for a given language. The labels of glossary definitions are required and must - in combination with the SensuLabel - be unique for a given language/audience combination. The key of coding status values must be unique. The labels of coding status values are required and must be unique for a given language/audience combination. Modifier set keys are required and must be unique. The labels of modifier sets are required and must be unique for a given language/audience combination. Modifier keys are required and must be unique regardless of modifier type (certainty, frequency, etc.). The labels of modifier definitions are required and must be unique for a given language/audience combination. Additional character-type-specific key. Additional character-type-specific key. Additional character-type-specific key. The labels of character definitions are required and must be unique for a given language/audience combination. This provides a joint key for states either defined locally within a character (= StateDefinition), or referenced from ConceptStates (StateReference; provides a new local key). This is the only key for them; no separate keys for locally defined/concept reference within the character are defined. Note that state keys are unique across all characters, not only within each character. The labels of concept tree definitions (= entire trees, not the nodes within the trees) are required and must be unique for a given language/audience combination. This collects all keys of Concept elements. Note that no UniqueLabelText constraint is defined for concept tree nodes; the labels on tree nodes are optional and not required to be unique. They are expected to be displayed together with their parents and thus obtain their uniqueness from the context (the path from the root should be unique, but this is not expressed in the schema). Also, the xpath selector selects all Concept elements anywhere in the document, which is more general (and therefore computation intensive) than necessary. A better xpath expression would be Terminology/ConceptTrees/ConceptTree//Concept, which includes all nodes regardless of their place in the tree structure. However, combining a defined path with an "all child" path is impossible under the restrictions imposed on xpath expressions in xml-schema identity constraints. Further, since keyed elements in a tree are collected from the document root rather than from the tree root, the node element names must be unique names in the entire schema. A related problem is that we desire to use the same element name (Concept) for node definitions and references to these nodes (from within NaturalLanguageDescriptions). Although the latter has a ref instead of an id, Schema would normally complain that the id is missing, rather than understanding that only elements possessing a id are to be selected for the xs:key constraint. Using a combined xpath ".//Nodes/Concept" is a solution. It does, however, work only if the id of the root node is not included. Since no reason exists to do so (this id is redundant) we accept this. All concept state id values must be unique in an entire project. Compare ConceptKey. A joint key for all CodedDescription or NaturalLanguageDescription elements. This identifies an entire stored key (i. e. not the nodes/steps in the key) The labels of stored key definitions (i. e. for the entire key) are required and must be unique for a given language/audience combination. This collects all ids of nodes in stored keys (Lead elements). Compare the note on Concept about a potentially better xpath. Within UBIF (Unified Biosciences Information Framework), this represents the node where the SDD-specific data start Default settings etc. = SDD- specific additions to general dataset metadata Default Audience and Concept tree for interactive identification. If configuration data exist at all, at least the default language should be configured! The default language and audience is used whenever the consuming application has no other preference specified. The user interface of the application may start with the default audience representations and then allow to choose a different audience. The default concept tree used to arrange characters in interactive identification. [ATTR: ref] If a class hierarchy is present, the hierarchy used for inheriting and aggregating descriptive data in the class hierarchy must be defined. [ATTR: ref] Defines the operational terminology (parts, characters, states, etc.) in which descriptions are expressed. The terms are defined by the biological specialist(s). They are used in the descriptions through references to their 'id' attributes). General vocabulary lists and rules; applicable outside of the domain of descriptive data. In contrast to enumerated types in the schema, new values and labels for new languages/audiences can be defined. A list of audiences addressed in the project. An Audience is an extension of language (including dialect), esp. with expertise (pupil, beginner, expert). @@ to be discussed! @@ For natural language reporting some rules can be defined per language rather than per audience. If a rule for a language used in an audience definition is missing, applications may add a default language rule to the project data. [ATTR: language, dir] @@This whole sequence is not functional, just a bunch of ideas for discussion! @@ Should for each of Or, And, etc. an entire delimiter-group be defined? @@ Should only 'Or' be defined and 'And' etc. left to the override mechanism available anyways in the concept trees? @@ unclear whether used. DeltaAccess defines on the character level whether states are combined with or, and, to, or with. This has not yet been worked out for SDD! Instead originally SDD attempts to succeed just with delimiters. Combining delimiter rules with conditionally different operators is a problem, however!@@ @@ unclear whether this would be used For states that intergrade: 'red to orange' The words listed in this collection should no be capitalized at the start of a sentence, or decapitalized when sentences are joined. The labels of audience definitions are required and must be unique for a given language ('language' attribute). Defines the semantics and labels of coding status values (e. g., unknown, not applicable, not interpretable). Coding status values (= 'missing data indicators', = 'special states') provide standardized reasons why data are missing. Unlike most elements in Terminology, these are constrained by the SDD model and can only be extended by revising the SDD standard (may be changed to user-definable in a later version of SDD). Labels are already user-definable to support multiple audiences. The labels and abbreviations given are only recommendations. They can be freely changed as long as the semantics are preserved. [ATTR: id] Contains detailed and fundamental terminological definitions (of object/part, object types, property, method, property state, etc.). These are referenced in character, state, etc. definitions, but may also be used independently. The Glossary entry for a single concept (object, method, property, state, etc.), which may be expressed in multiple audience-specific representations. [ATTR: id] The audience values must uniquely identify the Representations within each GlossaryEntry. Certainty, frequency, and other modifiers modify categorical states or statistical measures. Modifiers are defined for the entire project, but must be enabled for characters in concept nodes to be available when editing descriptions Modifiers within a group may be ranked/ordered; in descriptions, modifiers from the same group are combined with 'or'. All modifiers in a group must be of the same type (certainty, frequency, etc.). Characters are the operationalized concepts used in descriptions. They define categorical states and quantitative values or statistical measures. Characters are defined in an unordered flat list. They can be used alone or in combination with modifiers or concept trees. Hierarchies of property, object part, observation methods or other concepts. Concepts can be operationalized by referring to characters (only these allow scoring of data in the descriptions). Concept states (property or kind-of-part, reusable in multiple characters) and char. dependencies are expressed here as well. Concept trees may also be used to define flat character subsets for filtering purposes. @@DISCUSS: should concept tree hierarchies be recursively definable, as long as the resulting tree is acyclical?@@ Importantly, this would allow to define generalization and part-of relations between parts/structures! [ATTR: id] Authored or auto-generated free-form descriptions, which may be completely or partially marked up with elements similar to those in coded descriptions. Note: If all coded markup except the Text content is removed, the original natural language text description can be recovered without changes (lossless). [ATTR: id] Largely language-independent descriptions entirely controlled by Terminology. Both coded and nat. lang. may describe either abstract class concepts (taxon, disease, etc.) or physical objects (individual specimens). [ATTR: id] Dichotomous or multifurcating authored keys (incl. legacy data) (Note: Identification keys may also be created dynamically based on data in terminology and descriptions. These keys are intended to represent only manually authored keys, whether from capturing legacy data or newly designed.) [ATTR: id] ==== TERMINOLOGY START === ==== -- TERMINOLOGY/GENERAL START === The following types are used in the Terminology/General section. They define generic concepts not in principle restricted to the use in descriptive data. --- Audiences are an extension of language/culture codes, to capture expertise and other factors (= registers within a language). An Audience is a combination of an enumerated expertise category (pupil, beginner, expert) and a free-form scope definition. As a result, multiple audiences can be defined for the same expertise, distinguished only by their label. A concise label for the audience; plus optional details clarifying the role / definition of the audience. Properties describing machine-readable partial semantics for an audience definition. ExpertiseLevel is restricted to values from 0-5. These categories allow to communicate expected expertise between different applications using UBIF. Recommended interpretations: 0 = expertise level undefined 1 = elementary school (year 1 to 6); 2 = middle school (year 7 to 10); 3 = high school (year 11 above) and general public (trying to avoid any specialized terminology or jargon); 4 = university students or (partly) trained personnel (using terminology, but avoiding or explaining problematic terminology); 5 = experts (using the full range of terminology). The value that is referenced whenever an audience="..." attribute is used in audience-specific elements. Collection of AudienceDef-type elements [ATTR: audiencekey] The audiencekey string is referenced in all audience specific elements (labels, definitions). Recommendation: audience keys should consist of the expertise level from 0-5 (followed by period-number if a second audience for the same language and expertise level is defined). Examples: '0', '3.12' Audience references are always an optional addition to a language reference! (Note: If audience definitions are present, the audience attribute of AudienceRef should be treated as having a default value pointing to the first audience with expertiselevel=0 (undefined). Setting audience "default=0" in schema (together with the keyref identity constraint on audience) would require all documents to have audience definitions, which was considered undesirable.) --- Coding status allows to express reasons why data are missing (not coded) Project-wide definition of CodingStatus values Properties describing machine-readable partial semantics for a coding status value. Provided to support generic application code that continues to function if additional codes are defined. @@ Both proposals need elaboration and discussion! To be coded / Not to be coded / Cannot be coded / coded successfully NotEvaluated / CannotExist / DoesNotExist / Exists Enumeration used in CodingStatus/Specification. These required values enable applications to interprete user-defined coding status values. To Be Coded -- Information has not yet been entered, but is is planned to do so. Not To Be Coded -- Information has not yet been entered, and is is not planned to do so (esp. because resources are lacking and other characters should have priority). Cannot Be Coded -- Information cannot be entered due to objective (inapplicable character) or subjective (cannot interpret available data) reasons. Coded Successfully -- Information has been entered successfully. Enumeration used in CodingStatus/Specification. These required values enable applications to interprete user-defined coding status values. Not Evaluated -- The presence of information has not yet been evaluated. Cannot Exist -- Information cannot exist for logical reasons (i. e. a character with a coding status having this value is inapplicable). Does Not Exist -- Information should exist, but extensive research has failed to find it. Exists -- Information has already been found, but may not yet have been entered. Refers to CodingStatus values (e. g., from within descriptions) Refers to a CodingStatus value (Terminology/General/CodingStatusValues/Status/@id) ==== -- TERMINOLOGY/GENERAL END === -------------------------------- START Modifiers (uses polymorphism!) --------------------------- The modifier type system covers expressions of certainty, frequency, manner, degree, etc. that can be added to existing character value or state expressions. The modifier system is complex and uses abstract base and derived types both for modifier definitions and for references applying these modifiers to statements in descriptions. Quick overview over the primary entry types: Modifiers are defined in ModifierSet elements. Recommended applicability of sets to characters is defined in the concept trees. Single modifiers are applied to descriptive statements using the PolymorphicModification/PolymorphicModificationMarkup groups. 1. --- Modifier definitions a) Modifiers are grouped into sets because of ranking (ordering) within a set (and for management purposes). All modifiers in a set must be of the same modifier type (e. g., all are frequencies), else ranking would not be meaningful. A set of modifiers of a single type that has a label and may define order/rank.for the contained modifiers Label expressing the concept or scope of each modifier set. All Representations within a Label must have different language values. = 'Modifiers are ranked'. If true, the sequence of modifier elements in instance documents is semantically meaningful (as in 'weakly' - 'moderately' - 'strongly'). If false the sequence is intended for display purposes only. Refers to a ModifierSet, used in ConceptTree//Concept to define recommended modifier sets The ref attribute refers to a modifier set (Terminology/Modifiers/ModifierSet) b) Single modifier definitions. Abstract base type and derived types to be used in instance documents. Note that 'Frequency'Modifier, 'CertaintyModifier', etc. may have been named 'FrequencyModifierDef', etc.; they have been abbreviated to improve the readability of instance documents in case xsi:type would have been used. Abstract base type for state or character modifier definitions (certainty, frequency, etc.) -- Character modifiers: Abstract base type for modifiers applicable to character types in principal Definition of certainty modifiers (perhaps, probably, etc.) An estimate of a probability range for verbal modifiers, defined through two attributes. The upper/lower limits of probability modifiers may overlap. The default values are 0-1, indicating that no estimate was possible. If present and true the current modifier indicates that the state to which it refers is present or true only due to a misinterpretation. The probability range should be 0 to 0 = certainly false. Definition of spatial modifiers (proximal, distal, at base, at tip, etc.) In version SDD 1.0 this element is defined only to support forward compatibility; no specification details are defined for this modifier type yet. Definition of temporal modifiers (earlier, later, in summer, in spring, etc.) In version SDD 1.0 this element is defined only to support forward compatibility; no specification details are defined for this modifier type yet. Definition of character modifiers not yet covered by the categories above (open extension!) -- Categorical state modifiers: Abstract base type for modifiers applicable only to categorical states Definition of frequency modifiers (rarely, usually, etc.) An estimate of a frequency range for verbal modifiers, defined through two attributes. The upper and lower limits of several frequency modifiers may overlap. The default values are 0-1, indicating that no estimate was possible. Definition of modifiers restricted to single categorical statmenents, esp. modifiers/adverbs of degree and manner (strongly, very, darkly, etc.). (Note: the grammatical concept of adverbs of manner often includes the certainty modifiers, which should not be included here!) - (It is expected that this list may have to be extended in future SDD versions, creating additional specific modifier types for those lumped in OtherModifiers) - (Open questions: a) can approximations ('ca.', 'roughly') be handled as CertaintyModifiers or is a separate type desirable? b) should manner, degree, intensity become separate types? c) Specification of spatial and temporal modifiers must be elaborated!) c) Collections of modifier definitions. Abstract base type and derived types to be used in instance documents. The ModifierSet type refers to these collections in a polymorphic way. This allows to define a collection of ModifierSet elements, each set containing multiple modifiers of a single modifier type. Abstract base type of a collection of modifiers of a single type. In instance documents one of the following non-abstract types must be used. (This is an abstract type, specific derived types will be used in instance documents!) [ATTR: id] -- Character modifiers: (Collection; derived from ModifierDefs abstract base type, restricted to specific modifier type) (Collection; derived from ModifierDefs abstract base type, restricted to specific modifier type) (Collection; derived from ModifierDefs abstract base type, restricted to specific modifier type) (Collection; derived from ModifierDefs abstract base type, restricted to specific modifier type) -- Categorical state modifiers: (Collection; derived from ModifierDefs abstract base type, restricted to specific modifier type) (Collection; derived from ModifierDefs abstract base type, restricted to specific modifier type) d) Group combining the various derived collection types into a polymorphic structure (options are an explicit choice or the use of base type plus xsi:type). (General note: Places in the schema where a polymorphic design is intended (different derived types in place of an abstract base type) are highlighted using model groups the name of which starts with 'Polymorphic'. @@If two similar groups names are present in the schema, only the first will be used, the one starting with '__' shows an alternative design!) Collection of modifier definitions of a single type: Point for type polymorphism (multiple derived types in place of an abstract base type) Collection of modifier definitions of a single modifier type. Requires an xsi:type specification in instance documents: "CertaintyModifiers": express the certainty of categorical or statistical statements ('perhaps', 'probably', 'almost certainly'). 'True-by-misinterpretation'- modifiers are included as a special case of 'certainly false'. "FrequencyModifiers": used to describe state frequency (usually, rarely, etc.). In descriptions frequency range estimates can also be stated numerically! "Spatial-/TemporalModifiers": only predefined, no specifications yet! It is believed that specifications may be desirable here in the future. Defining them requires significant work, however. "OtherModifiers": (manner, degree, intensity; e. g., 'strongly', 'weakly'). These convey their specific semantics only to human consumers (or processors parsing and interpreting label text). Collection of modifier definitions of a single type: Point for type polymorphism (multiple derived types in place of an abstract base type) (Unlike most similar poly- morphisms, this is not a collection; each set may occur only once.) Express the certainty of categorical or statistical statements ('perhaps', 'probably', 'almost certainly'). 'True-by-misinterpretation'- modifiers are included as a special case of 'certainly false'. Only predefined, no specifications yet! It is believed that specifications may be desirable here in the future. Defining them requires significant work, however. Only predefined, no specifications yet! It is believed that specifications may be desirable here in the future. Defining them requires significant work, however. Other, so far untyped modifiers of manner, degree, intensity (e. g., 'strongly', 'weakly'). These convey their specific semantics only to human consumers (or processors parsing and interpreting label text). Used to describe state frequency (usually, rarely, etc.). In descriptions frequency range estimates can also be stated numerically! Modifiers of degree or manner, specific to categorical states (very, strongly, etc.). 2. --- Simple Modifier references (used in coded descriptions). a) Abstract base types Abstract base type for an actual modification of a statement. In instance documents the following derived types will be used, either referring to a defined modifier category, or giving explicit numerical ranges/values. Refers to a any kind of modifier definition type (Terminology/Modifiers/ModifierSet/*/Modifier/@id) Abstract base type including all references to CharacterModifierDef Abstract base type including all references to StateModifierDef Abstract base type, adding ProbRangeAttributeGroup. Currently used only for Frequency modifiers, where exact frequency values may optionally be given in descriptions. (Attribute modeling group used in StateModificationPlusProbabilities/Markup. In theory the attributes could be inherited from UBIF complex type ProbabilityRange, but this would require multiple inheritance!) Lower value of a probability range (values 0 to 1 inclusive). Note: to specify a single, exact value set both lower and upper attributes to this value! Upper value of a probability range (values 0 to 1 inclusive). Note: to specify a single, exact value set both lower and upper attributes to this value! b) Derived types to be used in instance documents. Note that 'Frequency', 'Certainty', etc. may have been named 'FrequencyModifierRef', 'CertaintyModifierRef', etc.; they have been abbreviated to improve the readability of instance documents in case xsi:type would have been used. -- Reference to character modifiers: Refers to a certainty character modifier Refers to a certainty modifier (Terminology/Modifiers/ModifierSet/CertaintyModifiers/Modifier/@id) Refers to a spatial character modifier Refers to a spatial modifier (Terminology/Modifiers/ModifierSet/SpatialModifiers/Modifier/@id) Refers to a temporal character modifier Refers to a "Temporal" modifier (Terminology/Modifiers/ModifierSet/TemporalModifiers/Modifier/@id) Refers to a character modifier not covered by the types above Refers to an "OtherModifer" modifier (Terminology/Modifiers/ModifierSet/OtherModifers/Modifier/@id) -- Reference to categorical state modifiers: Refers to a frequency modifier (e. g., from within categorical character data) Refers to a Frequency modifier (Terminology/Modifiers/ModifierSet/FrequencyModifiers/Modifier/@id) Refers to a state modifier (e. g., from within categorical character data) Refers to an "StateModifer" modifier (Terminology/Modifiers/ModifierSet/StateModifiers/Modifier/@id) c) Groups combining the various derived types into a polymorphic structure (options are an explicit choice or the use of base type plus xsi:type). Modifier reference in CodedDescr.: Point for type polymorphism (multiple derived types in place of an abstract base type) (The element sequence in instance documents is informative!) Abstract modifier reference, applying a modifier to a descriptive statement. In instance documents a specific derived type must be used. [ATTR: ref] Modifier reference in CodedDescr.: Point for type polymorphism (multiple derived types in place of an abstract base type). In object-oriented programming the following choice should be replaced with a polymorphic design, using a collection of the common base type! (The element sequence in instance documents is informative!) [ATTR: ref (= for all elements above)] Modifier reference or value in CodedDescr.: Point for type polymorphism (multiple derived types in place of an abstract base type) (The element sequence in instance documents is not informative!) Abstract modifier reference, applying a modifier to a single categorical state. In instance documents a specific derived type must be given (e. g., xsi:type = 'Frequency'). [ATTR: ref, and depending on derived type: lower/upper] Modifier reference or value in CodedDescr.: Point for type polymorphism (multiple derived types in place of an abstract base type) Currently limited to a single frequency and modifier per state, in an explicit attempt to simplify the SDD data model! [ATTR: ref (= for all elements above)] Public notes or comments, for multiple languages. Applications may, e. g., report the text in brackets after the character state. The audience values must uniquely identify the Representations within each Note element (no duplicate audience allowed). Flag states, which applications may use as a template for new descriptions. Templates may be categorical states or coding status values (but currently not measures). Rules for finding templates: a) For class description (i. e. using Header/ClassName) find all higher classes (according to ClassHierarchy) and copy the template states from there. b) For unit/object description (Header/Unit) find the Class assigned to the Unit and copy template states directly from this class (@ and higher classes?). It is expected that the scoring is revised by an expert; thus template states may be defined in cases where they apply only to the majority of subclasses. @@Can this perhaps be handled by new kind of CodingStatus instead?@@ 3. --- Modifier references extended with Text element (used in natural language markup). a) Abstract base types Abstract base type adding a Text element for markup Abstract base type including all references to CharacterModifierDef Abstract base type including all references to StateModifierDef Abstract base type, adding ProbRangeAttributeGroup. Currently used only for Frequency modifiers, where exact frequency values may optionally be given in descriptions. b) Derived types to be used in instance documents. Note: each of the derived types could alternatively be derived from the simple reference (CertaintyMarkup from Certainty, etc.). To allow a polymorphic collection of any markup modifier type, all are derived from the abstract StatementModificationMarkup type, however. The derivation by restriction currently changes only the annotation of the ref attribute! To make it more specific, a future schema version could use modifier-specific simple types derived from ModifierRelationID as types of the ref attribute. -- Reference to character modifiers: Variant of Certainty (modifier reference), with Text inside. Refers to a Certainty modifier (Terminology/Modifiers/ModifierSet/CertaintyModifiers/Modifier/@id) Variant of Spatial (modifier reference), with Text inside. Refers to a Spatial modifier (Terminology/Modifiers/ModifierSet/SpatialModifiers/Modifier/@id) Variant of Temporal (modifier reference), with Text inside. Refers to a "Temporal" modifier (Terminology/Modifiers/ModifierSet/TemporalModifiers/Modifier/@id) Variant of OtherMod (modifier reference), with Text inside. Refers to an "OtherModifer" modifier (Terminology/Modifiers/ModifierSet/OtherModifers/Modifier/@id) -- Reference to categorical state modifiers: Variant of Frequency (modifier reference), with Text inside. Refers to a Frequency modifier (Terminology/Modifiers/ModifierSet/FrequencyModifiers/Modifier/@id) Variant of StateMod (modifier reference), with Text inside. Refers to an "OtherModifer" modifier (Terminology/Modifiers/ModifierSet/StateModifers/Modifier/@id) c) Groups combining the various derived types into a polymorphic structure (options are an explicit choice or the use of base type plus xsi:type). Modifier reference in NLD: Point for type polymorphism (multiple derived types in place of an abstract base type) (The element sequence in instance documents is informative!) Abstract modifier reference, applying a modifier to a descriptive statement. In instance documents, a specific derived type must be specified (e. g., xsi:type = 'FrequencyMarkup'). [ATTR: ref, and depending on derived type: lower/upper] Modifier reference in NLD: Point for type polymorphism (multiple derived types in place of an abstract base type) (The element sequence in instance documents is informative!) [ATTR: ref (= for all elements above)] Modifier reference or value in NLD: Point for type polymorphism (multiple derived types in place of an abstract base type) (The element sequence in instance documents is informative!) Abstract modifier reference, applying a modifier to a descriptive statement.In instance documents, a specific derived type must be specified (e. g., xsi:type = 'FrequencyMarkup'). [ATTR: ref, and depending on derived type: lower/upper] Modifier reference or value in NLD: Point for type polymorphism (multiple derived types in place of an abstract base type) (The element sequence in instance documents is informative!) [ATTR: ref (= for all elements above)] -------------------------------- END Modifiers --------------------------- ==== GLOSSARY START === Glossary entries are largely (but not exclusively) defined by audience-specific representations An entry in the terminological glossary, providing an attribute "id" by which the entry can be referred to. Audience-specific representations of a glossary entry. All audience-specific versions must define the same concept. If, for example, a fructification would be considered a 'berry' in French but not in Chinese (i. e. the definitions have different widths) and both concepts are used in different descriptions in a project, these concepts must be placed in different GlossaryEntry elements (not in different Representations).The different concepts could still be translated the to other languages (term allows phrases as well as words). [ATTR: audience] Multiple citations (publication + page number) Creators, Revision status, and dates of this audience-specific glossary definition. Constrained vocabulary (Structure, PropertyTerm, FunctionalConcept, MethodOrProcedure, ChemicalCompound, Modifier, NomenclatureTerm, OtherTerm) @@ Please comment on necessity of this! @@ Ontological relations General relations between terms Kind-of or is-a relationship (class inheritance hierarchy). This may inform about structures (a sepal is a kind of leaf), properties (metallic color is a kind of color, 2-dimensional shape is a kind of shape), property states (ochre is a kind of brown, subglobose is a kind globose), functional terms (anther is kind-of sexual organ) etc. {directional!} Each concept term may occur only once in the collection. Terms that have identical or nearly identical definition (e. g., technical terminology and plain English equivalent). {bidirectional} Each concept term may occur only once in the collection. A term of opposite meaning. Usually a single term, but may refer to two synonymous terms. {bidirectional} Each concept term may occur only once in the collection. Related concepts and terms. Used to express unspecific relations not yet expressed in the previous relationships. The list of related terms may also be viewed as a keywords list! {bidirectional} Each concept term may occur only once in the collection. Misinterpretations are especially interesting to improve error tolerance in identifications. May refer to structure and property terms. Example: Cyathium is misinterpretable-as flower. @@?? necessary in addition to structural kind-of relations? {directional} Each concept term may occur only once in the collection. (applicable only to parts/structures) Part-of (= aggregation) relationship (class composition hierarchy). Notes: Both KindOf and PartOf relationships define 'broader terms'. Multiple part-of parents are possible if different composition concepts exist. {directional!} Each concept term may occur only once in the collection. Only for structures. Example: The thumb is adjacent to the index finger, connected to the palm of the hand, and part of the hand. {bidirectional} {@@This term seems to be particularly problematic and will not be included in the first release of SDD} Each concept term may occur only once in the collection. Only for structures. Example: The thumb is adjacent to the index finger, connected to the palm of the hand, and part of the hand. {bidirectional} Each concept term may occur only once in the collection. Developmental and evolutionary relations To express developmental (temporal, = "develops from") processes that change one structure into another. Examples: seedling develops-from seed; zygote develops-from male and female gametes (i. e. multiple parent terms).{directional!} Each concept term may occur only once in the collection. All children and the parent are homologous. Usually applied to structure terms. {directional} Each concept term may occur only once in the collection. Used as an alternative to Phyl.- DerivedFrom if no ancestral term is available. {bidirectional} Each concept term may occur only once in the collection. Audience-specific definitions primarily aimed at human consumption, but with the intent to be useful to computer linguistic ontological agents as well. The head term (phrase of one to several words) representing the concept (structure, property, method, modifier, character, state, etc.) that is being defined. If different definitions exist for a term (e. g., following different scientific schools), a distinguishing label (to be added after Term + "sensu") should be provided. @@ alternative names for element: ConceptLabel, ConceptQualifier?@@ @@ConceptLabel has been added to the UNIQUE definition, but needs testing what happens when missing. Will terms still be required unique? Definition text, explaining the concept (meaning, semantics) of a structure, character, state, etc. A single paragraph long; but new line (
) may be used. Optional URI of an external definition, in addition to the internal Definition above. Audience-dependent resources used in the definition (e. g., images with text, videos with speech, or images intended for audiences of different expertise). Each media resource may occur only once in the collection. Refers to a Glossary entry (e. g., from tree nodes or character states) Refers to a glossary entry (Terminology/Glossary/GlossaryEntry) GlossaryEntry reference. Note: a model group is used so that the keyref identity constraint may be defined only once in a central place. Schema 1.0 does not allow to define keyrefs on types, only elements! Reference to the definition of term or concept in the glossary. This glossary entry may provide definitions for multiple audiences and may include media resources like images. [ATTR: ref] (This identity constraint is placed on a global element!) Collection of glossary entries (identified by their id) Defines the type of a concept tree (list of enumerated values to support application interoperability). ==== GLOSSARY END === -------------------------------- START Characters and dependent objects (states, statistical measures) --------------------------- 1. --- Character definitions (characters = data recording and analysis variables, depending on observed part, property, and observation or measurement methodology) a) Abstract base type and derived types to be used in instance documents. Defines a character in the terminology. Abstract base type, one of the extensions below must be used in instance documents Only a simple label for presenting characters in a flat list is defined here. (Abbreviated char. labels for tabular reports, natural language wordings, etc. can be defined in concept trees!) All Representations within a Label must have different language/audience values. Meta information, rating characters under various aspects. Intended to guide a best- next character algorithm. # Derived from AbstractCharacter to be used in instance documents (non-abstract type). Categorical data include nominal and ordinal data (DELTA types UM/OM and NEXUS types). Other terms for categorical data in statistics are 'qualitative data' or 'attributes'. The term 'attribute' has been avoided in SDD because it has different definitions in statistics, programming, databases, DELTA, etc. Both 'qualitative' and 'attribute' are ambiguos as to whether ordinal/ ranked variables are in- or excluded. Extension of the common character properties with those specific to categorical data (= 'states'). An optional specification of the kind of categorical character variable. The available measurement scales are 'nominal', and 'ordinal'. The distinction between linear ordering and other kinds of ordering is made separately! Any categorical variable can assume only a limited number of discrete values. Thus data recorded in a CategoricalCharacter are always discrete (= discontinous or meristic). However, the measured property may either be naturally discrete ('male/ female', 'aseptate/ uniseptate/ biseptate/muriform'), or it may be continuously varying and partioned into into discrete categories ('no/few/many hairs', 'orange to red'). Only in the latter case the between-operator can be used on neighboring states. Some characters may have complex states relations (trees) or the homology of multiple state may be unknown. A conservative phylogenetic analysis may want to treat each state as a separate column with a binary coding of presence/absence of a specific state value. What would be a good term for this? AnalyzeStatesSeparately AnalyzeStatesAsPresentAbsent TreatStatesAsIndependentVariablesInAnalysis Mappings between categorical states (e. g., subovate may be mapped to ovate to simplify identification choices). Each mapping defines a source and a destination state. Both From and To may point multiple times to the same state, but the combination From + To must be unique. Both state must be defined in the current character (validated through identity constraint!) [ATTR: ref] Both To and From should point to a different character than the current (not validated). No explicit character reference is required, since state references are unique within a dataset. [ATTR: ref] A state may be mapped to multiple other states in the same character, or multiple states may be mapped to a single state, but the combination of From and To may only occur a single time. (States are defined outside the type specific tree, since categorical states may be present in addition to numerical data) (The element sequence in instance documents is informative!) Local definition of a state [ATTR: id] Reference to a single concept state (as defined project-wide at a concept tree node); extended with an id definition so that the state in the context of the current character can be referred to from descriptions. [ATTR: id, ref] References to project-wide defined ConceptStates (defined at the nodes of concept trees) must be unique within each character. This is achieved by a uniqueness constraint (local to each character) on the ref attribute of StateReference. The id attribute is already unique through the general CharacterStateKey. The labels of character state definitions are required to be unique within each character and audience definition. Note that this includes both the locally defined states and the referenced concept states. # Derived from AbstractCharacter to be used in instance documents (non-abstract type) Quantitative data include data like the DELTA types IN/RN. They are not supported by NEXUS. Extension of the common character properties with those specific to numerical measurements Especially including a more detailed measurement scale. --- Note: Unlike the states in categorical characters, the applicability of statistical measures to a character is not defined in the character. Any measure used in a description constitutes valid information. However, a list of recommended measures for sets of characters may be defined in concept nodes. An optional specification of the kind of numerical character variable. The numeric scales are 'interval', and 'ratio'. Interval differs from Ratio that the 0-value is an arbitrary point (e.g. in °C/°F) so that ratios should not be calculated. If true, an application may issue a warning if sample measurements are not integer. Note that most statistical measures are real values for integer data (min/max/TotalRange being exceptions).