head 1.6; access; symbols; locks; strict; comment @# @; 1.6 date 2007.03.06.17.30.00; author TWikiGuest; state Exp; branches; next 1.5; 1.5 date 2005.03.15.15.06.51; author GregorHagedorn; state Exp; branches; next 1.4; 1.4 date 2005.03.12.19.47.51; author GregorHagedorn; state Exp; branches; next 1.3; 1.3 date 2005.03.12.10.11.26; author GregorHagedorn; state Exp; branches; next 1.2; 1.2 date 2005.03.09.15.41.22; author DonaldHobern; state Exp; branches; next 1.1; 1.1 date 2005.03.09.10.35.26; author GregorHagedorn; state Exp; branches; next ; desc @none @ 1.6 log @Added topic name via script @ text @---+!! %TOPIC% %META:TOPICINFO{author="GregorHagedorn" date="1110899211" format="1.0" version="1.5"}% %META:TOPICPARENT{name="WebHome"}% This topic is about attempting to subdivide the totality of biodiversity informatics into separate knowledge domains, for which object types may be defined. Bioidiversity data could then be expressed in a matrix (or composition) or such object types, see DataModelMatrix. Ultimately, the object should be in a - relatively flat - ontological hierarchy, so any suggestions about this are appreciated. Below a rough first draft based on SDD/UBIF. We should work towards a rough consensus on how to delimit knowledge domains, and which labels for the object types are considered most useful and intuitive. In SDD we have: * *DescriptiveData* (consisting of DescriptiveTerminology, CodedDescriptions, NaturalLanguageDescriptions, and (fixed) IdentificationKeys)
plus inherited from UBIF (currently as external interface or "proxy" objects, to be revised as outlined in DataModelMatrix): * *ClassNames* (= definition of vernacular or scientific names) * *ClassHierarchies* (= taxonomic hierarchy, including synonmyization) * *Objects* (ABCD Units, ObjectOccurrences?, TaxonOccurrences? or Specimens? Problem: some uses need to validate that only stored/preserved objects are adderessed (e.g. nomenclature), others generalize stored and observed objects, some uses apply to parts of objects) * *Agents* (person, institution, software) * *Publications* (references to digital/printed publications or online-publications itself) * *Geography* (geographical locations and areas. Problem: objects in collection are called Location rather than Geography again. Alternative Names: Locations/Location (not clear whether geographic or in book, document, etc.) GeoLocations/GeoLocation - perhaps best choice? * *MediaResources* (image, audio, video, formatted text like pdf, html, etc.) * *MeasurementUnits* (scientific like m, kg, s, non-scientific like in, ft, oz) In the species bank workshop in Amsterdam, I further proposed: * *Uses* (biotechnological, medical, agricultural and mythological uses of plants) * *Conservation* (in the sense of nature conservation/red list data, would be good to have better term, conservation may also be applied to dead objects to conserve against decay) * *Ecology* - large area, no details ontology from me, except for * *OrganismInteractions* = two organisms, an interaction type like host-pathogen, predator-prey, or pollinator, and area in which this interaction is known to occur * *Distribution* in the sense of chorology, i.e. synthetic/summarized hypothesis about actual or potential distribution. Additional types in the overall object concept, for which no root collections would be defined because they are only used in compositions may be *NomenclaturalOpinion*, *Identification*, and several types like character, concept, modifier used inside SDD. Which other types (perhaps as subtypes in an ontology) should be defined for a start? Which names you simply dislike, even if you don't have a better one? In email to tcs-lc list, Roger Hyam proposed a root collection *"Nomenclature"*. This corresponds with Geography, which also differs from the plural form of the class name itself. In general I think it desirable to stay with the "plural name for collections" pattern, but intuitive names may be even more important. -- Main.GregorHagedorn - 09 Mar 2005 --- The ontology I use in The Taxonomicon looks like this: * Nomenclature * Rank (item) * Scientific name (text) * Common name (text) * Epithet (text) * Author citation (text) * Nomenclatural attribute (item) * Nomenclatural code (item) * Taxonomy * Taxon group (item) * Taxon (taxon) * Geography * Biogeographic realm (item) * Geographic region (item) * Type locality (text) * Presence (item) * Geology * Geologic time (item range) * Geologic age (number range) * Year of extinction (number) * Ecology * Habitat * Ecologic realm (item) * Major habitat type (item) * Ecoregion (item) * Habitat (item) * Relationships * Host (taxon) * Host type (item) * Type host (boolean) * Parasite (taxon) * Parasite type (item) * Pathogen (boolean) * Disease (text) * Symbiont (taxon) * Symbiont type (item) * Commensal (taxon) * Commensal type (item) * Host dependency (item) GBIF should provide a registry for all standardized objectID's, data source names and parameter names. -- Sheila Brands, Universal Taxonomic Services, The Taxonomicon & Systema Naturae 2000 - 10 Mar 2005 --- (Donald Hobern and Sheila Brands propose a closely related discussion on whether an object-oriented approach is appropriate at all. Please discuss this under KeywordBasedDataExchange! -- Gregor - 15. March 2005) --- @ 1.5 log @none @ text @d1 2 @ 1.4 log @none @ text @d1 1 a1 1 %META:TOPICINFO{author="GregorHagedorn" date="1110656871" format="1.0" version="1.4"}% d44 40 a83 1 Let me first try another approach which may be more confusing, but may ultimately help us to build what we need in a more gradual and modular fashion. First consider the ABCD !UnitFact element: d85 9 a93 18 Synecology Grows the fungus Leucocoprinus gongylophorus (Hoyt 1996). 2005-03-09 Donald Hobern Helldöbler, B. and Wilson, E.O. (1990) The ants. Springer-Verlag, Berlin. p. 599 Assume that we change this slightly so that the content of the element becomes an attribute that belongs to a controlled vocabulary of key information categories. Any item of biodiversity information can be presented this way, and we can subsequently refine the controlled vocabulary to represent an entire hierarchical tree (or more general graph) of categories. Secondly consider the fact that information within our immediate remit falls into two classes, data which relates to an individual organism (or some proxy for an individual in groups where it is hard to define an "individual"), and data which relates to a taxon (often a species, but potentially any rank), these latter data being in some way synthetic. I think that we can start with the model as the most general structured representation of biodiversity data, for either individual- or taxon-based data. @ 1.3 log @none @ text @d1 1 a1 1 %META:TOPICINFO{author="GregorHagedorn" date="1110622286" format="1.0" version="1.3"}% d44 1 a44 3 Let me first try another approach which may be more confusing, but may ultimately help us to build what we need in a more gradual and modular fashion. First consider the ABCD UnitFact element: @ 1.2 log @none @ text @d1 1 a1 1 %META:TOPICINFO{author="DonaldHobern" date="1110382882" format="1.0" version="1.2"}% d27 1 a27 1 In the species bank context, I further proposed in Amsterdam: d39 2 @ 1.1 log @none @ text @d1 1 a1 1 %META:TOPICINFO{author="GregorHagedorn" date="1110364526" format="1.0" version="1.1"}% d42 23 @