August 2009 - tdwg-content

NCD and DwC
by John R. WIECZOREK 27 Aug '09

27 Aug '09

Hi Wouter and Neil (and others), I hope both of you are well. I know this may be a busy time (or, better, vacation time), but I hope that you have had a chance to consider recent discussions on tdwg-content about the relationships between DwC, NCD and the TDWG Ontology. In addition to those public discussions, I'm adding a few questions and comments I have had during the progression of the Darwin Core Review. I'm cc'ing those having a clear vested interest in resolution on both sides. I would urge you to look at the relevant tdwg-content commentary as well as my concerns from the messages below so that we can hopefully quickly come to a consensus on joint plan. I say quickly because I am eager that DwC review shouldn't undergo further unnecessary delays. In case it's a bit much to go through all of the "literature" relevant to the proposal I'm making, and in hopes of facilitating quick solutions, I'll summarize. 1) Dublin Core recommends the use of the dcterms rather than their antiquated dc counterparts. Shouldn't NCD follow suit? Specific example: instead of http://purl.org/dc/elements/1.1/source, use http://purl.org/dc/terms/source. 2) NCD is using terms from the TDWG ontology, which is to date an unfinished academic exercise without any review. This dependency seems to me to guarantee that NCD will require revision when the ontology is revised. This wouldn't necessarily be required if NCD took the reigns and defined terms that aren't already in another standard (the Ontology does not fit into this category) within its own domain. Specifically, abandon http://rs.tdwg.org/ontology/voc/ in favor of http://rs.tdwg.org/ncd/terms/. 3) Reword some of the NCD term definitions so that NCD can be used more generally for data sets (data collections), and not just for object collections. With these commitments, DwC could safely move forward reusing NCD terms. Without the last two, DwC will have to redefine terms such as collectionID. Following are relevant message excerpts from previous tdwg-content postings: ----- from John R. WIECZOREK <tuco(a)berkeley.edu> reply-to tuco(a)berkeley.edu to TDWG Content Mailing List <tdwg-content(a)lists.tdwg.org> date Thu, Jul 23, 2009 at 6:20 PM subject Darwin Core Collection-related terms I have taken the content of the Darwin Core Issues 32 and 33 to post here as they both require discussion before an unambiguous recommendation can be made. >>>From http://code.google.com/p/darwincore/issues/detail?id=32 Reported by ren...(a)cria.org.br Term Name: collectionID Recommendation: Reuse the term which is already defined in NCD (on the other hand, the NCD term defined in the corresponding RDF file should probably not be restricted to a specific domain). Submitter: Renato De Giovanni Comment 1 by gtuco.btuco This is indeed intended to be the same term. Can you provide the URI to the term in NCD? Status: Accepted Labels: Milestone-Release1.0 Priority-Critical Comment 2 by ren...(a)cria.org.br Currently the URI is: http://rs.tdwg.org/ontology/voc/Collection#collectionId But I think that relationship terms like this one should probably not be bound to a domain since they can be used by objects from many different classes. I'm not sure if it's possible to change NCD and if the NCD creators would agree with this change. Perhaps a better URI for this term would be: http://rs.tdwg.org/ontology/voc/collectionId >>>From http://code.google.com/p/darwincore/issues/detail?id=33 Reported by ren...(a)cria.org.br Term Name: collectionCode Recommendation: Reuse existing term from NCD, but I would probably also suggest to change the NCD term from http://rs.tdwg.org/ontology/voc/Collection#acronymOrCoden to http://rs.tdwg.org/ontology/voc/collectionCode (without a domain). It would be nice to know Markus' or Roger's opinion about this, since they participated in the NCD group. Submitter: Renato De Giovanni ------- from Tim Robertson <trobertson(a)gbif.org> to tuco(a)berkeley.edu cc TDWG Content Mailing List <tdwg-content(a)lists.tdwg.org> date Fri, Jul 24, 2009 at 1:12 AM subject Re: [tdwg-content] Darwin Core Collection-related terms Hi John, Renato Thinking aloud, some possible options I see might be: a) - omit it from the DwC terms altogether b) - reuse the existing URI if the NCD term domain was derestricted c) - keep a duplicate term in the DwC NS d) - ? keep a duplicate term in the DwC NS and add some kind of "is equivalent of" to the NCD acronymOrCoden e) - ? keep a duplicate term in the DwC NS and have NCD acronymOrCoden do some "refinement" of dwc:collectionCode My preference is for c) (or if possible e) for clear boundaries of dwc and also maintainability reasons. To me, DwC fits nicely as a set of commonly used terms which are unrestricted to domain classes, and extend the terms offered by the DublinCore Metadata Terms. Using these terms we can assemble models/schemas etc. To say DwC now also includes terms from other namespaces (which are currently restricted to domains), I think might become more difficult to grasp and maintain. I also wonder if going down the route of b) or d) for one term could open the floodgates for a lot of other terms (http://rs.tdwg.org/dwc/terms/index.htm#genus -> http://rs.tdwg.org/ontology/voc/TaxonName#genusPart) and effectively move towards being an "index of data and object properties in the TDWG ontology". Just some thoughts, Tim ------- from renato(a)cria.org.br to TDWG Content Mailing List <tdwg-content(a)lists.tdwg.org> date Fri, Jul 24, 2009 at 6:52 AM subject Re: [tdwg-content] Darwin Core Collection-related terms Hi Tim, Nice summary. My preference is for b. Considering that NCD follows the same principles of this new DarwinCore version, I see no reason for duplicating the same term. No matter how much we try to keep boundaries clear between standards, there will always be some kind of semantic overlap between them. Having the same terms defined under different namespaces can be very confusing for users. I think TDWG should try to make things as reusable as possible. To be more specific, I would suggest the following changes to NCD: 1) Remove the domain from collectionId and institutionId and rename them to "Id" so that the URI becomes: http://rs.tdwg.org/ontology/voc/Collection#Id http://rs.tdwg.org/ontology/voc/Institution#Id 2) Remove the domain from #acronymOrCoden (Collection) and rename it to "Code" so that the URI becomes: http://rs.tdwg.org/ontology/voc/Collection#Code 3) Add a Code property in Institution (without a domain) making it: http://rs.tdwg.org/ontology/voc/Institution#Code Then DarwinCore or any other standard can easily reuse these terms. Depending on how this gets solved, yes, I think we should open the floodgates... Best Regards, Renato ------ from John R. WIECZOREK <tuco(a)berkeley.edu> reply-to tuco(a)berkeley.edu to Lynn Kutner <Lynn_Kutner(a)natureserve.org> cc TDWG Content Mailing List <tdwg-content(a)lists.tdwg.org> date Fri, Jul 31, 2009 at 12:57 PM subject Re: [tdwg-content] InstitutionCode Issue - ownership vs. custodianship The codes are now meant for any data set (a collection of data), not just collections of objects. They were actually always meant to be that way, but the descriptions had their origins in the specimen collections realm. Specifically, the following terms can all be used to identify where data are coming from originally: institutionCode collectionCode collectionID datasetID while the Dublin Core terms dc:rights, and dc:rightsHolder can be used to describe the original or other vested interests. To be more clear about what I meant about collection-related terms, I would propose changing the descriptions as follow: institutionCode: "The name (or acronym) in use by the institution administering the original record." collectionCode: "The name (or acronym) identifying the original collection or data set from which the record was derived." collectionID: "A unique identifier for the original collection or dataset from which the record was derived. Recommended best practice is to use the identifier in a collections registry such as the Biodiversity Collections Index (http://www.biodiversitycollectionsindex.org/)." datasetID: "An identifier for the data set. May be a global unique identifier or an identifier specific to a collection or institution." (unchanged) catalogNumber: An identifier (preferably unique) for the record within the data set or collection.

