Project

General

Profile

CdmVersionTwoDiscussion » History » Version 67

Helene Fradin, 04/24/2009 05:36 PM

1 2 Andreas Müller
{{>toc}}
2
3
4
5
6
# CDM v2.0 Discussion
7
8
9
10
11
----
12
13 4 Andreas Müller
_This is a site to discuss possible changes to the [CDM v1.4](http://wp5.e-taxonomy.eu/cdm/v14/) to go into CDM v2.0_
14 2 Andreas Müller
15 40 Helene Fradin
_See also Component C5.80 - Review of CDM v.1 and model for descriptive data in CDM v.2_
16 2 Andreas Müller
17 40 Helene Fradin
18 2 Andreas Müller
----
19
20
21
22 61 Andreas Müller
## Taxonomic Data
23
24
25 63 Andreas Müller
26
### Separation Of Taxonomic Concept And Taxonomic View
27 61 Andreas Müller
28
29
There is a need to separate taxonomic concept information from taxonomic view information resulting in the new classes TaxonomicView and TaxonNode.
30
31
32 65 Andreas Müller
![](CdmTaxonomicView:taxonomicView.png)
33 62 Andreas Müller
34 61 Andreas Müller
See [taxonomic view](http://dev.e-taxonomy.eu/trac/wiki/CdmTaxonomicView) for further information.
35
36
37
38 10 Helene Fradin
39 8 Helene Fradin
## DESCRIPTIVE DATA - PROPOSED REVISIONS
40 3 Andreas Müller
41 1 Andreas Müller
42 10 Helene Fradin
43
----
44
45
46 37 Helene Fradin
47 10 Helene Fradin
## 1. MAJOR - Character/Descriptor/Feature concept
48
49
50 30 Helene Fradin
 **Impacted objects: Feature** 
51 6 Helene Fradin
52 1 Andreas Müller
53
The Feature class is described in the class comments by: "The class for individual properties (also designed as character, type or category) of observed phenomena able to be described or measured."
54 7 Helene Fradin
55
56 30 Helene Fradin
 **a. Issues** 
57 8 Helene Fradin
58 31 Helene Fradin
59 15 Helene Fradin
It is very interesting that the object Feature is not typed such as Characters in SDD (Categorical, Quantitative, etc.) or many other models. However, if the information is needed as to what kind of data is supported by a certain Feature, it is not clearly stated how to understand and use the different attributes. Moreover, there are a dozen categories of Features (Additional Publication, Image, Cultivation, Description, ...) that are rich but difficult to interpret in the case of the import.
60
61
62
As a reminder, below is the list of the Feature class attributes:
63
64 16 Helene Fradin
   - supportsTextData -> feature can be described with TextData objects
65 15 Helene Fradin
66 16 Helene Fradin
   - supportsQuantitativeData -> feature can be described with QuantitativeData objects
67 15 Helene Fradin
68 16 Helene Fradin
   - supportsDistribution -> feature can be described with Distribution objects (geographical)
69 15 Helene Fradin
70 16 Helene Fradin
   - supportsIndividualAssociation ~~> feature can be described with IndividualsAssociation objects (between the described specimen and a second one -~~ for instance a host, only for SpecimenDescription)
71 15 Helene Fradin
72 16 Helene Fradin
   - supportsTaxonInteraction ~~> feature can be described with TaxonInteraction objects (between the described Taxon and a second one -~~ for instance a parasite, a prey or a hybrid parent, only for TaxonDescription)
73 15 Helene Fradin
74 16 Helene Fradin
   - supportsCommonTaxonName -> feature can be described with CommonTaxonName objects 
75 15 Helene Fradin
76 16 Helene Fradin
   - recommendedModifierEnumeration -> set of TermVocabulary containing the Modifier objects recommended to be used for DescriptionElementBase elements
77 15 Helene Fradin
78 16 Helene Fradin
   - recommendedStatisticalMeasures -> set of StatisticalMeasure recommended to be used in case of QuantitativeData
79 15 Helene Fradin
80 16 Helene Fradin
   - supportedCategoricalEnumerations -> set of TermVocabulary containing the list of possible State to be used in CategoricalData
81 12 Helene Fradin
82 17 Helene Fradin
83
The flexibility of the Feature class is not a problem for the import of SDD descriptive data: for each character, a new DESCRIPTION Feature instance is created:
84
85
   - for SDD CategoricalCharacter, supportedCategoricalEnumerations is set with the states defined in SDD in the elements StateDefinition
86
87
   - for SDD QuantitativeCharacter, supportsQuantitativeData is set to true.
88
89
   - for SDD TextCharacter, support supportsTextData is set to true.
90
91 19 Helene Fradin
   - SDD SequenceCharacter: so far, this data are not imported and I don't have an SDD example of this element being used. I guess it should be imported in a Sequence object?
92 18 Helene Fradin
93
94
However, exporting SDD data raises questions about the object Feature. I can see 3 different problems:
95
96
1. There is no safeguard to ensure that DescriptionElementBase objects used for a description tally with the way the corresponding Feature has been described (for example, a DescriptionElementBase associated with a Feature that has only information on supportedCategoricalEnumerations, could be of the type QuantitativeData).
97
98
1. The SDD standard and most descriptive models require the definition of a descriptive system (list of characters, potential states, potential measures) before expressing the strutured descriptions through this descriptive system. It is difficult to export properly this descriptive system to SDD: I can either export all the Feature (but most of them will be non relevant to the exported descriptions), or I can create the descriptive system by scanning all descriptions to extract only characters that are effectively used in the concerned descriptions (loss of efficiency).
99
100 22 Helene Fradin
1. In SDD, categorical states do not have to be defined at the Character level, they can be defined at a more general level and shared. Therefore, the supportedCategoricalEnumerations could well be empty: how do we know then that it supports StateData?
101 17 Helene Fradin
102 12 Helene Fradin
103 30 Helene Fradin
 **b. Example** 
104 31 Helene Fradin
105 19 Helene Fradin
106
If we consider the feature (character/descriptor in other models) "Leaf length". Below are examples corresponding to each problem described above:
107
108 1 Andreas Müller
1. A new Feature Instance names "Leaf length" is created with the attribute supportsQuantitativeData set to true and supportedCategoricalEnumerations set to null. It is still possible to create a DescriptionElementBase of type CategoricalData with the attribute feature set to "Leaf length" feature, and for example, the attribute states set to a list of StateData containing one item {"small"}. -> A feature described as a quantitative feature is used as a categorical feature.
109 23 Helene Fradin
110 19 Helene Fradin
111 21 Helene Fradin
1. Exporting 2 descriptions from the CDM, which contain only 1 DescriptionElementBase, such as:
112 19 Helene Fradin
113 1 Andreas Müller
Viola hederacea -> Leaf Length (mm) -> {Min = 2.3, Mean = 5.1, Max = 7.9, SD = 1.3, N = 20}
114 19 Helene Fradin
115 21 Helene Fradin
116 1 Andreas Müller
Viola betonicifolia  -> Leaf Length (mm) -> {Min = 2.9, Mean = 5.3, Max = 7.4, SD = 1.3, N = 21}
117 19 Helene Fradin
118 21 Helene Fradin
119 19 Helene Fradin
There might be other Feature instances stored in the CDM ("Leaf complexity", "Body shape", "Flattening of body", ...) related or not to the descriptions of such plants.
120 1 Andreas Müller
121 22 Helene Fradin
Therefore, when exporting the descriptive system, either there will be a majority of non-used features exported, if all feature are exported, or descriptions will have to be scanned one by one to detect only effectively used ones. For the last solution, it is ok with this simple example, but if with potentially hundreds of descriptions and hundreds of characters, the complexity increases quickly.
122 1 Andreas Müller
123 22 Helene Fradin
1. The states "small", "medium", "large" could be defined as DescriptiveConcept elements in SDD and the CategoricalCharacter "Leaf length" could contain no StateDefinition elements, using the stated defined more generally in CodedDescriptions. In this case, when the character "LeafLength" is imported, a Feature with no supportedCategoricalEnumerations is created. This Feature type is undefined while it supports CategoricalData.
124 1 Andreas Müller
125 22 Helene Fradin
126 30 Helene Fradin
 **c. Current solution** 
127 1 Andreas Müller
128 22 Helene Fradin
129 26 Helene Fradin
For now, all Feature instances are exported.
130 1 Andreas Müller
131
132 30 Helene Fradin
 **d. Proposed change (NOT IMPLEMENTED)** 
133 21 Helene Fradin
134
135 26 Helene Fradin
I think there should be a distinction within Feature attributes, between the type of data supported by the Feature (supportsTextData, supportsQuantitativeData, etc.) and the domain of possible values or frame of reference (recommendedStatisticalMeasures, supportedCategoricalEnumerations).
136 1 Andreas Müller
137 26 Helene Fradin
In practical terms:
138
139 41 Helene Fradin
   - I would add a boolean to the attribute: 'supportsCategoricalData' *(IMPLEMENTED)*,
140 26 Helene Fradin
141
   - I would remove the domain of possible values (recommendedModifierEnumeration, recommendedStatisticalMeasures, supportedCategoricalEnumerations) and create a new class that we could call for example PossibleValues or RecommendedValues from which would inherit RecommendedModifiers, RecommendedStates, and RecommendedStatisticalMeasures.
142
143
   - I would add an attribute (e.g. PossibleValuesDomains) that would be a Set<RecommendedValues>).
144
145
146
It doesn't prevent problem 1 from happening but at least it clarifies the typing of Feature objects: it is set only through the boolean attributes 'supports...'.
147
148 27 Helene Fradin
It doesn't resolve problem 2. I would suggest to attach an DescriptiveSystem object to a DescriptionBase object (see item 6).
149 1 Andreas Müller
150 42 Helene Fradin
It resolves problem 3. The typing of the Feature will only depend on the boolean attributes.
151 1 Andreas Müller
152 42 Helene Fradin
153 48 Helene Fradin
[[Gregor|Hagedorn - 27/02/2009]] One comment on PossibleStatisticalMeasures: at this point both SDD and CDM take the position that all statistical measures known to the system are in principle valid data and thus allowed. At the same time, the designer of a matrix has a valid interest to make a choice of preferred measures. This is the reason why we speak of "recommendedStatisticalMeasures". Example: Leaf Length, Kurtosis = 2.3 is just as valid a statement (although highly unlikely) as Leaf Length, mean = 12.3. However: Flower color = Long is simply wrong. Thus the strict enforcement of possible states.
154
155
The base class seems reasonable, I would, however, recommend renaming it from PossibleStates to AvailableStates.
156
157
158
[[Andreas|Müller - 27/02/2009]] The PossibleValues class seems reasonable to me but instead of having subclasses all having the same structure we could use Java generics instead 
159
160
161 50 Helene Fradin
Class PossibleValues<T implements IPossibleValue>{
162
163 51 Helene Fradin
 Set<T> supportedValues;
164 50 Helene Fradin
165
}
166 48 Helene Fradin
167
168 53 Helene Fradin
and/or something similar for the Vocabulary based supported values and IPossibleValue implemented by all relevant classes like MeasurementUnit and StatisticalMeasure
169
170
171
[[Hélène|Fradin - 23/03/2009]]
172
173
174
The updated proposed change (*NOT IMPLEMENTED*) is summarized in the diagram below.
175
176
Two new classes are suggested:
177
178 56 Helene Fradin
- AvailableValues: makes it possible to express a frame of reference of values (e.g. an extensive range of colors). The 4 types of values that can be listed all implement a new interface: IAvailableValue. It inherits from TermBase, so that it can be described through the attribute representations.
179 53 Helene Fradin
180 56 Helene Fradin
- RecommendedValues: makes it possible to list the values that can be used in a certain context (e.g. for a group of taxa and a specific feature, only a limited range of colors can be used). It can reference an AvailableValues instance that corresponds to the larger frame of reference (e.g. a standard range of colors). It inherits from IdentifiableIdentity: a title could be enough to describe this specific set.
181 48 Helene Fradin
182
183 67 Helene Fradin
[!AvailableValuespng!|[Hélène Fradin - 24/04/2009]]
184 66 Helene Fradin
185
186
Addition of a new attribute for Feature: recommendedMeasurementUnits (*IMPLEMENTED*).
187
188 12 Helene Fradin
189
190
----
191
192
193
194 32 Helene Fradin
## 2. HIGHLY CRITICAL - Mixed properties associated with mixed objects
195 12 Helene Fradin
196 1 Andreas Müller
197 33 Helene Fradin
 **Impacted objects: all objects inheriting from VersionableEntity** 
198 1 Andreas Müller
199 32 Helene Fradin
200 33 Helene Fradin
 **a. Issue** 
201 32 Helene Fradin
202 1 Andreas Müller
203 40 Helene Fradin
[[Helene] Some very useful properties are available only for a restricted number of objects I found that extremely hard when importing SDD data into the CDM because I sometimes needed a property that I knew existed for other objects but was not available for the considered object|[Gregor]] I find your observation about the limitation that "essential general properties (title, description, media and original sources) are available only for a restricted number of objects" very interesting. I had some discussions with Markus, trying to get him on erring on the side of allowing sometimes a property which is only necessary under very special use cases, rather than custom tailoring properties to the currently perceived needs. I can understand that Markus wanted to have a clean model, but since in SDD we started doing this, and in the end found that more and more things are shared, we at some point decided to move quite a bit (I am not claiming the fully correct bit) into the abstract  base classes.
204 1 Andreas Müller
205 40 Helene Fradin
The "precision" aimed at, is also in my view responsible to the deep class hierarchy, which hinders a ready understanding of the model. From the UML it is difficult  to derive which properties some derived classes have, because all inheritance layers contribute.
206 1 Andreas Müller
207 40 Helene Fradin
208 34 Helene Fradin
 **d. Proposed change (NOT IMPLEMENTED)** 
209
210
211
I think these properties should be made generic, therefore available at a higher level.
212
213
The specific attributes I am thinking of are: **representations** (Set<Representation>), **media** (Set<Media>), **sources** (Set<OriginalSource>).
214
215
To implement this, I can see 2 solutions: a drastic one and a less drastic one.
216
217
218
   - drastic (directly inspired from the use of the SDD Representation element) : the problem is that it would impact the CDM at a high level so I am probably overlooking important issues raised by this.
219
220
It consists in having these attributes at the level of the VersionableEntity object. However, as the Representation, Media and OriginalSource classes all inherit from VersionableEntity, they should be removed from this hierarchy of objects and defined independantly.
221
222
The new VersionableEntity attribute would be: 
223
224
   representations: Set<Representation>
225
226
and the Representation object, defined independantly, would contain media and sources as attributes.
227
228
In parallel, redundant attributes in lower classes could be removed.
229
230
Therefore, any CDM object inheriting from VersionabeEntity could be represented in the same way: a title and a description (possibly available in several languages), one or several images attached to the object, and one or several sources.
231
232
233
   - less drastic: to make available these properties largely, they could be put back up in the hierarchy.
234
235
I would suggest:
236
237
     > adding to TermBase: sources + media
238
239
     > adding to Media: representations
240
241
     > adding to ReferencedEntityBase: media
242
243
     > adding to IdentifiableEntity: representations + media
244
245
     > adding to FeatureNode: representations + media + sources
246
247
     > removing media from DefinedTermBase
248
249
     > removing media from DescriptionElementBase
250
251
     > removing media from IdentifiableMediaEntity
252
253 32 Helene Fradin
254 54 Helene Fradin
[[Andreas|Müller - 27/02/2009]] I clearly see your point that you needed some attributes but they were not available due to the class hierarchy. Anyway I think to have too many attributes at the very high levels makes thinks more confusing for the user sometimes and opens possibilities which should exist. This sometimes makes e.g. exporting data more difficult if you do not want to loose information. E.g. if you have representations for each versionable entity you will have to check if someone for some reason added some representation to a TaxonNameBase which is a versionable entity. This doesn’t make sense because a TaxonNameBase is always meant to be a scientific name (otherwise you should use CommonName) and therefore only Latin should be available. Also a TaxonNameBase does not really need a media, but if this possibility exists people may start to save protologues as media directly with the name instead of using a TaxonNameDescription. So you will start having the same type of information at different places and you have to check them all, if you don’t want to loose information. So I don’t think that e.g. representations should be available to each class because there are many classes that do not need them really.
255
256
Therefore I think we should keep the number of attributes as limited as possible to each but at the same time of course we need to be able to express things that have to be expressed by adding necessary attributes.
257
258
Maybe you could set up a table with all classes where you think representations, media or originalSources are really needed from your experience with SDD/CDM.
259
260
I also feel a bit uncomfortable with having media and textual representation within one class because I think many representations are more abstract so we will never need a media for it. But I can see that this way of thinking is maybe influenced by the way we use representations now and that is only for defined terms. Many of the defined terms do not seem to have a need for a media representation. If you use representation in a more general way this may change.
261
262
I know that my arguments may go against the open world assumption that is followed by the TDWG ontology for example. But from my perspective the CDM should be a DataModel that is complex but still made to be used in concrete application. Therefore it tries to be strict were ever possible. At the same time I am not sure if this is always the right way to go so I am looking forward for the discussion about the above issues.
263
264
265
[[Ben|Clark - 03/03/2009]] suggested that we could make a TermBase an IdentifiableEntity - IdentifiableEntities do have a collection of OriginalSources, and space for the IdInSource.
266 45 Helene Fradin
267
268 56 Helene Fradin
[[Hélène|Fradin - 24/03/2009]] The diagram below represents the solution proposed by Ben, i.e. to make a TermBase an IdentifiableEntity so that they can have a collection of OriginalSources. I **TESTED** it in my environment and it works fine. However, I had to add the method generateTitle() to a certain number of classes. I think it still needs to be discussed because the representations attribute becomes redundant with titleCache and then we are exactly with the problem of too many attributes mentioned by Andreas.
269 55 Helene Fradin
270
271 47 Helene Fradin
![](TermBase.PNG)
272 45 Helene Fradin
273 32 Helene Fradin
274 12 Helene Fradin
----
275
276
277
278 13 Helene Fradin
## 3. MAJOR - Creation of a defined set of descriptions
279 12 Helene Fradin
280
281 35 Helene Fradin
 **Impacted objects: new object** 
282
283
284
 **a. Issue** 
285
286
287
Cf. mail exchanges between Gregor Hagedorn, Ben Clark and Helene Fradin in December 2009 "Keys and descriptions in the CDM".
288
289
There is no equivalent way of representing a SDD Dataset into the CDM and multi-access keys.
290
291
292 60 Helene Fradin
 **d. Proposed change (TESTED LOCALLY)** 
293 35 Helene Fradin
294
295 36 Helene Fradin
The solution proposed by Ben was a delimited set of taxa and their description. It would certainly be helpful for the import/export between SDD and CDM.
296 35 Helene Fradin
297 36 Helene Fradin
[Gregor] Perhaps to generalize this, a working set of taxa and a default character tree (to optionally create a subset of all taxa) could be provided? Such a working set could then carry a flag that it is suitably revised to serve as a multi-access key.
298 35 Helene Fradin
299
300
public class WorkingSet {
301 1 Andreas Müller
302 36 Helene Fradin
   private Map<Taxon,DescriptionBase> matrix;
303 35 Helene Fradin
304 37 Helene Fradin
   private DescriptiveSystem descriptiveSystem;
305
306 36 Helene Fradin
   private boolean multiAccessKey;
307
308 46 Helene Fradin
   private Language defaultLanguage;
309
310 36 Helene Fradin
   ...
311 1 Andreas Müller
312 35 Helene Fradin
 }
313 1 Andreas Müller
314
315 56 Helene Fradin
[[Gregor|Hagedorn - 27/02/2009]] I wonder whether separate Working Set Taxa and Working Set Features may not be more desirable, than actually filtering on DescriptionBase objects directly. To me it certainly seems to be more logically and consistent to set up ("I work with this genus/family etc, and have selected 200 out of 900 available
316 1 Andreas Müller
317 56 Helene Fradin
features").
318
319
Filtering the matrix dimension might also help in making it more similar to SDD Dataset element.
320
321
322 60 Helene Fradin
[[Hélène|Fradin - 24/03/2009]] New proposition (TESTED LOCALLY) with 2 separate working sets classes (*NOT IMPLEMENTED*)
323 56 Helene Fradin
324
325
public class WorkingSetTaxa {
326
327
   private Set<Taxon> taxa;
328
329
   ...
330
331
 }
332
333
334
public class WorkingSetFeatures {
335
336 57 Helene Fradin
   private Set<Feature> descriptiveSystem;
337 56 Helene Fradin
338
   ...
339
340
 }
341
342
343
344 12 Helene Fradin
----
345
346
347
348 56 Helene Fradin
## 4. MAJOR - Mapping use and referential objects
349 12 Helene Fradin
350
351
352
----
353
354 1 Andreas Müller
355
356 40 Helene Fradin
## 5. MAJOR - Problem how CDM handles the link between description and scientific taxonomic name
357
358
359
 **a. Issue** 
360
361
362
The fact that structured descriptions (DescriptionBase objects) cannot always be linked with a scientific taxonomic name raises problems for regrouping related descriptions. If the only possibility to regroup descriptions is by using the association with an existing taxonomic hierarchy, it limits the possibility of extracting sets of descriptions from the CDM. In addition, when importing data into the CDM, the information on potential connections between descriptions other than taxonomic is lost if not structured identically (e.g. use of the Scope class). A model such as SDD uses a Dataset object which contains a set of descriptions that can be tagged with a name, a description and media objects.
363 1 Andreas Müller
364 12 Helene Fradin
365 57 Helene Fradin
[[Gregor|Hagedorn - 27/02/2009]] About the problem how CDM handles the link between description and scientific taxonomic name I tend to agree. I have had repeated problems understanding the relation between descriptions and taxon names (and that they are so different).
366 1 Andreas Müller
367 57 Helene Fradin
I want to make sure that the use-case of unidentified specimens is included; this is possible both in CDM and in SDD (description has specimen but no taxon scope) (In fact this is simply equivalent to being identified as "Biota" and can easily be converted to that.)
368
369
370
371
372 12 Helene Fradin
----
373
374
375
376 13 Helene Fradin
## 6. MINOR - Descriptive system
377 37 Helene Fradin
378
379
 **Impacted objects: DescriptionBase** 
380
381
382
 **a. Issue** 
383
384
385
There is no possibility of associating a set of features/characters/descriptors to a description, or a set of descriptions.
386
387
388 38 Helene Fradin
 **d. Proposed change (IMPLEMENTED as an attribute of DescriptionBase)** 
389 37 Helene Fradin
390
391
To create a new object called DescriptiveSystem which contains at least a set of Feature objects possibly associated with domain of values.
392
393
394
public class DescriptiveSystem {
395
396
   private Set<Feature> features;
397
398
   // OR private Set<Feature, Set<PossibleValues>>;
399
400 1 Andreas Müller
 }
401 38 Helene Fradin
402
403 39 Helene Fradin
CURRENT INTERMEDIARY IMPLEMENTATION: http://dev.e-taxonomy.eu/trac/attachment/wiki/CdmVersionTwoDiscussion/DescriptionBase.gatcl.PNG
404 1 Andreas Müller
405 12 Helene Fradin
406 57 Helene Fradin
[[Hélène|Fradin - 24/03/2009]] Exactly corresponds to the WorkingSet classes defined in 3.
407 1 Andreas Müller
408 57 Helene Fradin
409
410 12 Helene Fradin
----
411
412
413 1 Andreas Müller
414 13 Helene Fradin
## 7. MINOR - How to express uncertainty or inapplicability ?
415 12 Helene Fradin
416
417
418
----
419
420 1 Andreas Müller
421 12 Helene Fradin
422 13 Helene Fradin
## 8. MINOR - Handling of multiple languages
423 12 Helene Fradin
424 1 Andreas Müller
425
426 12 Helene Fradin
----
427
428
429
430 13 Helene Fradin
## 9. MINOR - Media properties and associations
431 12 Helene Fradin
432
433 13 Helene Fradin
IMPLEMENTED
434 12 Helene Fradin
435 13 Helene Fradin
436
437 12 Helene Fradin
----
438
439
440
441 13 Helene Fradin
## 10. MINOR - A default measurement unit for Feature
442 12 Helene Fradin
443
444
445
----
446
447
448
449
## 11. MINOR - Ordering of TermVocabulary for supportedCategoricalEnumerations in Feature
450 24 Helene Fradin
451
452
453
----
454
455
456
457
## 12. MINOR - Why is the setParent function not public in FeatureNode ?
458 25 Helene Fradin
459
460
461
----
462
463
464
465 1 Andreas Müller
## 13. MINOR - How to distinguish between characters and groups as they are both Feature objects ?
466 32 Helene Fradin
467
468
Should the 'partOf' attribute be used?
469 27 Helene Fradin
470
471
472
----
473
474
475 1 Andreas Müller
476
## 14. MINOR - How to export and reimport multi-types characters/features/descriptors between CDM and SDD ? 
477 57 Helene Fradin
478
479
480
----
481
482
483
484
## 15. MAJOR - How to attribute a language to a titleCache ?
485
486
487
 **d. Proposed change (NOT IMPLEMENTED)** 
488
489
490
To make titleCache a LanguageString or a MultiLanguageText.
491 58 Helene Fradin
492
493
494
----
495
496
497
498
## 16. MINOR - Coding status / Unknown description
499
500
501
 **d. Proposed change (NOT IMPLEMENTED)** 
502
503
504
A new object would be created to be able to express a generic status information about a DescriptionBaseElement. For example, if a feature is “color of wings” but the described taxon has no wings, the description element associated with this feature is “not applicable”. It needs to be distinguished from a case where the description information is missing because “not available”. A DescriptionBaseElement could have a status attribute corresponding to a Status object expressing this information. This object would be similar to the DataStatus element in SDD and allow the recording of standardized reasons why data are missing. UBIF terminology (common foundation for several TDWG/GBIF standards like SDD) would be used.
505
506
507 59 Helene Fradin
[!Statusjpg!|[Gregor Hagedorn - 27/02/2009]] We did have Coding Status control at some point in the dicussions with Markus. This is a question to Andreas etc, wether perhaps it is just hidden in some way.
508 58 Helene Fradin
509
Otherwise I can only confirm how important the management of coding-/data-entry-status is (which also includes status values such as "Not to be coded = Decided to not code" or "Unknown = Research was performed, but still unknown". No status value is interpreted as: "work to do".
510
511
512
[[Andreas|Müller - 27/02/2009]] Can more then one of the values of these status appear for the same description element? If no, we should handle status as a defined term instead of having multiple boolean values. 
513
514
Is the status type information enough or should we handle it the same way as e.g. NomenclaturalStatusType which inherits from ReferencedEntityBase, so you can also store the information about who thinks that this status is the valid one. Please don’t misunderstand me here. I don’t want to make it more difficult then necessary but I just made the experience that taxonomists always want to add references to any kind of information and so I wonder if this is needed here too sooner or later. But if SDD does not have it, maybe we do not need it.
515
516
517
[[Ben|Clark - 27/02/2009]] I think that the idea for recording the status of an object is really important, but I wonder how this use case differs from Marker (which has a boolean, and a MarkerType which already has values like COMPLETE, DOUBTFUL, TO_BE_CHECKED). 
518
519
Having multiple ways to do the same thing is not a good idea, so if we use Status to describe the status of a DescriptionElementBase, then we should not use Marker for this purpose.