- tdwg-content - lists.tdwg.org

FW: [STDTRK] Request for a Decision for Public Review of DarwinCore Draft Standard
by Donald Hobern 26 Aug '09

26 Aug '09

At Gail's request, I'm forwarding some discussion between Renato and myself on the Darwin Core draft Thanks, Donald Renato, You are quite right - domains and ranges may cause us more problems. At very least it may be sensible for these to be things which get asserted within other OWL files used within specific projects to govern their own application models and inference rules. In the end my concerns are really around the need for more clarity on the way that the dcTerms:type values are to be used and how this relates to past use of Darwin Core. I'm not sure I ultimately disagree with any of the decisions made. However I still cannot find any actual definition for the Occurrence and Event cases to explain what situations they are intended to cover. Unless we take the time to define the intended scope for all our terms and property values, it is hard to predict whether data from multiple sources can be expected to be suitable for combination. The scientific name case is one example. I would like an explicit statement that it means nothing more than "the name of a taxon (somehow) associated with this record" rather like a Dublin Core subject. If, e.g. in the case of an Occurrence record, it is meant to be a statement that a taxon was actually recorded at the location on the given date, we may need to be more explicit. I'm still not comfortable with leaving these things unstated. I must however emphasise that I am very happy to see how much work has gone into this revision and the level of forethought in addressing many important issues. Donald -----Original Message----- From: renato(a)cria.org.br [mailto:renato@cria.org.br] Sent: Friday, 24 July 2009 7:04 AM Subject: RE: [STDTRK] Request for a Decision for Public Review of DarwinCore Draft Standard Hi Donald, Scientific name is precisely the kind of term that I feel should be generic. There's an ancient search interface at CRIA that illustrates the use case "give me everything you have related with this scientific name": http://names.cria.org.br/index?lang=en (check all checkboxes at the bottom of the page) In SPARQL I think the query would simply look like: SELECT ?x WHERE { ?x <http://rs.tdwg.org/ont/scientificName> "some name" } instead of repeating the same condition for every possible combination of domain#property. Most id properties (collectionID, locationID, etc.) should also probably be "domainless" since they can appear in objects from many different classes. Best Regards, -- Renato > Looking at what is in the DwC document, I think my concerns are with > plans to use DwC for checklist data rather than the DwC proposal itself, > but the problem issue may be in there somewhere. Here are some comments I > sent earlier: > > I need to take some time and provide some comments on the use of Darwin > Core for non-occurrence data. In general I believe we need to be moving > towards simple class properties with tightly defined explanations of the > expected content and format. This use of DwC seems to me to be a > significant dilution of the semantic content of these properties. If DwC > is an object property just for a taxon occurrence, the explanation of > dwc:ScientificName would be something like "The scientific name assigned > to the taxon to which the recorded organism was identified". If we extend > it to cover taxon occurrences, checklist entries and all the other things > that people seem to have in mind, the explanation would reduce to "The > scientific name which is associated with this record". In practice few > people will be stumbled, but I really don't like it. It would be so easy > just to have chk:ScientificName as well as dwc:ScientificName and to keep > the semantics explicit. This becomes particularly problematic when we > play with RDFS and OWL. We could choose to define the "dwc:ScientificName" > property to have a domain restricted to TaxonOccurrence, allowing a > reasoner > to infer that objects with this property can be treated as > TaxonOccurrence records. With the diluted dwc:ScientificName all we can > infer is that the object is a > ThingWithSomethingToDoWithTheBiologicalDomain. > > Donald -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

3 4

DwC taxonomic terms
by Markus Döring 26 Aug '09

26 Aug '09

