Discussion

Trying using the form when posting

Name/Topic: Units

Issue: Schema as written requires specific units, such as height in meters, whereas it is desireable to retain the original values and units reported by the original observer

Proposal: Incorporate ability to specify units for attributes such as diameter and height, probably at the plot level but possibly at the project level. Would be ok to have a set of default units. If this is accepted we should also include a list of acceptable units, perhaps taken from the SEEK units ontology.

Comments: Based on a discussion among Peet, Wiser and Schildhauer.

Status: Method for recording units for all measured values has been added to the new proposed version of schema Candidate 1.5.2. (Available 2010-05-21). We have yet to consider SEEK units ontology, but this has merit.

Usage of foreign namespaces

TCS

Name/Topic: tcs:taxonname:name

Issue: The TCS has redundant name element in entity taxonname

Proposal: Changing the tcs:taxonname:name to optional if a ref is available, we only need this:

<taxonName id=1>
  <CanonicalName>
    <Simple>Hypnum cupressiforme</Simple> 
  </CanonicalName>
</taxonName>
<taxonConcept id="83028">
  <Name scientific="true" ref="1"/> 
    <AccordingTo>
     <AccordingToDetailed>
       <PublishedIn linkType="local" ref="4"/> 
    </AccordingToDetailed>
  </AccordingTo>
</taxonConcept>

Comments: Nick Spencer -> I think you are correct Martin. I saw this as an issue with it being ambiguous as to what was the preferred method. However, we can't directly change the TCS standard so would need to be very careful in adopting changes that would see us departing from it. Perhaps we should raise this as an issue with the tcs working group?

Status: Submitted

EML

Name/Topic: eml:attribute

Issue: The VegX? element attribute is very simar to EML, only one element is missing.

Proposal: Rework of EML to fit generalized purpose

Comments:

Status: Submitted to Matt Jones

Change Proposals

Remodelling

Name/Topic: Geography

Issue: We have insufficient geospatial elements in the schema

