- tdwg-content - lists.tdwg.org

FW: biostatus
by Kevin Richards 10 Sep '09

10 Sep '09

Not sure if Jerry's post got through to the list - it looked like it bounced. So I am posting again on his behalf... -----Original Message----- From: Jerry Cooper Sent: Friday, 11 September 2009 9:39 a.m. To: Kevin Richards; Blum, Stan; tuco(a)berkeley.edu Cc: tdwg-content(a)lists.tdwg.org Subject: RE: [tdwg-content] biostatus A lot of this was thought about when we were working on the IAS Profile schema and associated use-cases ... http://wiki.tdwg.org/InvasiveSpecies/ Agreed that 'biostatus' (which is an imprecisely defined trem) is a property of a taxon concept. In many domains there clearly a need to pass information about the presence/absence and indigenous/endemic/introduced/invasiveness etc, status of a taxon, in a defined geograhical area. Of course this is not primary data relating to specimens or observations, but is an aggregate opinion based on evidence available to the compiler. Open any book on any aspect of biogeography and you will find such statements and polygon boundaries. It is one of the elements gathered by Species2000. It certainly an implicit or explicit component of regional checklists. Our recently funded NZOR project (http://nzor.org.nz) will compile the first digital catalogue of life for New Zealand and a key requirement dicated by our funders (and biosecurity legislation) is accompanying evidence-based statements of the presence or absence of a taxon (concept) in New Zealand political, economic and biogeographical borders. Such statements only belongs in DwC in a most abstract extension of DwC relating to passing taxon concept related data, and not primary data on collections/observations. Jerry -----Original Message----- From: Kevin Richards Sent: Thursday, 10 September 2009 4:01 p.m. To: Blum, Stan; tuco(a)berkeley.edu Cc: tdwg-content(a)lists.tdwg.org Subject: RE: [tdwg-content] biostatus Absolutely, the invasive species people need to have their input here. Invasive species data is a great use case of biostatus data. There should be allowance for invasive attributes in the new Darwin Core, considering the invasive species group attempted to extend darwin core previously. I do believe biostatus applies to Taxon Concepts, not specimens (if that was what you were implying Stan), as you cannot really say that the specimen itself is invasive - it is the concept you have identified it to that can be deemed invasive, surely. Specimens can provide a "present" biostatus, but not "absent", nor biostatus origin, such as "exotic". So they are a source of biostatus data, but I dont think they are objects that biostatus is strictly attributed to. Kevin ________________________________________ From: Blum, Stan [SBlum(a)calacademy.org] Sent: Thursday, 10 September 2009 2:47 p.m. To: Kevin Richards; tuco(a)berkeley.edu Cc: tdwg-content(a)lists.tdwg.org Subject: RE: [tdwg-content] biostatus I don't know what the current thinking is regarding the invasive species work and the DwC, but what you're asking for, Kevin, seems to me to be a summary judgement about the occurrence (presence) of a species in a geographic region. I think individual organism occurrence records (note I don't use species occurrence) can be tagged with an attribute indicating that the record can be used for distribution analysis (but that may need to be further refined into native, naturalized (=invasive?), and cultivated/captive). I think the invasive species folks need to weigh in here about their use cases: data they want to analyze about organisms, versus summary statements they want to make about taxa. My two cents, -Stan ________________________________________ From: tdwg-content-bounces(a)lists.tdwg.org [tdwg-content-bounces(a)lists.tdwg.org] On Behalf Of Kevin Richards [RichardsK(a)landcareresearch.co.nz] Sent: Wednesday, September 09, 2009 7:08 PM To: tuco(a)berkeley.edu Cc: tdwg-content(a)lists.tdwg.org Subject: Re: [tdwg-content] biostatus I was just thinking to that the "locality" type component should be influenced by other geo components within TDWG - ideally it probably should be linked to TDWG regions, dublic core, ISO, or other vocab? Also, there is probably a time element in this. But I don't think we need to go there. :-) Kevin ________________________________________ From: gtuco.btuco(a)gmail.com [gtuco.btuco(a)gmail.com] On Behalf Of John R. WIECZOREK [tuco(a)berkeley.edu] Sent: Thursday, 10 September 2009 12:52 p.m. To: Kevin Richards Cc: tdwg-content(a)lists.tdwg.org Subject: Re: [tdwg-content] biostatus Makes sense, but need a "second" of the motion to include. On Wed, Sep 9, 2009 at 5:21 PM, Kevin Richards<RichardsK(a)landcareresearch.co.nz> wrote: > Yes, thats a good start, however, biostatus is a more complicated topic than that, eg whther it is "native" may depend on the region you are looking at - so region data needs to be included, and whether it is present or not also is another important piece of data. > > biostatus is also really a name/concept oriented piece of data, not specimen/occurrence. So maybe useful to have as domain (RDF) independent?? > > So I suggest a "class" fro biostatus that includes: > Biostatus (eg Endemic, Indigenous, Exotic) > BiostatusOccurrence (eg Present, Absent) > BiostatusRegion (eg, New Zealand) > > so you could have biostatus about a taxon in NZ like > "Aus bus" has biostatus in NZ, Exotic and Present > and a more lacalised biostatus for a region of NZ, eg > "Aus bus" has biostatus in Canterbury NZ, Exotic and Absent > > Make sense? > > Kevin > > ________________________________________ > From: gtuco.btuco(a)gmail.com [gtuco.btuco(a)gmail.com] On Behalf Of John R. WIECZOREK [tuco(a)berkeley.edu] > Sent: Thursday, 10 September 2009 11:53 a.m. > To: Kevin Richards > Cc: tdwg-content(a)lists.tdwg.org > Subject: Re: [tdwg-content] biostatus > > Hi Kevin, > > Not exactly sure what is meant by biostatus given what you have > written, but have a look at the term establishmentMeans > (http://rs.tdwg.org/dwc/terms/index.htm#establishmentMeans) and see if > that is the same or similar. > > John > > On Wed, Sep 9, 2009 at 4:46 PM, Kevin > Richards<RichardsK(a)landcareresearch.co.nz> wrote: >> This is a bit out of the blue, and I haven't had the chance to look into it >> fully, but... >> >> is there allowance for Biostatus in the new Dariwn Core format? >> >> An imprtant, and common field - ie Biostatus occurrence, locality, and >> status, eg "Present Indigenous" >> >> Kevin >> > > Please consider the environment before printing this email > Warning: This electronic message together with any attachments is confidential. If you receive it in error: (i) you must not read, use, disclose, copy or retain it; (ii) please contact the sender immediately by reply email and then delete the emails. > The views expressed in this email may not be those of Landcare Research New Zealand Limited. http://www.landcareresearch.co.nz > Please consider the environment before printing this email Warning: This electronic message together with any attachments is confidential. If you receive it in error: (i) you must not read, use, disclose, copy or retain it; (ii) please contact the sender immediately by reply email and then delete the emails. The views expressed in this email may not be those of Landcare Research New Zealand Limited. http://www.landcareresearch.co.nz _______________________________________________ tdwg-content mailing list tdwg-content(a)lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-content Please consider the environment before printing this email Warning: This electronic message together with any attachments is confidential. If you receive it in error: (i) you must not read, use, disclose, copy or retain it; (ii) please contact the sender immediately by reply email and then delete the emails. The views expressed in this email may not be those of Landcare Research New Zealand Limited. http://www.landcareresearch.co.nz

