Closed nielsklazenga closed 9 years ago
The Darwin Core documentation at https://code.google.com/p/darwincore/wiki/Event#habitat now recommends recording habitat information using the Environment Ontology (ENVO, http://environmentontology.org/). In addition to:
ENVO has the following concepts that can be used:
The environmental feature concept comes close to the substrate element proposed in issue #14.
It may be possible to deliver the Darwin Core habitat concept (http://rs.tdwg.org/dwc/terms/habitat) as well as the ENVO concepts, so we could deliver the detailed habitat description using the Darwin Core concept and the categorised data using the ENVO concepts. However, I believe it is the intention to eventually include environmentalMaterial, environmentalFeature and biome in Darwin Core.
I would like to bring this issue to people's attention again.
I was going to really rock the boat by saying that what we deliver as habitat
is really locationRemarks
and that the only way to salvage the terms in the habitat group is to deprecate them all and only bring them back once we have a vocabulary for them. Until then they are dead weight in our databases. Turns out I did that already months ago and it didn't even cause a ripple.
+1 on being clear that it isn't necessary (and is in fact beneficial) to avoid arbitrarily splitting up a free-text field. I'm still cogitating on the habitat vs. locationRemarks item. I'm not following the "ripple" comment, does this imply you've made changes to the terms.rdf and committed those without anyone commenting?
A ripple is a very small wave. I was just saying that I thought this would be controversial, but I said it seven months ago (in this issue) and nobody even noticed apparently. No, I didn't make any changes: this is purely for discussion. I don't even expect us to make any changes before HISPID is ratified; this is for us to consider later. We already decided to only deliver habitat
to AVH. Which is basically confirming what HISPID 3 already says, I think, although what HISPID 3 says on this is very open to different interpretations.
I am also not sure about habitat
vs. locationRemarks
. I just want us to think about having both verbatim and interpreted habitat fields (and was suggesting locationRemarks
for the verbatim field). There is no hurry, as it only becomes an issue once we have a habitat vocabulary for the interpreted field. I don't think the IUCN Habitat vocabulary is all that useful (well, useful perhaps, but worth the effort?).
Apart from the locationRemarks
vs habitat
thing, this is more an intentional thing and the habitat terms can stay as they are now and were after our workshop. It might be good to add a comment that we intend to have a vocabulary on these terms, from which people can infer that it is probably not the best idea to keep filling them with free text.
Hobart, 2015-10-25: We keep the habitat fields as a verbatim fields (as they are now), but will flag this as an issue for discussion among the community in future.
Following the AGM, I said I would look into some of the event terms such as habitat, geological substrate, substrate, soil, vegetation.. There is a committee called the National Committee on Soil and Terrain (NCST) that have published the colloquially known blue and yellow books (Australian Soil and Land Survey Field Handbook). Not sure how this would work for NZ though... The yellow book contains various chapters including landform, vegetation, land surface, soil profile, and substrate. This is a nationally recognised standard in which we could possibly use the keys: Landform pattern, Landform element, Soil texture, Lithology, Geology. Vegetation could be based on National Vegetation Information System (NVIS) using the broad floristic formation. I have attached the keys apart from vegetation (need to think about this one some more BUT free text may be the way to go for veg).. I propose we change 'geologicalSubstrate' to 'lithology'.
Geology.xlsx Landform_element.xlsx Landform_pattern.xlsx Lithology.xlsx
For vegetation, another option is to use the NVIS Major Vegetation Groups or subgroups. See attached.. Does NZ have something equivalent? Bear in mind they may be under review soon...
NVIS Major Veg Groups 4.1.pdf NVIS Major Veg Subgroups 4.1.pdf
I think these are very useful vocabularies. Any chance they are online somewhere? I second the proposal to change geologicalSubstrate
to lithology
.
Major vegetation groups and subgroups can be found at http://laptop.deh.gov.au/erin/nvis/mvg/index.html
Landform pattern & element, lithology, soil texture is published at, but only available as a book. I can't seem to find the tables published online elsewhere but will investigate further.. The tables attached previously are from the NT's soil database which are derived from the yellow book. http://www.publish.csiro.au/pid/5230.htm
Yes, I had a look for the soil types and the lithography as well yesterday and couldn't find anything either. It means we can use them, but, if we want to put a vocabulary online, we probably need to get permission for that.
there is a NZ soils classification handbook that has similar vocabularies from memory. It includes a vegetation classification too, but the ecologists may have different schema. Will need to dig a bit
the NVIS stuff Donna mentioned appears to be covered under CC-BY licenses
Yes, it's from ERIN. You can download the shapefiles etc. for free from Geoscience Australia. We've had facets with the NVIS vegetation classification in AVH for the last four years.
It's the NCST stuff that I think we can't just copy.
I am having a meeting with our NT rep for NCST on Friday so I should know more about using the code tables for landform, lithology and soil texture etc...
Yes, the NVIS datasets are all spatial, so vegetation could be an auto-generated field. But it also makes sense to have a verbatim field for vegetation..?
Good to know NZ also have similar vocabularies. Look forward to hearing more..
I contacted Peter Wilson at CSIRO about using the tables from the yellow book and accessing them etc. I am awaiting a reply...
The HISPID Habitat group contains the following elements:
Issue #14 furthermore proposes a 'Substrate' field in the sense that I would interpret the word, the current HISPID concept being more the underlying geology.
According to the HISPID 3 documentation Habitat is an aggregated field, that may be split up into the six other elements in herbarium databases. It also says that the translation of collectors' historical descriptions of habitat is prone to error and misinterpretation and that institutions that do store the discrete concept must combine those before delivery, if they want to deliver the Habitat field. That has not been the practice, as almost everyone is delivering Habitat and some herbaria deliver additional habitat field as well.
Under Collection notes in HISPID 3, the point is made much more clearly than under the Habitat group:
Of the seven concepts above, Habitat has been mapped to dwc:habitat, Topography to locationRemarks and Associated Species to associatedTaxa (but see #20), The other concepts cannot be mapped to Darwin Core.
All HISPID Habitat fields, except Aspect, are free text fields. I don't think there is any point in splitting up the Habitat field if the resulting fields are also free text. In fact, splitting up the field would just make it harder for users to find the data, as different herbaria, or even different people at the same herbarium, or the same people in different circumstances, might put the same information in different fields. Just keeping everything in the one field will also avoid the errors and misinterpretations that the HISPID documentation warns us for.
I think the discrete concepts could be useful, but only if they had vocabularies on them – and would be interpreted fields – and would be used in addition to the detailed habitat description in the habitat field. For the habitat information that I record with my bryophyte collections I can currently only use the Habitat field (I make notes about light and moisture etc., in addition to vegetation, topography, substrate etc.). I would happily populate the discrete fields, if I were told the values I could use and if it didn't mean I had to give up on the detail and context in my habitat descriptions.
I actually think that it might be best if our implementation of the dwc:habitat element also would have a vocabulary on it (for example the IUCN Habitat classification, http://rs.gbif.org/vocabulary/iucn/habitat.xml, or a more detailed Australian one, as long as there is some classification we can refer to) and that what we currently deliver under this concept might be best placed somewhere else, perhaps locationRemarks, but I haven't given that too much thought yet (and I do tend to change my mind every now and then), so I am not going to pursue this. I might actually not really pursue any of this – except that all habitat information should be delivered in habitat, which is already in HISPID – but I just put it out there, as it needs to be discussed.