Proposal: We suggest we follow the Geospatial Extension of Darwin Core [these are currently being refined by the TDWG Geospatial interest Group - geospatial schema. We suggest we call our ‘base’ element geospatial, just as we have ‘literature’ and ‘party’. We should use the name space ‘DwC’ and include the namespace at the top of our schema as we do for eml, tcs, etc. Although Darwin Core has not yet been adopted as a standard, it seems stable enough to be worth following and it fully meets our needs

Comments:

Brad Boyle: Agreed

Status: Done. A new geospatial type has been created to accommodate all the coordinate based location information. The basis for this was the Darwin Core geospatial extension. To this base were added (or moved) elements for coordinates based on a projected grid coordinate system. For example a map series, map sheet name and easting and northing coordinate. Also added were depth and elevation elements.

Name/Topic: Foreign Key type references

Issue: Rather than using strict XML nesting to structure repeated data, e.g., a specific plot with multiple different observations record on it the schema relies on 'pointers' to common 'container' elements.

Proposal: For elements with suffix ‘ID’ should we remove the referenced element structure from the working/editing schema to reduce confusion. If ‘….ID’ is well defined in the documentation, then users will know that this information is located elsewhere in the schema and this will be included in the definition of the ‘….ID’ element.

Comments:

Brad Boyle: Assuming I understand, I agree to the above.

Status: DONE

Name/Topic: aggregateValue: upperValue and lowerValue

Issue: We can’t understand the nature of the elements pertaining to aggregateOrganismObservation:aggregateValue. What is the purpose for the elements upperValue and lowerValue?

Proposal: Are they meant to be used if the data are recorded as a range? This seems unlikely for an aggregateValue, which by its definition implies a single value was recorded. If they are meant to be used to record ranges, then the element ‘value’ would not be used, so cannot be mandatory.

Comments:

Brad Boyle: I’m not sure I understand either, but I will make a guess. aggregateOrganismObservations pertain to group of individuals of a particular species, rather than individual organisms. One example is percent cover (…of species X). Percent cover is frequently expressed as categories, each with an upper and lower bound, e.g., <1%, 1-5%, >5-10%, etc. I suspect this may be what upperValue and lowerValue refer to.

Status: these definitions have been updated

Name/Topic: attributeID: data types e.g. ordinal etc

Issue: We don’t understand how these elements successfully define the ordinal scale being used.

Proposal: . For example, how can an ordinal scale have a precision associated with it? Second, ordinal scales are by their nature unitless, so we don’t understand how there can be a unit associated with it either. Could ‘precision’ and ‘unit’ be meant to apply to ‘upperLimit’ and ‘lowerLimit’? The element ‘coverPercent’ is defined as the average cover of the index in percent. Wouldn’t this be best calculated from ‘upperLimit’ and ‘lowerLimit”, rather than stored independently. What does the element ‘definition’ mean? What does the element ‘index description’ mean? Are these different?

Comments:

Brad Boyle: Hmm…reading this it looks like my comments above apply to upperLimit and lowerLimit rather than upperValue and lowerValue. I didn’t play any part in the design of the specific elements of this component, so best not to guess. Bob, do you know anything about this? VegBank? contains a lot of aggregate observations.

Status: all these changes have been made

Name/Topic: Cardinality of taxonDeterminationType:TaxonConcept

Issue: The parent element should be an unbounded container element, not bounded to be 1. And the child element TaxonID? should be bounded to 1, rather than unbounded?

Proposal:

Comments:

Status: Unresolved

Name/Topic: simple user defined variables structure

Issue: The structure for the simple user defined variables seems to be redundant, if MethodID? is mandatory because the element ‘name’ is included both under ‘method’ and under simpleUserDefinedType.

Proposal: We suggest that MethodID? should be optional.

Comments:

Brad Boyle: Agreed

Nick Spencer: I think this is a miss understanding of how simple user defined element works and so believe it to be OK.

Status: Unchanged

Name/Topic: veg:taxonOccurrenceType:originalReference

Issue: the element ‘originalReference’ is likely redundant with information being stored under the taxonConcept section.

Proposal: Can this element be deleted?

Comments:

Brad Boyle: Yes

Status: Removed

Name/Topic: types ‘relatedItemType’ and ‘relatedSpatialItemType’

Issue: duplication in the two types that is confusing

Proposal: We suggest that the types ‘relatedItemType’ and ‘relatedSpatialItemType’ be collapsed into one type with the spatial information being optional. this will allow mapped trees to be accommodated in the individualOrganismObservation element. If this change is adopted, some definitions will need to be slightly modified.

Comments:

Status: These types have been updated. relatedSpatialItem now reuses relatedItem and no longer has the duplicated elements referred to above.

Name/Topic: the EML Project module

Issue: one of the drawbacks of using the EML Project module is that it only allows one-to-many project relationships.

Proposal:

Comments:

Brad Boyle: We should extend the EML module here; make our model fit the real world rather than trying to shoehorn it into as-is EML.

Status: unresolved

Name/Topic: Vouchers-Specimens

Issue: Not clear to me how vouchering is supported. A voucher is a verifiable evidence of the taxonConcept applied to a particulat taxonObservation. It should allow for the transfer of a taxonName to a taxonObservation based on another taxonObservation, typically a specimen deposited in a herbarium.

Proposal: currently we are using a very simple approach to accommodate vouchers, i.e. only recording the herbarium accession code. One option is to adopt the specimen part of the TCS schema.

Comments:

Brad Boyle: OK, then we need to re-think this. Support of herbarium specimen vouchers, if possible as webservice, is critical to accomodating most tropical data. We need to be able to retrieve—and store—all the usual DwC? elements pertaining to names and determiners of herbarium specimens, and map them to vegetation observations.

Nick Spencer: so we might need both a simple accession number approach and also implement a structured way of describing a service. EML has one, but does it accommodate REST/WS/TAPIR(?) type requests?

Status: unchanged

Missing elements

Name/Topic: communityDetermination:Date

Issue: VegBank? has a start date and end date

Proposal: Add Date

Comments:

Brad Boyle: Yes. We should allow for start and end of all dates, with StartDate? being mandatory in cases where only one date given.

Status: DONE

Name/Topic: diameterAccuracy

Issue: individualOrganismObservationType: Need elements ‘diameterAccuracy’ and ‘heightAccuracy’ to accommodate diameter classes and height classes

Proposal: [See VegBank?]

Comments:

Brad Boyle: Agreed

Status: DONE

Name/Topic: veg:plot: ‘radius’

Issue: veg:plot: needa an element ‘radius’

Proposal: : need an element ‘radius’ (positioned below the elements length and width) to define the dimensions of circular plots

Comments:

Brad Boyle: Agreed

Status: DONE

Name/Topic: veg:individualOrganismObservation: ‘health’

Issue: veg:individualOrganismObservation: needs an element ‘health’ to indicate whether individuals are dead.

Proposal: See VegBank? ‘stemhealth’: defined as ‘Health of the stem referenced in this stemLocation record. Usually used to describe "dead" stems.’ We believe health status, particularly of trees, is too critical in tree demography datasets to be handled by a user-defined variable.

Comments:

Brad Boyle: Yes. This should be a fixed field.

Status: DONE

Element/Attribute naming

Name/Topic: veg:PlotType: plotCode

Issue: To avoid confusion with plotName and emphasise importance of uniqueness

Proposal: rename to plotUniqueIdentifier

Comments:

Status: DONE

Name/Topic: veg:individualOrganismObservation locationObservationID

Issue: More explicitly describes the relationship

Proposal: rename to plotObservationID

Comments:

Status: DONE

Name/Topic: Veg:taxonOccurrenceType originalName

Issue: More clearly defines the plant name as that used by the author of the plot. Follows VegBank?

Proposal: rename to authorName

Comments:

Status: DONE

Name/Topic: Veg:taxonOccurrenceType Code

Issue: More clearly defines the species code as that used by the author of the plot.

Proposal: rename to authorCode

Comments:

Status: DONE

Name/Topic: Veg: AggregateOrganismObservation?:aggregateValue:attributeID ratio

Issue: When we check dictionaries and Google:define ratio invariably refers to the relative magnitudes of two quantities

Proposal: rename to quantitative

Comments:

Status: DONE

Name/Topic: Veg:plotObservation locationID

Issue: More explicitly describes the relationship

Proposal: rename to plotCodeID

Comments:

Status: DONE

Name/Topic: Veg:plotObservation ecoManagement

Issue:

Proposal: rename to management

Comments:

Status: DONE

Element Definition

Name/Topic: . obsEndDate & obsStartDate

Issue: . obsEndDate & obsStartDate – these are defined backwards from VegBank? and to Susan are counterintuitive

Proposal: . If one is going to be mandatory, to me it should be obsStartDate, not obsEndDate.

Comments:

Brad Boyle: Agreed

Status: DONE

Name/Topic: PlotObservation?: WaterDepth?

Issue: PlotObservation?: The concept of WaterDepth? seem completely different from the element with the same name in VegBank?. The Bfn definition: “Distance from surface to ground water in meters” sounds more suitable for an element named “WatertableDepth”.

Proposal: The VegBank? definition is: “For aquatic or marine vegetation, what was the water depth in m.”

Comments:

Nick Spencer: element now mored to geospatial type

Status: definition unchanged - needs resolution

Name/Topic: concepts ‘order’ and ‘sequence’.

Issue: a consistent term be used for the concepts ‘order’ and ‘sequence’. Currently the schema uses both e.g. ‘order’ in misc:AttributeType vs. ‘stratumSequence’ within ‘stratumType’.

Proposal:

Comments:

Status: Unresolved

Name/Topic: determination of ‘stratum’.

Issue: There is in Europe a phytosociological school that classify stratum communities (you, europeans we are crazy classifiers :-). These are called ‘sinusiae’ (http://www.britannica.com/EBchecked/topic/578754/synusia). See also Dengler, J., M. Chytry, and J. Ewald. 2008. Phytosociology. Pages 2767-2779 in S. E. Jørgensen and B. D. Fath, editors. Encyclopedia of Ecology. Elsevier, Oxford.

Proposal: One way to expand Veg-X to allow for this would be to add stratumDetermination and stratumConcept (or similar names) that would use a reference of a stratumObservation, much like we now do for community determinations that apply to the whole plotObservation. It may sound crazy but it does not compromise Veg-X in any way and we could gain some (few) users.

Comments:

Status: Unresolved