Dear John & DwC friends, after finally having time to review the current dwc terms again I came across a couple of issues I'd like to see discussed or even changed. I am working for nearly 1 year now with the new terms during their development, especially with the new and modified taxonomic terms. So far they work very well in practice, but there are a few improvements I can think of, mostly related to the latest changes shortly before the public review started. I have added them as separate issues to the google code site, but list them here in one go. The number of issues is larger than I hoped for, but most of them are minor terminology issues for consistency and not touching the core meaning of the terms. Markus --- #47 rename basionym(ID) to originalName(ID) http://code.google.com/p/darwincore/issues/detail?id=47 The intend for this term is really to reflect where a name originally comes from in case it is a recombination. The term basionym is mostly used with botanists and covers only the cases when an epithet remains the same, i.e. not replacement names. The best matching, broader term therefore is originalName I think. Changes have to be done to both the verbatim name and the ID. Good examples for synonyms, basionyms, replaced names etc can be found in this document: http://www.peabody.yale.edu/other/PROTEM/TAXSIG/taxonomy_synonyms_examples.… --- #48 remove taxonConceptID http://code.google.com/p/darwincore/issues/detail?id=48 The conceptID is intended to state that 2 name usages / potential taxa are the same, even if they use a different name. This is a special case of true concept relations and I would much prefer to see this covered in a dedicated extension treating all concept relations, especially frequent cases such as includes, overlaps, etc. I am more than willing to define such an extension --- #49 rename scientificNameID, acceptedScientificNameID and higherTaxonNameID http://code.google.com/p/darwincore/issues/detail?id=49 no matter what the final term names are I think the 3 ones should be consistent. Originally it was intended to call them taxonID, acceptedTaxonID and higherTaxonID with a loose definition of a taxon, more based on the idea of that all terms here are taxonomic terms and therefore contain taxon in their name. The current version scientificNameID, acceptedScientificNameID and higherTaxonNameID intends to do the same I believe, but the terminology invites people to use them not referring to each other from what I have seen so far in practice. Concrete recomendations: #49a replace scientificNameID with nameUsageID There is the need to uniquely identify a taxon concept with a given name, a name usage. A nameID suggests the name is unique which it isnt if combined with an sec reference aka taxonAccordingTo. A taxonID suggests to refer to a distinct taxon concept. A name usage seems the smallest entity and can therefore be used to act as a sort of unique key for names, taxa, taxon concepts or just usages of a name. All other taxonomic dwc ID terms can and should point to a name usage id then. This makes me think if most/all other IDs should reflect this in their names, see below. It could make sense to keep scientificNameID as a ID to the name as defined by a nomenclator. But this ID can also be used as a name usage id, so in order to gain clarity I would prefer to have the term removed. #49b rename acceptedScientificName(ID) to acceptedNameUsage(ID) this term should point to the name usage that reflects the "accepted" taxon in case of synonyms, no matter if they are objective or subjective. AcceptedScientificName sounds more like a nomenclatural exercise and in accordance with #3 (nameUsageID) the term acceptedNameUsage(ID) would be the best fit in my eyes. #49c rename higherTaxonName(ID) to higherNameUsage(ID) in consistency with nameUsage & acceptedNameUsage --- #50 remove recommendation to concatenate multiple values, especially for higherTaxonName/higherNameUsage http://code.google.com/p/darwincore/issues/detail?id=50 similar to originalName or acceptedNameUsage this term is meant to be a verbatim pointer to the higher taxon as an alternative way of using higherTaxonNameID. Therefore it should only contain a single name, the direct parent, in my eyes. There are also already the 7 mayor ranks as separate terms that can be used to express a flattened hierarchy. I am aware DwC suggests to use concatenated lists in a single term in other places, e.g. , but I believe it would be better to keep the meaning singular and use multiple instances of that term to express multiple values. Dublin Core also recommends to use multiple XML elements for multiple values, see recommendation 5 in http://dublincore.org/documents/dc-xml-guidelines/ --- #51 rename namePublicationID to namePublishedInID http://code.google.com/p/darwincore/issues/detail?id=51 for consistency with namePublishedIn --- #52 rename (verbatim)scientificNameRank to (verbatim)rank http://code.google.com/p/darwincore/issues/detail?id=52 to avoid discussions about whether the rank belongs to the name or the taxon and also because its nice and short and there is no clash in biological terminology.

5 13

assertions in DwC terms
by Hilmar Lapp 24 Aug '09

24 Aug '09

