wiki-archive/twiki/temp-gjr/BDI/SDD/SchemaChangeLog091EarlyBetaVersions.txt

%META:TOPICINFO{author="GarryJolleyRogers" date="1259118877" format="1.1" version="1.21"}%
%META:TOPICPARENT{name="SchemaChangeLog"}%
---+!! %TOPIC%

<h1>Changes in 0.91 beta 15 (relative to the 0.9 Dec. 1. 2003 release)</h1>

<strong>This is an updated version containing most of the minor changes discussed at the [[SDD2004Berlin][meeting in Berlin]]. Some changes are still pending. 
The current version of the BDI.SDD_ schema can always be found at CurrentSchemaVersion. Please do read through the report of changes, except perhaps for the few trivial at the start. 
Please take a look at the schema to verify that you agree with the changes and that they make sense to you.</strong>

<strong>Note:</strong> I have tried to document changes, but I cannot guarantee that everything is properly documented.
In fact, since <nop>GenerationMetadata and <nop>ProjectDefinition are heavily changed in an attempt to find common
ground between the various GBIF standards (current discussion involves only ABCD so far), I have given up on documenting all detailed changes therein (but some are commented).

<h3>Trivial omissions that were present in 0.9, corrected in 0.91<a name="trivial"/></h3>
   * audiencekey in <nop>ProjectDefinition/Audiences/Audience was specified to have a pattern in the documentation, but the pattern was not defined in the schema, regular expression pattern added to schema 0.91.
   * <nop>RevisionData were required in Description, Keys, and <nop>GlossaryEntries, now made optional.
   * The Keys collection could be missing, or empty (0 to unlimited Key objects), now changed to 1 to unlimited Key objects.

<h3>Non-trivial changes enacted plus proposals not enacted<a name="nontrivial"/></h3>

*Root*
   * In an attempt to converge with ABCD:
      * Document root element changed to <nop>DataSets/<nop>DataSet collection. <nop>DataSet takes the place of the original Document. Multiple "Projects" can now be transported in one file or data stream. This is not urgent for BDI.SDD_, but does not hurt either.
      * <nop>GenerationMetadata changed to <nop>TransformationHistory, conceived as a collection of at least one, possibly multiple Transformation elements. Alternative names: <nop>ConversionHistory, <nop>UBIF.DerivationHistory, <nop>HistoryMetadata, <nop>ContentHistoryMetadata, or <nop>DataHistoryMetadata.

*<nop>ProjectDefinition*
   * Element itself changed to <nop>ProjectMetadata
   * <nop>AudienceSpecificData/Representation split into <nop>Description/Representation and <nop>IPRStatements/Representation.
   * <nop>IPRStatements is a list of various copyright, terms of use, disclaimer, acknowledgment etc. statements (new type common to BDI.SDD_ and ABCD schema). However, this is also present in <nop>TransformationHistory!
   * <nop>ProjectDefinition/HistoryWebAddress dropped. Annotation was: "@@ To be discussed. The idea is that a project may point to a web resource that informs about details about the history of the data (previous versions or a detailed log of changes)." Unless somebody needs it now, I propose that this should be an addition in a later version rather than included in the first release.
   * <nop>ProjectDefinition/Icon moved to new <nop>ProjectDefinition/Description/Representation, thus making it audience specific. 
     Icon (or logos) are not necessarily language independent since they may include text!
   * <nop>ProjectDefinition/WebAddress moved as well, different audiences/languages may be referred to different URIs!
   * _New_ after Berlin meeting: attempt to use across standards (see UBIF.SchemaDiscussion), therefore audience-dependent project Description and IPR-Statements changed to language dependent. Language should simplify the adoption of common framework elements for all TDWG/GBIF standards.
   * _New_ after Berlin meeting: Version structure revised. 
      * Version/PublicationDate changed to <nop>VersionReleaseDate to avoid possible confusion with <nop>LastRevision or data generation date in online situations.
      * A Modifier element added (for beta, rel. candidate, etc.). 
      * Increment removed (because considered application-internal management mechanism, no need for interoperability).
      * Major and Minor left as integers to improve interoperability and comparability (nobody commented on the proposal "change version to string" posed in previous version of the change log.)
   * _New_ after Berlin meeting: The narrative (unconstrained text) elements <nop>GeographicCoverage and <nop>TaxonomicCoverage in <nop>ProjectDefinition|Projectmetadata/Description/Representation combined to Coverage.
      Constrained <nop>ClassScope added, __OtherScope needs a proposal how to link it to other vocabularies. <nop>SourcePublication changed from a single to possibly several, and considered a scoping mechanism as well.
   * _NOTE_: Project Definition could also be called "Envelope". This avoids "project", which is meaningful in BDI.SDD_, but perhaps problematic in ABCD/taxon names?)
   * _QUESTION_: Can project definition be merged with transformation history?)
   * _PROPOSAL_: Need documentation of quality control methods and standards, e. g. 
      * <nop>QualityControlStandard: Name (and version, if applicable) of the published or internally documented quality control standard used.
      * <nop>QualityControlDescription: Free-form description of methods used to ensure the quality of the descriptive data. In the absence of a standard, this should be a short description of the quality control procedures taken.
   * _QUESTION_: <nop>ProjectDefinition/RevisionData/InitiationDate is xml:dateTime and required, which may cause problems in legacy projects. See discussion under InitiationDateForImportedLegacyData. The proposal makes sense in the context of project definition.
     However, <nop>RevisionDataType is also used in several other contexts (single descriptions, glossary, characters, etc.) and the proposal does not make sense there. Do we need two slightly derived types? Has anybody a better idea?