1 0

Re: [tdwg-content] biostatus
by renato＠cria.org.br 10 Sep '09

10 Sep '09

Hi Kevin, I think one of the roles of SPM (Species Profile Model) was to represent the kind of data you mentioned: http://wiki.tdwg.org/SPM/ A species profile points to a taxon concept (aboutTaxon) and may have several pieces of information attached, including one for distribution. Each piece of information should be able to indicate a geographical and/or temporal context. However, I don't know what is the current status of SPM and what are the plans for it. The invasive species group also defined terms for what you called "biostatus". They called it "species status" and you can find more information about the terms in the end of this page: http://www.niiss.org/cwis438/websites/GISINDirectory/tech/Model_info.php?Mo… Best Regards, -- Renato > Absolutely, the invasive species people need to have their input here. > Invasive species data is a great use case of biostatus data. > > There should be allowance for invasive attributes in the new Darwin Core, > considering the invasive species group attempted to extend darwin core > previously. > > I do believe biostatus applies to Taxon Concepts, not specimens (if that > was what you were implying Stan), as you cannot really say that the > specimen itself is invasive - it is the concept you have identified it to > that can be deemed invasive, surely. > > Specimens can provide a "present" biostatus, but not "absent", nor > biostatus origin, such as "exotic". So they are a source of biostatus > data, but I dont think they are objects that biostatus is strictly > attributed to. > > Kevin -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