5 8

Re: [tdwg-content] dwc: city to county
by John R. WIECZOREK 26 Aug '09

26 Aug '09

Hi Gregor, Sorry to remain confusing (it's all so clear to me ;-) ). I think what you are trying to do is relate records by features they have in common, features that one might find in gazetteers of named places. That's not what the locationID is for. locationID is the identifier for the Location. The Location consists of all of those fields having to do with place. If two Locations differ in any of the content of any of the fields in Location, they should have different locationIDs. This is consistent with the use of class identifiers throughout the rest of the Darwin Core. So, you said, "I assume that the locality is known in detail, e.g. "E of little pond 100 S of village X". Can the localityID for village X be given or not?" The answer is "No, the locationID for village X can exist, but it shouldn't be the locationID of the record referring to the detailed place that mentions village X." I hope that's clearer. John On Tue, Aug 18, 2009 at 2:41 PM, Gregor Hagedorn<g.m.hagedorn(a)gmail.com> wrote: >> But I think you misunderstood me. The >> localityID can apply to any level of granularity, but it should always >> be the id for the whole of the Location, not some arbitrary part of >> it, such as the stateProvince in one case and country in another. >> >> In other words, if a country, stateProvince, and county were given >> with a localityID, that localityID should apply to the combination of >> the three (in other words, the county, within that stateProvince >> within that country). If a locality were also given, then the id >> shoould be for that locality within that county within that >> stateProvince within that country. The id could even apply to >> individual georeferences within named places. > > Thanks John, but sorry, I still don't understand. I assume that the > locality is known in detail, e.g. "E of little pond 100 S of village > X". Can the localityID for village X be given or not? I thought your > counterexample would preclude that. You say "the whole content of the > Location part of the record, not just one part of it". Is the village > Gazetteer ID a "part" in that sense or not? Or, shall the location > details (sublocation) be given elsewhere? > > Gregor >

3 8

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