*GeneralDeclarations*
   * New root section "<nop>GeneralDeclarations" created for concepts not specific to BDI.SDD_, but needed in the schema. Alternative names for this section are: 
     <nop>GeneralDefinitions, <nop>OverarchingIssues/Functions, <nop>CrosscuttingIssues/Functions, <nop>GeneralTerminology, <nop>GeneralTerms, <nop>GeneralVocabulary (the latter three do not 
     cover the possible inclusion of "language rules"). The following elements moved there:
      * <nop>ProjectDefinition/Audiences
      * Terminology/<nop>CodingStatusValues
      * Terminology/<nop>UnivariateStatisticalMeasures (was <nop>StatisticalMeasures)
      * (Newly created:) Global definitions for <nop>MeasurementUnits (Character definition Numerical/<nop>MeasurementUnit is consequently changed to a ref type). The optional generalization allows to define relations between units such that two size measures, one expressed in mm the other in cm become comparable.
   * In each of <nop>CodingStatus, <nop>UnivariateStatisticalMeasure, <nop>MeasurementUnit, the "Generalization" element 
     (containing the machine-readable partial semantics of an object) was renamed to Specification.
   * The Audience definitions lang and expertiselevel, previously defined as attributes, have been reorganized to follow the pattern of Label + Specification.
   * The defaultaudience attribute present at Audience was only appropriately placed because all audience definitions were considered part of the project definition.
     Now it is separated and moved to <nop>ProjectDefinition/DefaultAudience.
   * <nop>StatisticalMeasures renamed to <nop>UnivariateStatisticalMeasures (compare Bob's comment on TWIKI about ClosedTopicMultivariateStatistics).
      * Related: the fact that Char. def. Numerical/StatisticalMeasures had both a ref and a key confused several reviewers. To clarify, the key has now been renamed from ref to <nop>GeneralDeclarationRef and both this and the key on <nop>GeneralDefinitions/<nop>UnivariateStatisticalMeasures/<nop>UnivariateStatisticalMeasure is typed as <nop>StatisticalMeasureKeyValue.
      * Element "Dimensionless" added to Specification of <nop>UnivariateStatisticalMeasures (answers whether the measurement unit apply to a statistic or not).

*Terminology*
   * Sequence of sections changed, Terminology section placed after Entities and Resources sections.
   * Terminology/Glossary (= ontology definitions) strongly changed
      * Multiple new ontological relations between terms added and subsumed under a new  Ontology element. This urgently needs review!
      * <nop>SensuLabel and <nop>KindOfTerm added. The first allows to distinguish between multiple definitions of a term (Term does not have to be unique, but Term + <nop>SensuLabel has to be!), the latter categorizes terms (is that doubtful??).
      * With the introduction of <nop>SensuLabel, Term is no longer a keyref in the ontological definitions (synonym, antonym, etc.). Replaced with <nop>TermListType = List of <nop>GlossaryEntryRefType.
      * Ontology now refers to <nop>GlossaryEntry keys rather than Term strings in a specific language. This is partly necessitated by the introduction of a <nop>SensuLabel.
      * As a result, other parts of the <nop>GlossaryEntry (Citations, <nop>RevisionData) have now been made language/audience-independent as well. This also resolves some anomalies, e.g. that <nop>RevisionData were one the audience-specific part instead on the language-independent object as in all other cases in BDI.SDD_.
      * <nop>ExternalReference changed to <nop>ExternalDefinitionURI
   * <nop>CharacterDefType
      * Label changed from <nop>LabelPlusAbbreviationType to <nop>SimpleLabelType. This simplifies the model: Only a single label can be defined at the character level, all extended concepts (abbreviations, export tokens, images) are definable only in concept trees. Since concept trees require a terminal node for each character, the same expressiveness is maintained.
      * Type changed to <nop>MeasurementScale, value list completed to include "ratio".
      * Section Assumptions added to the character definition, <nop>MeasurementScale moved there
      * Categorical and Numerical are tentatively changed to a choice rather than co-occurring. This needs discussion!
      * PlausibilityRange added to numeric character definition. Applies to all values and statistics, except those that are dimensionless (like variance).
   * <nop>GenericStates renamed to <nop>ConceptStates (= states that are present at nodes in the concept tree; this is the only place where <nop>GenericStates 
     was present). "Generic" was considered to be confusing since for biologists it may be understood as referring to states describing a Genus.
   * "Probability modifiers" have been renamed back to "Certainty modifiers" (they were previously called "Uncertainty modifiers" before changing to "Probability". As 
     already discussed in Brazil (but later forgotten), Probability is ambiguous since low occurrence frequency of a state also results in a low probability that a given object has a given character state.
   * Terminology/Modifiers/Sets (intended to define reusable modifier sets which would then be associated with characters) and <nop>CharacterDefType/ModifierSets where both replaced with a new Concept/ApplicableModifiers element in the concept trees. For the modifier sets a key and a label had to be defined so they could be selected in each characters through a keyref. The new solution avoids both the label and the key/keyref mechanism: The concept label also identifies the modifier set, and the characters are already defined by all characters included in a concept branch. The disadvantage is, that some tree-walking is required to find which modifier is applicable to which character.
   * In frequency modifiers "ProbabilityRange" was changed to "CertaintyRange".
   * Frequency and Certainty modifiers changed to now contain the Range definition inside a Specification element. 
   * Concept trees: An organizing element "Specification" added (similar to definitions in <nop>GeneralDeclarations). The types, roles, etc. inside were reorganized and the enumerations changed (e.&nbsp;g., <nop>MethodHierarchy to <nop>InstrumentationHierarchy, <nop>PartHierarchy split into <nop>PartOfHierarchy and <nop>PartGeneralizationHierarchy). Also please critizise the current structure: "DesignedFor/Role=Filtering". Do the element and value names make sense to native speakers? Any better suggestions?

   * _PROPOSAL_: Rename <nop>AutoAddStates to <nop>UpdateStateRefsTriggers (those state from a generic state set must be as <nop>StateReference in Character/Categorical/States). GH: I believe it should be the other way round, i.e. instead of a state-set reference at the character, there should be a list of characters referenced at the place concept node. I have started to do this, but not yet finished! See "####" at the end of the document!
   * _QUESTION_: Allow multiple mappings of fine-grained states to coarse-grained states, and make these mappings expertise-specific (part of audience definition)?
     Do we need multiple state sets within a character? Broad categories and narrow categories? Currently mapping of state is within a single character, and the two state sets need to be detected by application (those present minus those mapped away. Note: mapping can be indirect a-> b-> c, only c should remain.)
     Do we need multiple <em>named</em> mapping definitions in the future? See StateMapping for further discussion.

*Entities*
   * The "connector" metapher was not well received and not considered intuitive. As an attempt, I propose to use a proxy metapher: The proxy object is a local object "standing-in" for the external, often asynchronously available resource on the internet. In programming this is called the "proxy-pattern". As a variation proxy objects may, however, also "stand-in" if no external object can be found and a local object (e.g. in biology: taxon name, specimen) has to be defined. Specific changes:
      * <nop>ResourceConnectorBaseType changed to <nop>ProxyBaseType
      * <nop>ClassNameConnectorType, <nop>ClassHierarchyConnectorType, <nop>DescribedObjectConnectorType, etc. all changed to <nop>...ProxyType
      * Within the <nop>ProxyBaseType, the <nop>FreeFormDescription was changed to Label. For all internal BDI.SDD_ object like characters or states, Label signifies a human readable representation, which is the intent of this data element as well.
      * The ID/external object linking was strongly changed. The previous version (which was never really worked out so far) worked only if the object query could be embedded into a single URI query string, or if the old <nop>ServiceProvider referred to a web service wsdl with a single method and a single parameter. Now the <nop>ObjectLink rather than the old "ExternalID" points to the object in case of a single URI query string. The method and parameter names, and the ID-values are now given separately for web services. Furthermore, ABCD does not plan to provide a single or unified ID for collection units, but uses three separate variables that together uniquely refer to a specimen object. This is supported, but it would still be desirable to have a single ID to simplify ID comparison and distinguish ID from other parameter values that may be required to use a webservice method (but may be constant for different objects).
      * In addition to URL and webservice, tentative support for DOI (digital object identifiers) and <nop>LifeScience ID (LSID) was added (including an LSIDs defining a pattern constraint).
      * _New_ after Berlin meeting: Sequence of Label (= <nop>FreeFormDescription in 0.9) and <nop>ObjectLink changed; Label is now first. This agrees with the use of Label throughout the other parts of the schema (characters, states, etc.).
   * Entities/Classes changed to Entities/ClassNames, //Class to //ClassName. Note: in addition to the <nop>ClassName (taxon name) pointers present we may need alternative pointers into the class concepts (taxon concepts) as present <nop>ClassHierarchy!
   * "<nop>TaxonNameInSource" renamed to "<nop>ClassNameInSource". Related open issue: Combine with Location? Else we need to have a <nop>CitationBaseType without <nop>ClassNameInSource used in Glossary and Keys, and a derived type used in Descriptions!
   * _New_ after Berlin meeting: <nop>ClassIdentification changed to <nop>ClassAssignment; the process will be an identification, but the result is assigning the object description to a class. The term Identification caused confusion in the discussion.
   * Bob pointed out the inconsistency of declaring the standard to be independent of the biodiversity domain (thus using class/object instead of taxon/specimen) and still having taxon, taxonauthor, etc. in UBIF.FormattedText. For the time being I have removed these (they are still preserved in an unused backup version of the type, so they can easily be put back).
   * Similarly, the biology-specific elements Sex and Stage were removed from <nop>ClassNameProxyType (= <nop>ClassNameConnectorType in 0.9; = the type of the proxy object defining links to external name databases).
     BDI.SDD_ assumes that <nop>ClassNameConnectorType in the future will connect to nomenclators or species databases and these are unlikely to provide separate records for sex and stage. It would have been possible to move Sex and Stage to <nop>DescriptionBaseType, but they are required at the end of the diagnostic keys as well (sexes or stages may be keyed out separately!). Thus, a new type <nop>ClassRefWithAdditionalClassifierType has been derived from the <nop>ClassRefType and used for <nop>DescriptionBaseType/Class (which is the basis for coded as well as natural language descriptions) and <nop>StoredKeyDefType/Lead/Class. Furthermore the Object identifications may be sex/stage specific (but also many objects will have multiple stages in a single specimen...). At the moment the new <nop>ClassRefWithAdditionalClassifierType has also been used at <nop>DescribedObjectConnectorType/ClassIdentification.
      * The above mentioned type <nop>ClassRefWithAdditionalClassifierType should be defined generalized, avoiding biology-specific concepts like sex and stage.
      * See SecondaryClassifiersProposal (and earlier: TheProblemOfSex)!
   * <nop>ClassHierarchies was previously restricted to single hierarchy, now allows multiple <nop>ClassHierarchy objects. A <nop>ClassHierarchy is the only way available in BDI.SDD_ to define 
     taxon subsets (character subsets are defined in the <nop>ConceptTrees).

   * _PROPOSAL_: Add an Abbreviation element to Class and Object in Entities? Would not likely be updated by service, but may be useful or even required for reports. Update problem is related to problem with updating the Caption of <nop>MediaResources.

*Descriptions*
   * In coded and natural language descriptions a Header element was introduced to improve the overview and organization of information. 
   * <nop>CharacterData_BaseType/Sequence with values "terminology" or "description" was considered difficult to understand. Bob proposed to replace it with a boolean "<nop>StatesAreOrdered" which has been done.

   * _PROPOSAL_: Rename <nop>CodedDescriptions to <nop>SymbolicDescriptions, see Analytical Philosophy (I only checked the Enc. Britannica, I am no expert in this!)

*Keys*
   * Keys/Key was changed to <nop>IdentificationKey/IdentificationKeys. The term "key" was perceived as too general, causing especially misunderstanding for non-biologists like programmers.
     Instead of the depracated "guided key" other terms are "Pathway key" and "Stored key". "Dichotomous key" is inappropriate.
   * <nop>CodedStatements in Keys (coded terminology equivalent to the natural language key statement) used to be a simple list of states. To accomodate the frequently occurring more complex statements in keys, e. g. "margin of fruitbody yellow (or orange and hairy)" -> i.e. not if only orange, or "margin of fruitbody yellow, never with denticles" -> other surface structures may be present, a boolean operator logic modeled after <nop>MathML has been added to <nop>CodedStatements inside Keys.  
      * Related: Should Boolean logic (not, and, or) be added to any natural language markup?
      * Should guided keys be marked up using the natural language markup method rather than using a separate section, as currently proposed? Currently, the key markup was thought to follow the coded description model, but now it has been extended. Problem: Boolean logic is frequently found in the lead statements of keys, but rarely in natural language taxon descriptions. However, if Boolean logic operators are introduced to both, it would be a strong argument to use the same method in NLD and Keys, rather than having three variants.
      * Alternatively, we may want to extend the <nop>CodedDescriptions and provide Boolean logic operators there as well. This would be a heavy burden on database-oriented descriptive data processing, however. Or can someone provide a simple model how to handle arbitrary logical and/or combinations in a relatively simple database model?

*General*
   * <nop>CitationType: optional <nop>LastVerified and <nop>InvalidSince date elements added, important for volatile online publications.
   * The application-specific data containers (= extension mechanism to store non-BDI.SDD_ data) has been renamed from <nop>ApplicationData/Application to <nop>CustomExtensions/CustomExtension. Several applications may agree on common extensions, in which case the old names would not have been appropriate. The mechanism itself remains unchanged.
   * Model groups like "(Rich)AnnotationGroup" containing only optional elements have been themself made optional. This changes nothing in the validation and schema, but seems to help when using Castor data binding.
   * In the <nop>LabelPlusAbbreviationRepresentationType (used frequently in Label/Representation elements) the Selector element containing media (usually images) was renamed to <nop>MediaResources. This is the same element name used generically throughout the schema. 
      * The name "Selectors" was intended to express that only certain media should be added here - those that are sufficiently informative and concise at the same time to be used as selectors instead of text labels. However, the use of Selector lead to more confusion than clarification, and the purpose of the media is expressed through the Label context, i.e. these are labeling images etc.
      * The only other media resource is Icon which remains semantically labeled.

---

<h1>Open Questions<a name="questions"/></h1>

   * Class names (= taxon names referenced in descriptions or keys) may have to be audience specific! See LanguageSpecificClassNames for a discussion!

   * Descriptions generalization questions, i.e. inferring descriptions from other descriptions:
      * Main.PrometheusII proposes to explictly reference descriptions that are to be included or generalized into a current description. Currently we expect in BDI.SDD_ this to rely on am automatic "description resource discovery" mechanism, i. e. _all_ object descriptions with the same class name are generalized, and classes are generalized to higher classes following the class (taxon) hierachy defined in Entities.
      * <nop>BioLink proposes (correct?) to explicitly flag which characters or states allow generalization, and whether from above or below.
      * (= the first is explicit generalization on the object/class hierarchy level, the second explicit which characters/states are included in generalization.)
      * Related: BDI.SDD_ probably needs a mechanism to mark the results of aggregation/generalization, computed characters, calulated statistics to document whether they are calculated / inherited or directly entered.
      * Related: Do we have to document original terminology labels during data entry (i.e. in the language/audience representation used during scoring). The audience itself may be interesting (as a code), but even more the terminology may have been changed slightly (evolution of terminology) since scoring. A record of score-time representation would increase the trust in the coded scores and allow some backtracking of problems.

   * In Descriptions we call an element <nop>GeographicalScope, in <nop>ProjectDefinition basically the same thing <nop>GeographicalCoverage! However, Descriptions refers to defined objects in Resources, whereas in <nop>ProjectDefinition it is free-form text (modeled directly after <nop>DublinCore). Make this consistent and always use Resources/Geography/Location object references?

   * Problem of storing calculated data and marking them as "autogenerated" (or which term to use?). Related to problem of inheriting information up and down taxonomic tree. Similar problems are already marked up in the "Origin" element in character and NLD data, and in the inherited attribute associated with character ratings. In the case of statistical measures, marking the Origin as calculated would refer to the raw data in an observation set. However, there is some discussion on the Wiki (see RepeatedObservations) whether we need a keyref to exactly one observation set or not.

   * We probably need to have more than one class hierarchy and add a marker to indicate which hierarchy is formal, and which contains non-taxonomic groupings. In Brazil Kevin reported on Lucid providing a "tag" mechanism to mark "silly characters" intended only to group items like "100 worst weed species: yes/no". XPER reported a similar tag mechanism for items (instead of characters as in Lucid) to tags items for specific problems: diseases / quarantine species / disease vectors. To me both kind of problems seem to be most appropriately handled as a non-taxonomic class hierarchy. Any proposals how to handle this? As a first step an additional attribute "IsPhylogenetic" in the class hierarchy is proposed (already done).

   * Glossary:
      * Do we need some method to express ranges for cardinality: How many legs may there be etc.?
      * Do we need some method to associate states with properties/types?

   * Should the natural language markup be brought closer to xhtml by using &lt;span class=""&gt; for markup?

   * Basing character states on concept states (= reuse of state sets in multiple characters) causes problem with order (ordinal scale) characters. The states in a character may be inherited from from multiple concepts nodes. Each of these will probably have order in the concept, but the final order can only be defined in each character. This seems unfortunate.

   * Can we describe images? Is this automatically implied in reversing the association between a description and an image or not? 
     Images may only illustrate parts of the description.

   * Can we format numeric values in reports? See DELTA  *DECIMAL PLACES. How do we format sets of statistical measures in natural language or other reports? The (min-) lowerrange - central - upperrange (-max) format is not necessarily universal. Currently it is nevertheless fixed in application code and cannot be defined by users. Since many variants which individual measures are present exist, this can probably not be done with a <nop>TextBefore/After strategy (possible for Min, Max, but not for ranges with/without mean, "3-6", "5", "3-5-6"). Also, open ranges exist, which should be output as "at least 3 cm long" in natural language. Also: formats are audience/language-specific!
  
   * Can we find a smart method to format related and dependent value like width x length?

   * Using polymorphism for character definitions. Color as separate character type?

   * Media Resource may need a location detail (if figure has multiple labeled fragments). Perhaps call this <nop>FragmentLabel?

   * Media-"FragmentLabels", but even more the "Location" in Citations may be language sensitive! "table 1", "tab. 2", "figure 3" in English, "Abbildung 3" in German etc.!

---

<h1>Problems I believe cannot be solved in xml schema</h1> 

(please tell me if you disagree!)

   * We have a frequently used type that prevents validation of requiredness in BDI.SDD_  schema: Most labels use <nop>FormattedSimpleTextType, which if the element is required should always be non-empty. However, in contrast to simple text strings, <nop>FormattedSimpleTextType allows limited formatting (sup/sub etc.) and has a mixed content model. As a result, it is not possible in xml schema to require the length of it to be at least 1. This may be a case where we have to make a recommendation not to output empty elements, and a requirement that a missing element and an empty element are to be considered identical (applications should not attach different semantics to empty elements).
---
The missing element issue seems approachable by declaring things nillable and allowing xsi:nil="true" to distinguish from the missing case. This arose also in the discussion ResolvedTopicIsDiGIRadequateForBDI.SDD -- Main.BobMorris - 29 Apr 2004 

I cannot follow your argument. The problem I state above is that I cannot constrain the Labels to actually contain a string, the element must be present but may contain nothing. There seems no mechanims in schema to prevent that. I know you warned us against mixed content model! -- Gregor Hagedorn - 3. May.
---

<h3>Appendix, see discussion marked "####" above:</h3>

Current situation in 0.9:
<pre>
Concept
  Concept
     Concept key="123"
       ConceptStates
         StateDefinition key="1"
         StateDefinition key="2"
         StateDefinition key="3"

Char
  Categorical/States/
    StateReference ref="1"
    StateReference ref="2"
    StateReference ref="3"
    AutoAddStates ref="123"
</pre>

Proposed reversal:
<pre>
Concept
  Concept
     Concept key="123"
       ConceptStates
         StateDefinition key="1"
         StateDefinition key="2"
         StateDefinition key="3"
       UpdateStateRefsTrigger
         Character ref="123"

Char key="123"
  Categorical/States/
    StateReference ref="1"
    StateReference ref="2"
    StateReference ref="3"    
</pre>

One reason why this is relevant is that I believe we have to introduce a similar mechanism for <nop>StatisticalMeasures, to allow defining sets of statistical measures centrally (min-max range, a simple range/mean type like DELTA, extensions including variance and sample size, etc.).

Also, we have modifier sets as well. Can we also run them over a concept-node-based system, so that we have very similar systems for States, Measures, and modifiers? That seems to improve the schema. Unfortunately, with modifiers I am uncertain how well this works. Modifiers almost cry for inheritance down the concept tree, something we have not yet done so far!

---

Looking for the most recent schema file? See CurrentSchemaVersion!

-- Gregor Hagedorn - 25 May 2004

%META:FILEATTACHMENT{name="SDD_091beta3.zip" attr="h" comment="SDD 0.91 Beta 3" date="1079962204" path="C:\Data\Desktop\DESCR\TDWG-SDD\Schema\091\SDD_091beta3.zip" size="52796" user="GregorHagedorn" version="1.1"}%
%META:FILEATTACHMENT{name="SDD_091beta6.zip" attr="h" comment="SDD 0.91 Beta 6" date="1082737634" path="C:\Data\Desktop\DESCR\TDWG-SDD\Schema\091\SDD_091beta6.zip" size="57560" user="GregorHagedorn" version="1.1"}%
%META:FILEATTACHMENT{name="SDD_091beta7.zip" attr="h" comment="SDD 0.91 Beta 7" date="1083591586" path="C:\Data\Desktop\DESCR\TDWG-SDD\Schema\091\SDD_091beta7.zip" size="56869" user="GregorHagedorn" version="1.1"}%
%META:FILEATTACHMENT{name="SDD_091beta9.zip" attr="h" comment="SDD 0.91 Beta 9" date="1083773230" path="C:\Data\Desktop\DESCR\TDWG-SDD\Schema\091\SDD_091beta9.zip" size="57050" user="GregorHagedorn" version="1.1"}%
%META:FILEATTACHMENT{name="SDD_091beta10.zip" attr="h" comment="SDD 0.91 Beta 10" date="1084188580" path="C:\Data\Desktop\DESCR\TDWG-SDD\Schema\091\SDD_091beta10.zip" size="58257" user="GregorHagedorn" version="1.1"}%
%META:FILEATTACHMENT{name="SDD_091beta11.zip" attr="h" comment="Beta 11 = Final for Berlin meeting!" date="1084279915" path="C:\Data\Desktop\DESCR\TDWG-SDD\Schema\091\SDD_091beta11.zip" size="77014" user="GregorHagedorn" version="1.1"}%
%META:TOPICMOVED{by="GregorHagedorn" date="1079962486" from="SDD.SchemaChangeLog091EarlyBetaVersion" to="SDD.SchemaChangeLog091EarlyBetaVersions"}%