1 0

NESCent Phyloinformatics VoCamp
by Nico Cellinese 09 Sep '09

09 Sep '09

NESCent Phyloinformatics VoCamp OPEN CALL FOR PARTICIPATION Integrating diverse biological data with the historical process of evolution is a grand challenge for 21st century biology. The interoperability of data from diverse fields (e.g., genetics, ecology, biodiversity, biomedicine) requires a technology infrastructure based on formalized, shared vocabularies. Developing such vocabularies is a community project. In order to build controlled vocabularies and ontologies, the National Evolutionary Synthesis Center (NESCent: http://nescent.org) is sponsoring a "Phyloinformatics VoCamp". We invite scientists from diverse sub-disciplines to apply for this event, as explained below. The application deadline is September 18, 2009. More information about motivation, plans, and preliminary ideas is available online at http://bit.ly/VoCamp_Proposal. Feel free to disseminate this notice to colleagues who may be interested.* A VoCamp (http://vocamp.org) is an intense, hands-on, working meeting with face-to-face interactions between a diverse group of people focused on vocabulary and ontology design, development and application. The Phyloinformatics VoCamp will include ontology and vocabulary developers from relevant efforts, experts on knowledge representation and reasoning, and users and developers of integrative applications that use these ontologies. This event will partially overlap with the Biodiversity Information Standards (TDWG: http://tdwg.org) Annual Conference in Montpellier, France, November 9-13, 2009. The VoCamp is an activity of the TDWG Interest Group on Phylogenetics Standards (http://wiki.tdwg.org/Phylogenetics) and is partly supported by TDWG and the Université Montpellier. GOALS AND ACTIVITIES -------------------- The objective of the event is to connect previously disparate ontology development efforts, stakeholder communities, and interoperability initiatives with shared objectives. Aside from sharing knowledge, expertise, and best practices, our goal is to build-out existing ontology resources in a hands-on manner in terms of ontological rigor, semantic richness, and modularity that supports effective reuse. We also plan to have programming expertise and activities present at the event, such as for necessary large-scale transformations, and especially for proof-of-concept applications that directly apply the ontologies being developed. On a long-term basis, we anticipate that the event, if successful, will give rise to similarly structured follow-up events organized by the participating stakeholder communities, such as TDWG, SONet (http://sonet.ecoinformatics.org), and OBO (http://www.obofoundry.org). ORGANIZATION ------------ The VoCamp will be 4 days in duration during November 7-11, 2009 and is co-located with the TDWG annual conference (http://www.tdwg.org/conference2009) in Montpellier, France. The first two days (Nov 7-8) will be dedicated entirely to VoCamp and the remainder of the event (Nov 10-11) will overlap with TDWG 'workshops days'. Participants will have the opportunity, and are encouraged, to interact with TDWG participants and attend conference sessions outside of the VoCamp. The specific vocabulary development targets will be selected by the participants partly in advance through a dedicated area on a wiki, a mailing list, and one or more conference calls, and partly on-site through an Open Space activity. The exact agenda for the event will be developed similarly, but will be largely devoted to ontology and vocabulary development time. At the event itself, participants will self-organize into small subgroups focused on particular targets. The VoCamp will conclude with a wrap-up session, and a report presented to the TDWG conference audience. We also anticipate that several "boot camps" will be needed to ensure a productive event for all participants, for example on ontology design and engineering, reasoning, and infrastructure for collaborative development of ontologies. We welcome comments and suggestions for issues in ontology development that are not explicitly addressed here or in our proposal but that could be addressed at the event. Please email the organizers at vocamp1(a)nescent.org with any suggestions. HOW TO APPLY ------------ The application consists of your cv and your responses to 6 questions about your experience, skills, objectives, support, and commitment to open software development. To apply, please fill out the online form at http://bit.ly/VoCamp_Form by September 18, and submit your CV to the organizers at vocamp1(a)nescent.org. NESCent will provide funds in support of expenses, including travel, accommodation, registration, and meals. Pending the final amount of funds available and the support requested by the participants, sponsorship may need to be capped. Logistical and travel details will be communicated to accepted and confirmed participants. We specifically encourage applications from members of under- represented groups, specifically women and minorities, and from graduate students and post-docs. If you have questions or are unsure whether to apply, please contact an organizer or write to vocamp1(a)nescent.org . Please understand that funding and space for this event are limited. We also need to balance a critical mass of expertise in specific areas with broad participation. Therefore, not all qualified applicants can be guaranteed acceptance. Yours, The Organizing Committee Arlin Stoltzfus, Chair (University of Maryland Biotechnology Institute) Nico Cellinese (University of Florida) Karen Cranston (Field Museum of Natural History) Hilmar Lapp (NESCent) Sheldon McKay (Cold Spring Harbor Laboratory, iPlant Collaborative) Enrico Pontelli (New Mexico State University) * This announcement is being sent to the following lists: evoldir, TDWG, SSB, nexml, phylows, CDAO, SONet, GBIF, Ecolog, TAXACOM.

1 0

[tdwg-phylo] NESCent Phyloinformatics VoCamp
by Nico Cellinese 09 Sep '09

09 Sep '09

NESCent Phyloinformatics VoCamp OPEN CALL FOR PARTICIPATION Integrating diverse biological data with the historical process of evolution is a grand challenge for 21st century biology. The interoperability of data from diverse fields (e.g., genetics, ecology, biodiversity, biomedicine) requires a technology infrastructure based on formalized, shared vocabularies. Developing such vocabularies is a community project. In order to build controlled vocabularies and ontologies, the National Evolutionary Synthesis Center (NESCent: http://nescent.org) is sponsoring a "Phyloinformatics VoCamp". We invite scientists from diverse sub-disciplines to apply for this event, as explained below. The application deadline is September 18, 2009. More information about motivation, plans, and preliminary ideas is available online at http://bit.ly/VoCamp_Proposal. Feel free to disseminate this notice to colleagues who may be interested.* A VoCamp (http://vocamp.org) is an intense, hands-on, working meeting with face-to-face interactions between a diverse group of people focused on vocabulary and ontology design, development and application. The Phyloinformatics VoCamp will include ontology and vocabulary developers from relevant efforts, experts on knowledge representation and reasoning, and users and developers of integrative applications that use these ontologies. This event will partially overlap with the Biodiversity Information Standards (TDWG: http://tdwg.org) Annual Conference in Montpellier, France, November 9-13, 2009. The VoCamp is an activity of the TDWG Interest Group on Phylogenetics Standards (http://wiki.tdwg.org/Phylogenetics) and is partly supported by TDWG and the Université Montpellier. GOALS AND ACTIVITIES -------------------- The objective of the event is to connect previously disparate ontology development efforts, stakeholder communities, and interoperability initiatives with shared objectives. Aside from sharing knowledge, expertise, and best practices, our goal is to build-out existing ontology resources in a hands-on manner in terms of ontological rigor, semantic richness, and modularity that supports effective reuse. We also plan to have programming expertise and activities present at the event, such as for necessary large-scale transformations, and especially for proof-of-concept applications that directly apply the ontologies being developed. On a long-term basis, we anticipate that the event, if successful, will give rise to similarly structured follow-up events organized by the participating stakeholder communities, such as TDWG, SONet (http://sonet.ecoinformatics.org), and OBO (http://www.obofoundry.org). ORGANIZATION ------------ The VoCamp will be 4 days in duration during November 7-11, 2009 and is co-located with the TDWG annual conference (http://www.tdwg.org/conference2009) in Montpellier, France. The first two days (Nov 7-8) will be dedicated entirely to VoCamp and the remainder of the event (Nov 10-11) will overlap with TDWG 'workshops days'. Participants will have the opportunity, and are encouraged, to interact with TDWG participants and attend conference sessions outside of the VoCamp. The specific vocabulary development targets will be selected by the participants partly in advance through a dedicated area on a wiki, a mailing list, and one or more conference calls, and partly on-site through an Open Space activity. The exact agenda for the event will be developed similarly, but will be largely devoted to ontology and vocabulary development time. At the event itself, participants will self-organize into small subgroups focused on particular targets. The VoCamp will conclude with a wrap-up session, and a report presented to the TDWG conference audience. We also anticipate that several "boot camps" will be needed to ensure a productive event for all participants, for example on ontology design and engineering, reasoning, and infrastructure for collaborative development of ontologies. We welcome comments and suggestions for issues in ontology development that are not explicitly addressed here or in our proposal but that could be addressed at the event. Please email the organizers at vocamp1(a)nescent.org with any suggestions. HOW TO APPLY ------------ The application consists of your cv and your responses to 6 questions about your experience, skills, objectives, support, and commitment to open software development. To apply, please fill out the online form at http://bit.ly/VoCamp_Form by September 18, and submit your CV to the organizers at vocamp1(a)nescent.org. NESCent will provide funds in support of expenses, including travel, accommodation, registration, and meals. Pending the final amount of funds available and the support requested by the participants, sponsorship may need to be capped. Logistical and travel details will be communicated to accepted and confirmed participants. We specifically encourage applications from members of under- represented groups, specifically women and minorities, and from graduate students and post-docs. If you have questions or are unsure whether to apply, please contact an organizer or write to vocamp1(a)nescent.org . Please understand that funding and space for this event are limited. We also need to balance a critical mass of expertise in specific areas with broad participation. Therefore, not all qualified applicants can be guaranteed acceptance. Yours, The Organizing Committee Arlin Stoltzfus, Chair (University of Maryland Biotechnology Institute) Nico Cellinese (University of Florida) Karen Cranston (Field Museum of Natural History) Hilmar Lapp (NESCent) Sheldon McKay (Cold Spring Harbor Laboratory, iPlant Collaborative) Enrico Pontelli (New Mexico State University) * This announcement is being sent to the following lists: evoldir, TDWG, SSB, nexml, phylows, CDAO, SONet, GBIF, Ecolog, TAXACOM.

1 0

[tdwg-sdd] TDWG meeting 2009 in Montpellier - Biological Descriptions Presentations
by Gregor Hagedorn 07 Sep '09

07 Sep '09

Who is presently working on biological descriptions management, analysis and identification and coming to the http://www.tdwg.org/conference2009/ We are inviting presentation of current work - outside of the SPM activities, which are covered by a separate session - of these topics in the session of the "Biological Descriptions Interest Group : Identification keys, documents, platforms, and infrastructure." 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.

1 0

[tdwg-phylo] Interest Group Charter: Need feedback
by Hilmar Lapp 06 Sep '09

06 Sep '09

Hi all, as I'm sure you've noticed already, the 2009 TDWG Conference is coming up and only about 2 months away. Nico and I hope to see as many of you there as possible! As the one remaining TODO needed to complete the formal establishment of our TDWG Interest Group, we need to get the group's charter written, finalized, and approved. Nico and I have now written a draft charter here: http://docs.google.com/View?id=dhdjhbvd_65ff7bp3dn Since in order to be approved by the executive committee in time for the 2009 conference it needs to be submitted rather soon. So, we'd be much obliged if you can review the draft and give us feedback, comments, and suggestions by Friday, Sep 11, so we can incorporate it in time for submitting the final version on Monday, Sep 14. FYI, there'll likely be significant activities of our group at the event, the announcements and Calls for Participation for which will be posted here over the coming week. Pending final approval for funding and logistics, one of these will be a VoCamp; check out http://evoinfo.nescent.org/VoCamp1_Proposal if you're curious. Cheers, Hilmar & Nico

1 0

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

26 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