The current DwC Terms version (at http://rs.tdwg.org/dwc/rdf/dwcterms.rdf) defines the domain for (at least some) object properties. Unless I am missing something this means that when I use DwC Terms for properties I implicitly assert the class of the subject, which means that either I can use DwC terms only for subjects of the type they are intended for (and why would one want to limit DwC's use in this way?), or reasoning based on RDF or OWL extractions of leads to problems. For example, in the Phenoscape project [1] we would like to link characters, states, or OTUs to the specimens based on which a systematist defined a (or all) character(s) or state(s). The specimens would be described in a NeXML document [2] with embedded RDFa annotation by institutionCode, collectionCode, and catalogNumber. The RDF extracted from that when run in a reasoner (which we will do) would implicitly assert that the specimen is a DwCTerms:Occurrence. Right now that probably doesn't hurt much in this case, but it might in the future, and I'm not sure what is gained from forcing those implicit assertions in the vocabulary. Should I post this as an issue to the tracker on Google Code, too? -hilmar [1] http://phenoscape.org [2] http://nexml.org -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- hlapp at duke dot edu : ===========================================================

3 7

taxonAccordingToID
by David Remsen 19 Aug '09

19 Aug '09

John - Is there a good reason why there is a namePublishedIn and namePublishedInID pair or properties for explicitly or indirectly referencing the original description of a name but only a taxonAccordingTo propertly for explicitly citing a subsequent use or reference to a name. Why no means to reference a non-original citation? Regards, David

1 0

Re: [tdwg-content] dwc: city to county
by Gregor Hagedorn 18 Aug '09

18 Aug '09

At the moment I can only add small bits of geo-relevant comments to the dwc effort: -------- 1. While studying the available terms for describing biodiversity-related images for MRTG, trying to reuse as many dwc terms as possible (unless higher priority standards already exists, such as dc or xmp, see http://www.keytonature.eu/wiki/MRTG_Schema_v0.7#Geography_Vocabulary) we note the conspicuous absence of ** city or place name ** The term is available in iptc geo extension and is likely to be in the future routinely used on digital images. dwc has http://purl.org/dc/terms/Location Has Domain: Definition: A spatial region or named place. and Identifier: http://rs.tdwg.org/dwc/terms/locality Has Domain: http://purl.org/dc/terms/Location Definition: The specific description of the place. Less specific geographic information can be provided in other geographic terms (higherGeography, continent, country, stateProvince, county, waterBody, island, islandGroup). This term may contain information modified from the the original to correct perceived errors or standardize the description. Comment: Example: "Bariloche, 25 km NNE via Ruta Nacional 40 (=Ruta 237)". For discussion see http://code.google.com/p/darwincore/wiki/Location However, the first is very wide, and does not give the information that the type of object is a place or city name (it could be circumscription names like a province), the second is free from text. In many densely populated areas, separating the city or village name for easier finding is recommended, because these terms do occur in gazetteers. Could this be added to DWC? -------- 2. If clarity is more important than brevity, I would greatly prefer stateOrProvince over the current stateProvince, which literally is the province of a state, which more less exists in Germany as administration province of a state of the federal republic (Regierungsbezirk). -------- 3. The definition of county (perhaps better more international as "County or Subprovince") is: Term Name: county Identifier: http://rs.tdwg.org/dwc/terms/county Has Domain: http://purl.org/dc/terms/Location Definition: The full, unabbreviated name of the next smaller political region than StateProvince (county, shire, department, etc.) in which the Location occurs. Comment: Examples: "Missoula", "Los Lagos", "Mataró". For discussion see http://code.google.com/p/darwincore/wiki/Location Here, wikipedia (http://en.wikipedia.org/wiki/County) suggests to interpret the German Kreis as equivalent to county; however, the literal definition above would require to map county to Regierungsbezirk. Many countries have a hierarchy of adminstrative political regions, and the highest may often not be the most relevant ones. I suggest to weaken the definition to a suggestions, perhaps: Definition: The full, unabbreviated name of the most relevant political region between cities or villages and states or provinces (county, shire, department, etc.) in which the Location occurs. Gregor -- --------------------------------- Dr. Gregor Hagedorn Heinrich-Seidel-Str. 2 12167 Berlin skype: g.hagedorn This message is sent on a personal basis and does not constitute an activity of the German Federal Government or its research institutions. Together with any attachments, this message is intended only for the person to whom it is addressed and may not be redistributed or published without permission.

3 10

Fwd: DWC occurrence identifier fields - confused
by John R. WIECZOREK 18 Aug '09

18 Aug '09

Forwarded, as agreed. The following exchange went offline temporarily - just bringing it back to show outcomes. Thanks, Lynn. ---------- Forwarded message ---------- From: Lynn Kutner <Lynn_Kutner(a)natureserve.org> Date: Tue, Aug 18, 2009 at 10:38 AM Subject: RE: DWC occurrence identifier fields - confused To: "tuco(a)berkeley.edu" <tuco(a)berkeley.edu> John - Thanks for the further comments / explanation. I know there is a lot of push-pull of what various people & organizations. I personally like the elegant simplicity of DWC for data sharing / discovery and it seems there are other standards (like ABCD?) that can take care of the "everything and the kitchen sink" approach. In addition, each organization will likely have their own internal data models that have been designed to meet their unique data management needs. No problem copying this to tdwg-content. Lynn -----Original Message----- From: gtuco.btuco(a)gmail.com [mailto:gtuco.btuco@gmail.com] On Behalf Of John R. WIECZOREK Sent: Tuesday, August 18, 2009 11:33 AM To: Lynn Kutner Subject: Re: DWC occurrence identifier fields - confused Comments inline below. Do you mind if I copy this to tdwg-content? On Mon, Aug 17, 2009 at 12:49 PM, Lynn Kutner<Lynn_Kutner(a)natureserve.org> wrote: > John - > > Thanks for the clarification / additional definitions. > > Now I wonder if all those ID fields are really needed in Darwin Core? > > Yes for internal data management needs, but I think of the DWC as for data sharing through portals such as GBIF and for data discovery through a portal is the level of detail of the original field collection "recordNumber" really as relevant? Yes, definitely. This may be the only way that duplicates can be identified. > Maybe I'm over simplifying, but if I want to get data from institution X then I think primarily of the primary record ID that they are using in their database. That will enalbe them to link to / select the correct records. If I want / need additional levels of detail (such as any previous ID values) I'd be inclined to follow up with them directly for that data. You might, but the person writing software to try to link things together automatically would be out of a job. > We share such a teeny amount of our data attributes through GBIF that we see it as a data discovery mechanism and not for data management. People definitely contact us directly when they need more detailed information. Agreed. DwC used to be something like a least common denominator. Now it is becoming more useful than that. Every term in the proposed standard has be requested by at least two independent groups, or has been in active use already. > Thanks - > Lynn Thank you! Good to talk these things through. I've added some of the explanatory notes to the Occurrence commentaries on the Darwin Core wiki at http://code.google.com/p/darwincore/wiki/Occurrence. > -----Original Message----- > From: gtuco.btuco(a)gmail.com [mailto:gtuco.btuco@gmail.com] On Behalf Of John R. WIECZOREK > Sent: Thursday, August 13, 2009 8:46 AM > To: Lynn Kutner > Subject: Re: DWC occurrence identifier fields - confused > > Hi Lynn, > > It's definitely not a dumb question. If you have it, so will others. > I'm wracking my brain on how to have definitions that don't have a domain bias and yet help people to know what the term means within their domain. It's really tough. Happily, we have the extra wiki pages to work with to help explain things further and give more examples. > Problem is, there is nothing there right now for these terms. Maybe together we can do something to amend the definitions, examples, and wiki explanations to at least clarify things for your domain. > > So, let me try to explain a bit further here. > > The occurrenceID is supposed to (globally) uniquely identify an occurrence record, whether it is a specimen-based occurrence, a one-time observation of a species at a location, or one of many occurrences of an individual who is being tracked, monitored, or recaptured. Making it globally unique is quite a trick, one foe which we don't really have good solutions in place yet, but one which ontologists insist is essential. TDWG and GBIF seem to be pushing LSIDs as the solution for this, but there remains great unrest among experts about whether this is a wise move. Anyway, LSID or not, the term is there and waiting. > > catalogNumber is unfortunate for a name, because it suggests a catalog, which suggests a specimen. The definition tries to ameliorate the potential bias by saying that it is a number to identify an occurrence record within a data set or collection. So, it could be a specimen catalog number or it could be a unique identifier for a record within an observation or animal movement data set. > > individualID is meant for any records that need to identify individuals for whom there may be more than one record. Banded birds, marine mammal photos allowing individual identification, individual trees resampled overtime, periodic biopsies on the same individuals, etc. could all use this term to group the records corresponding to individuals. > > recordNumber came directly from the idea of a collector's number - the one that the collector puts on a tag on a specimen in the field and writes in their notes. It isn't the same as the catalogNumber because that is usually only applied once the specimen gets accessioned into a collection. There may be corollaries to this for other disciplines, but I have no experience of them. > > Which ones you use is suggested by the rules for Simple Darwin Core (http://rs.tdwg.org/dwc/terms/simple/index.htm#rules) specifically rule 4: "Support (provide data in) as many fields as you can." > > I'm happy to get all of this right, so let me know if doubts remain, or if you have suggestions about how to clarify any of this within the definitions or supporting documentation. > > Sincerely, > > John > > On Wed, Aug 12, 2009 at 1:58 PM, Lynn Kutner<Lynn_Kutner(a)natureserve.org> wrote: >> Hi John - >> >> This may be such an astonishingly dumb question that I didn't want to send it to the list ... >> >> When I read through the draft DWC and try to figure out how we'd fit our data to DWC, the fields that currently have me stumped are the occurrence identifiers: >> >> occurrenceID A unique identifier for the Occurrence (as opposed to a particular digital record of the occurrence). In the absence of a persistent global unique identifier, construct one from a combination of identifiers in the record that will most closely make the occurrenceID globally unique. For a specimen, for example, use the form: "urn:catalog:[institutionCode]:[collectionCode]:[catalogNumber]. Examples: 1) "urn:lsid:nhm.ku.edu:Herps:32", 2) "urn:catalog:FMNH:Mammal:145732". >> >> catalogNumber An identifier (preferably unique) for the Occurrence within the data set or collection. Examples: "2008.1334", "145732a", "145732". >> >> individualID An identifier for an individual or named group of individual organisms represented in the Occurrence. Meant to accommodate resampling of the same individual or group for monitoring purposes. May be a global unique identifier or an identifier specific to a data set. Examples: "U.amer. 44", "Smedley", "Orca J 23". >> >> recordNumber An identifier given to the Occurrence at the time it was recorded. Often serves as a link between field notes and an Occurrence record, such as a specimen collector's number. >> >> >> It's really no clear to me how these fields relate to each other, how they differ, and which one(s) we'd use when we put our data on GBIF. >> >> Thanks for your help! >> Lynn >> >> Lynn Kutner >> NatureServe >> phone: (703) 797-4804 >> email: lynn_kutner(a)natureserve.org >> http://www.natureserve.org/ >> >> >

1 0

FW: dwc
by Ginzbarg, Steve 13 Aug '09

13 Aug '09

-----Original Message----- From: Ginzbarg, Steve Sent: Thursday, August 13, 2009 3:23 PM To: 'tuco(a)berkeley.edu' Subject: RE: [tdwg-content] dwc John, That's better. Some other possible wordings below. -----Original Message----- From: gtuco.btuco(a)gmail.com [mailto:gtuco.btuco@gmail.com] On Behalf Of John R. WIECZOREK Sent: Thursday, August 13, 2009 11:37 AM To: Ginzbarg, Steve Subject: Re: [tdwg-content] dwc Thanks for your tenacity and patience, Steve. I see what you are saying now. For the distances from surface, there is nothing saying explicitly what the nearest surface actually is. Is it the surface defined by the elevation or the surface defined by the depth? I think this can be resolved by the following change in definition for minimumDistanceAboveSurfaceInMeters from: "The lesser distance in a range of distance from the nearest surface in the vertical direction (positive for above, negative for below), in meters." to: "The lesser distance in a range of distance from a reference surface in the vertical direction, in meters. Use positive values for locations above the surface, negative values for locations below. If depth measures are given, the reference surface is the location given by the depth, otherwise the reference surface is the location given by the elevation." [Steve Ginzbarg] or "The lesser distance in a range of distance from a reference surface, either on land or underwater, in the vertical direction, in meters. Use positive values for locations above the surface, negative values for locations below." or "The lesser distance in a range of distance from a reference surface, either a land/air or a land/water interface, in the vertical direction, in meters. Use positive values for locations above the surface, negative values for locations below." A similar change would apply to the maximumDistanceAboveSurfaceInMeters. For coordinateUncertaintyInMeters I think we can solve the problem with the following simple change from: "The upper limit of the distance (in meters) from the given decimalLatitude and decimalLongitude describing a circle within which the whole of the Location is contained. Leave the value empty if the uncertainty is unknown, cannot be estimated, or is not applicable (because there are no coordinates). Zero is not a valid value for this term." to: "The horizontal distance (in meters) from the given decimalLatitude and decimalLongitude describing a circle within which the whole of the Location is contained. Leave the value empty if the uncertainty is unknown, cannot be estimated, or is not applicable (because there are no coordinates). Zero is not a valid value for this term." [Steve Ginzbarg] That's better. I think "smallest circle" is understood. or, more explicitly, "The horizontal distance (in meters) from the given decimalLatitude and decimalLongitude describing the smallest circle containing the whole of the Location. Leave the value empty if the uncertainty is unknown, cannot be estimated, or is not applicable (because there are no coordinates). Zero is not a valid value for this term." Would these be satisfactory changes? [Steve Ginzbarg] Yes. I had a hard time finding the link on the webpage to all the terms and definitions, http://rs.tdwg.org/dwc/terms/. John On Wed, Aug 12, 2009 at 3:33 PM, Ginzbarg, Steve<sginzbar(a)biology.as.ua.edu> wrote: > Hi John, > >> Term Name: minimumDistanceAboveSurfaceInMeters >> >> Definition: The lesser distance in a range of distance from the >> nearest surface in the vertical direction (positive for above, negative for >> below), in meters. >> >> Comment: Example: 1.5 meter sediment core from the bottom of a lake >> (at depth 20m) at 300m elevation; VerbatimElevation: "300m" >> MinimumElevationInMeters: "300", MaximumElevationInMeters: "300", >> VerbatimDepth: "20m", MinumumDepthInMeters: "20", MaximumDepthInMeters: >> "20", DistanceAboveSurfaceInMetersMinimum: "0", >> DistanceAboveSurfaceInMetersMaximum: "-1.5". >> >> Those would be the distances above the surface if the core was raised to the >> surface of the water. If it was still in place the numbers would be: >> Example: 1.5 meter sediment core from the bottom of a lake (at depth 20m) at >> 300m elevation; VerbatimElevation: "300m" MinimumElevationInMeters: "300", >> MaximumElevationInMeters: "300", VerbatimDepth: "20m", MinumumDepthInMeters: >> "20", MaximumDepthInMeters: "20", DistanceAboveSurfaceInMetersMinimum: >> "-21.5", DistanceAboveSurfaceInMetersMaximum: "-20". > > Explanation: The nearest surface in the example is the bottom of the > lake, therefore the example is correct. > > ditto maximumDistanceAboveSurfaceInMeters > > Given the "to the nearest surface" part of the definition, these terms > are not redundant; they were defined specifically to address the > problem of more than one offset from a vertical datum. > > [Steve Ginzbarg] It may be clear to the person recording the data which surface is the nearest but how is the person interpreting the data to know which surface was nearest, e.g. the surface of the water or the surface of the bottom of the lake? > >> Term Name: coordinateUncertaintyInMeters >> >> Definition: The upper limit of the distance (in meters) from the >> given decimalLatitude and decimalLongitude describing a circle within which >> the whole of the Location is contained. Leave the value empty if the >> uncertainty is unknown, cannot be estimated, or is not applicable (because >> there are no coordinates). Zero is not a valid value for this term. >> >> change "upper limit" to "lower limit" > > The coordinateUncertaintyInMeters is the maximum error distance as > defined in the GBIF Best Practices. It is definitely the upper limit, > not the lower limit. > > [Steve Ginzbarg] Maximum error - we could be off by at most this much; but the shortest radius that describes a circle that contains the whole location. (An infinite radius would describe a circle that contains the location. We're looking for the smallest radius whose circle still does. >> Steve Ginzbarg >

1 0

FW: dwc
by Ginzbarg, Steve 13 Aug '09

13 Aug '09

>>>From the Darwin Core Progress page, http://code.google.com/p/darwincore/wiki/DarwinCoreProgress, perhaps you could change the paragraph: The Documents The entry level document for the Darwin Core standard can be found at http://rs.tdwg.org/dwc/index.htm. This is where anyone new to the documents should start. to The Documents The entry level document for the Darwin Core standard can be found at http://rs.tdwg.org/dwc/index.htm. This is where anyone new to the documents should start. To go directly to a list of all Darwin Core terms and definitions go to <Darwin Core Terms: A quick reference guide> http://rs.tdwg.org/dwc/terms/. Steve -----Original Message----- From: gtuco.btuco(a)gmail.com [mailto:gtuco.btuco@gmail.com] On Behalf Of John R. WIECZOREK Sent: Thursday, August 13, 2009 3:36 PM To: Ginzbarg, Steve Subject: Re: [tdwg-content] dwc Mind posting the response to tdwg-content, where I can then respond again? Not sure what you mean or suggest by the last sentence "I had a hard time finding the link on the webpage to all the terms and definitions, http://rs.tdwg.org/dwc/terms/." Do you mean that it isn't clear that the Quick Reference Guide is the first place to look for them? Recommendations? -----Original Message----- From: Ginzbarg, Steve Sent: Thursday, August 13, 2009 3:23 PM To: 'tuco(a)berkeley.edu' Subject: RE: [tdwg-content] dwc John, That's better. Some other possible wordings below. -----Original Message----- From: gtuco.btuco(a)gmail.com [mailto:gtuco.btuco@gmail.com] On Behalf Of John R. WIECZOREK Sent: Thursday, August 13, 2009 11:37 AM To: Ginzbarg, Steve Subject: Re: [tdwg-content] dwc Thanks for your tenacity and patience, Steve. I see what you are saying now. For the distances from surface, there is nothing saying explicitly what the nearest surface actually is. Is it the surface defined by the elevation or the surface defined by the depth? I think this can be resolved by the following change in definition for minimumDistanceAboveSurfaceInMeters from: "The lesser distance in a range of distance from the nearest surface in the vertical direction (positive for above, negative for below), in meters." to: "The lesser distance in a range of distance from a reference surface in the vertical direction, in meters. Use positive values for locations above the surface, negative values for locations below. If depth measures are given, the reference surface is the location given by the depth, otherwise the reference surface is the location given by the elevation." [Steve Ginzbarg] or "The lesser distance in a range of distance from a reference surface, either on land or underwater, in the vertical direction, in meters. Use positive values for locations above the surface, negative values for locations below." or "The lesser distance in a range of distance from a reference surface, either a land/air or a land/water interface, in the vertical direction, in meters. Use positive values for locations above the surface, negative values for locations below." A similar change would apply to the maximumDistanceAboveSurfaceInMeters. For coordinateUncertaintyInMeters I think we can solve the problem with the following simple change from: "The upper limit of the distance (in meters) from the given decimalLatitude and decimalLongitude describing a circle within which the whole of the Location is contained. Leave the value empty if the uncertainty is unknown, cannot be estimated, or is not applicable (because there are no coordinates). Zero is not a valid value for this term." to: "The horizontal distance (in meters) from the given decimalLatitude and decimalLongitude describing a circle within which the whole of the Location is contained. Leave the value empty if the uncertainty is unknown, cannot be estimated, or is not applicable (because there are no coordinates). Zero is not a valid value for this term." [Steve Ginzbarg] That's better. I think "smallest circle" is understood. or, more explicitly, "The horizontal distance (in meters) from the given decimalLatitude and decimalLongitude describing the smallest circle containing the whole of the Location. Leave the value empty if the uncertainty is unknown, cannot be estimated, or is not applicable (because there are no coordinates). Zero is not a valid value for this term." Would these be satisfactory changes? [Steve Ginzbarg] Yes. I had a hard time finding the link on the webpage to all the terms and definitions, http://rs.tdwg.org/dwc/terms/. John On Wed, Aug 12, 2009 at 3:33 PM, Ginzbarg, Steve<sginzbar(a)biology.as.ua.edu> wrote: > Hi John, > >> Term Name: minimumDistanceAboveSurfaceInMeters >> >> Definition: The lesser distance in a range of distance from the >> nearest surface in the vertical direction (positive for above, negative for >> below), in meters. >> >> Comment: Example: 1.5 meter sediment core from the bottom of a lake >> (at depth 20m) at 300m elevation; VerbatimElevation: "300m" >> MinimumElevationInMeters: "300", MaximumElevationInMeters: "300", >> VerbatimDepth: "20m", MinumumDepthInMeters: "20", MaximumDepthInMeters: >> "20", DistanceAboveSurfaceInMetersMinimum: "0", >> DistanceAboveSurfaceInMetersMaximum: "-1.5". >> >> Those would be the distances above the surface if the core was raised to the >> surface of the water. If it was still in place the numbers would be: >> Example: 1.5 meter sediment core from the bottom of a lake (at depth 20m) at >> 300m elevation; VerbatimElevation: "300m" MinimumElevationInMeters: "300", >> MaximumElevationInMeters: "300", VerbatimDepth: "20m", MinumumDepthInMeters: >> "20", MaximumDepthInMeters: "20", DistanceAboveSurfaceInMetersMinimum: >> "-21.5", DistanceAboveSurfaceInMetersMaximum: "-20". > > Explanation: The nearest surface in the example is the bottom of the > lake, therefore the example is correct. > > ditto maximumDistanceAboveSurfaceInMeters > > Given the "to the nearest surface" part of the definition, these terms > are not redundant; they were defined specifically to address the > problem of more than one offset from a vertical datum. > > [Steve Ginzbarg] It may be clear to the person recording the data which surface is the nearest but how is the person interpreting the data to know which surface was nearest, e.g. the surface of the water or the surface of the bottom of the lake? > >> Term Name: coordinateUncertaintyInMeters >> >> Definition: The upper limit of the distance (in meters) from the >> given decimalLatitude and decimalLongitude describing a circle within which >> the whole of the Location is contained. Leave the value empty if the >> uncertainty is unknown, cannot be estimated, or is not applicable (because >> there are no coordinates). Zero is not a valid value for this term. >> >> change "upper limit" to "lower limit" > > The coordinateUncertaintyInMeters is the maximum error distance as > defined in the GBIF Best Practices. It is definitely the upper limit, > not the lower limit. > > [Steve Ginzbarg] Maximum error - we could be off by at most this much; but the shortest radius that describes a circle that contains the whole location. (An infinite radius would describe a circle that contains the location. We're looking for the smallest radius whose circle still does. >> Steve Ginzbarg >

2 1

dwc
by Ginzbarg, Steve 12 Aug '09

12 Aug '09

Here are my notes on the draft. Term Name: day Definition: The two-digit day of the month on which the Event occurred. Comment: Example: "9", "28". To be two-digit it would have to be "09" instead of "9" in the comment. I would recommend omitting "two-digit" from the definition. Term Name: higherGeographyID Definition: A unique identifier for the geographic region within with the Location occurred. within with -> within which Term Name: locality Definition: The specific description of the place. Less specific geographic information can be provided in other geographic terms (higherGeography, continent, country, stateProvince, county, waterBody, island, islandGroup). This term may contain information modified from the the original to correct perceived errors or standardize the description. delete 2nd "the" Term Name: minimumDistanceAboveSurfaceInMeters Definition: The lesser distance in a range of distance from the nearest surface in the vertical direction (positive for above, negative for below), in meters. Comment: Example: 1.5 meter sediment core from the bottom of a lake (at depth 20m) at 300m elevation; VerbatimElevation: "300m" MinimumElevationInMeters: "300", MaximumElevationInMeters: "300", VerbatimDepth: "20m", MinumumDepthInMeters: "20", MaximumDepthInMeters: "20", DistanceAboveSurfaceInMetersMinimum: "0", DistanceAboveSurfaceInMetersMaximum: "-1.5". Those would be the distances above the surface if the core was raised to the surface of the water. If it was still in place the numbers would be: Example: 1.5 meter sediment core from the bottom of a lake (at depth 20m) at 300m elevation; VerbatimElevation: "300m" MinimumElevationInMeters: "300", MaximumElevationInMeters: "300", VerbatimDepth: "20m", MinumumDepthInMeters: "20", MaximumDepthInMeters: "20", DistanceAboveSurfaceInMetersMinimum: "-21.5", DistanceAboveSurfaceInMetersMaximum: "-20". No reason the distance above surface should take the length of the core into account and the depth should not, so: Example: 1.5 meter sediment core from the bottom of a lake (at depth 20m) at 300m elevation; VerbatimElevation: "300m" MinimumElevationInMeters: "300", MaximumElevationInMeters: "300", VerbatimDepth: "20m", MinumumDepthInMeters: "21.5", MaximumDepthInMeters: "20", DistanceAboveSurfaceInMetersMinimum: "-21.5", DistanceAboveSurfaceInMetersMaximum: "-20". ditto maximumDistanceAboveSurfaceInMeters These terms are redundant with depth but I can't think of a way to redefine either depth or above surface that would not be confusing for users, e.g. eliminating above surface and recording distance above surface as negative depth; or eliminating depth and recording depths as negative distance above the surface. Why are the verbatimLatitude and verbatimLongitude terms needed? Isn't verbatimCoordinates sufficient? Term Name: coordinateUncertaintyInMeters Definition: The upper limit of the distance (in meters) from the given decimalLatitude and decimalLongitude describing a circle within which the whole of the Location is contained. Leave the value empty if the uncertainty is unknown, cannot be estimated, or is not applicable (because there are no coordinates). Zero is not a valid value for this term. change "upper limit" to "lower limit" Term Name: scientificName Definition: The taxon name (with date and authorship information if applicable). When forming part of and Identification, this should be the name in lowest level taxonomic rank that can be determined. This term should not contain identification qualifications, which should instead be supplied in the IdentificationQualifier term. part of and Identification-> part of an Identification Steve Ginzbarg

2 1

DwC review: comments
by Nico Cellinese 09 Aug '09

09 Aug '09

Hello, I am kind of late with this but I think still in time to drop a couple of comments about nomenclature before the review deadline. I think that phylogenetic nomenclature is not well accounted for. Clade names could be well accommodated right now, however, the types of phylogenetic definitions are not (node-based, branch-based, apomorphy- based and variations). There could be a few options on how to handle these (e.g., with annotations) , but I wanted to make sure that there is a will to take the PhyloCode into consideration. The phylogenetics community is using these names that are now slowly being published. Next year, after the Code will be published, many more names will be formally recognized and used in databases. This issue will have to be faced at some point, so why not right away. Any comments on this? Thanks! Cheers, Nico <><><><><><><><><><><><><><><><><><><><> Nico Cellinese, Ph.D. Assistant Curator, Herbarium & Informatics Adjunct Assistant Professor, Department of Biology Florida Museum of Natural History University of Florida 354 Dickinson Hall, PO Box 117800 Gainesville, FL 32611-7800, U.S.A. Tel. 352-273-1979 Fax 352-846-1861 http://www.flmnh.ufl.edu

2 2