- tdwg-content - lists.tdwg.org

Re: [tdwg-content] Implementing Darwin Core in RDF
by Steve Baskauf 28 Aug '16

28 Aug '16

I looked at the tdwg-content archives to try to figure out which of the last two emails that I wrote were actually sent out to the list. This one below does not show up in the archives because "An HTML attachment was scrubbed...", apparently the actual email. I'll try sending it again in hopes that the message actually survives. The other message that contained comments about Douglas' example files (and which actually had attachments) never came to me, but shows up in the archives at http://lists.tdwg.org/pipermail/tdwg-content/2016-August/003642.html I'm not sure what is going on with the listserv, my spam filter, or both. Steve -------- Original Message -------- Subject: Re: [tdwg-content] Implementing Darwin Core in RDF Date: Fri, 26 Aug 2016 10:44:45 -0500 From: Steve Baskauf <steve.baskauf(a)vanderbilt.edu> Organization: Vanderbilt University Dept. of Biological Sciences To: Douglas Campbell <Douglas.Campbell(a)tepapa.govt.nz>, "tdwg-content(a)lists.tdwg.org" <tdwg-content(a)lists.tdwg.org> References: Douglas (and the list), I took some time to look at your Turtle file, but will have to come back to it again later when I have more time before giving you specific feedback. However, I wanted to make a few general comments to express how I think about the use of RDF in the biodiversity informatics context. Before embarking down the path of exposing metadata as RDF, I think that one needs to ask the question: "Why do I want to expose RDF?" There are several things that you get with RDF: 1. It's machine-readable. 2. It's a W3C standard that enables linking resources described by different data providers as a graph. 3. RDF triples from different sources can easily be aggregated in a triplestore and be queried using SPARQL. 4. It is compatible with machine reasoning. If all you care about is item #1, then RDF is probably more trouble than it is worth. There are more conventional means for providing access to data without requiring human intervention, with vanilla JSON being a prime example. If your primary concern is breaking down data silos (i.e. you like the idea of Linked Data), then item #4 is probably more trouble that it's worth. Machine reasoning is possible, but carrying out effective, non-trivial reasoning, requires a clear idea of what kind of reasoning you want to undertake and careful thought about how to structure the RDF. RDF isn't the only way to achieve item #2. Although JSON-LD can be valid RDF, it doesn't have to be. There also other popular non-RDF graph database options may be less troublesome if all you care about is linking data as a graph. It seems to me that item #3 is the sweet spot where the potential benefits of using RDF could outweigh its hassles. IF multiple data providers exposed their data using a consistent graph topology, a machine could harvest triples from the various providers, throw them into a standard triplestore, and other machines could query the aggregated data using SPARQL to ask interesting questions. All of this could be done in an automated fashion, with little or no human intervention. (There is the additional problem of providers disciplining themselves to using consensus URIs to identify resources that would be linked across data silos rather than minting their own new ones, but that's a different issue that I won't get into in this email.) However, if the multiple providers each use their own graph topology, then there are problems. Simply merging the triples into a single graph would be no problem. However, constructing a query that would work with every possible graph model that providers dream up would be virtually impossible. So if one aspires to merge RDF triples from multiple providers, the burden of enabling querying that will work with all data can fall at three places in the workflow: 1. The burden could fall on *providers* to discipline themselves to follow a consensus graph model. This requires them to express their triples as a graph that might not correspond to their native data model, but once that is done, no further action would be required down the pipeline. 2. The burden could fall on *aggregators* to "clean up" triples as they are ingested into the triplestore. For example, it's not difficult to create SPARQL construct queries that would add nodes that aren't present in the providers data but that are needed for consistency with the graph model used by the aggregator. However, that would depend on the aggregator to create a sort of "mapping" for each provider that uses a different graph model. It's likely that would require at least some human intervention, which is at odds with the goal of automated machine discovery and ingestion. 3. The burden could fall on the *users* who want to query the aggregated triples. The "dirty" triples from multiple providers following differing graph models could just be thrown together in a triplestore. Those who want to query the data would have to create complex queries that were designed to catch all of the variations in graph topologies that providers might reasonably dream up, or else risk missing some results that might be important. It seems likely that this approach would be doomed to failure. Who would want to waste their time doing all that work when there would be a high probability of missing some results anyway? Although the second option would probably be feasible, in order to achieve the real promise of RDF for our community, it seems to me like option #1 would be the way to go. Bringing this back to the specific example of Douglas' data and Darwin-SW, Darwin-SW was designed with the intention of facilitating aggregation of RDF metadata from diverse sources: traditional museum specimens, event-oriented occurrences (bioblitzes, trawls), mark-recapture, repeated samples, collection of tissues/DNA without collecting the organism, camera traps, observations without collection (e.g. birder observations), etc. Every one of these categories of data providers are going to have some part of the Darwin-SW model that they don't care about. Museums may care about specimens but not organisms. Birders may care about organisms but not specimens. Bioblitzers may care passionately about events with many occurrences, while mark-recapture people may think that events are useless since every occurrence happens at a separate event. In order for Darwin-SW to work as intended, each kind of provider is going to just have to bite the bullet and create nodes for every kind of resource in the Darwin-SW model whether they like it or not. This is very much NOT in the wild-west spirit of RDF where Anybody can say Anything about Any resource. But if one cares about standardization, one will follow the template even if it doesn't fit perfectly with the provider's situation. In writing Darwin-SW, we rigged it (some would say poisoned it) with semantics that cause a graph to become inconsistent if the Darwin-SW object properties are used to join classes in a way that's inconsistent with the Darwin-SW model. I won't go into the details here - you can read about them in section 3.2 of the paper [1]. We've received some criticism for doing that, and perhaps it was a bad idea. But that's the way things stand at the present. It's a sort of veiled threat that says, "there's nothing to stop you from using the Darwin-SW object properties inappropriately, but if you do, you will create a graph that a reasoner will flag as inconsistent". If a provider is bothered by that, it's better to mint its own object properties and not use the Darwin-SW ones. I'll try to provide a more direct response about Douglas' sample data later on. One thing that I might say now is that I'm not sure that I understand what Douglas means when he says "it would be impossible to create an Organism entity. And in fact we will not create Organism entities as we don’t need them in our context". If the problem is a reluctance to mint and maintain URIs for resources that don't play an important role in the data, it's quite possible to just let them be blank nodes without URIs. If the issue is that the Organism doesn't have an identification, that's no problem. An Organism can have zero to many identifications at any particular time. New identifications can be added at any point in the future. Steve [1] http://www.semantic-web-journal.net/content/darwin-sw-darwin-core-based-ter… Douglas Campbell wrote: > > Thank you all for your feedback. > > > > I am hopeful there will eventually be a ‘standard’ vocabulary for the > DwC associations. In the meantime it looks like DSW will suit us the > best. dwcFP is quite loose (and having version numbers in the IRI > means the namespace has broken once already). BCO is quite > bewildering – I like the solidity of underlying OBO framework, but BCO > has a steep learning curve and doesn’t seem to tie into well-known LD > ontologies. > > > > The downside of DSW for us is the extra abstract Occurrence and > Organism entities. We basically hold specimens from field collection > events that we identify – that is the data in our collection > management system, so the other entities would just be fabricated for > data exchange (not because we specifically model or store them). > > > > I have mocked up a herbaria record starting from the specimen point of > view (the core things that we hold in our collections). This is > attached as turtle and also our original JSON-LD (converted at > http://json-ld.org/playground/ ). > > > > *I had to go to Occurrence directly from the Specimen/Token using > dsw:evidenceFor (rather than via Organism and dsw:hasOccurence) as it > may not have been identified - meaning it would be impossible to > create an Organism entity. And in fact we will not create Organism > entities as we don’t need them in our context. > > * The Occurrence is just a placeholder (since we don’t have data for > it), which means I have associated the Agent to the Event rather than > the Occurrence – it so happens that this is valid as the domain isn’t > specified in dwciri:recordedBy. > > *I have include properties of linked-to entities because we need them > populated as part of the web API for searching, etc. This is similar > to the DwC concept of convenience properties. > > * There’s a few other messy parts like what IRIs we will create for > the Occurrence and Identification entities. > > > > I’d be interested in any comments about whether this is on the right > track and/or would be considered conformant DwC RDF J > > > > Cheers, > > Douglas > > > > > > *From:* tdwg-content [mailto:tdwg-content-bounces@lists.tdwg.org] *On > Behalf Of *John Deck > *Sent:* Thursday, 18 August 2016 4:02 a.m. > *To:* tdwg-content(a)lists.tdwg.org > *Subject:* Re: [tdwg-content] Implementing Darwin Core in RDF > > > > Another angle to consider here is using the Biological Collections > Ontology (https://github.com/BiodiversityOntologies/bco), which is > part of the OBO Foundry framework (http://www.obofoundry.org/), and > for which development and work has been done in integrating with > Darwin Core and Audubon Core > (e.g. http://www.ncbi.nlm.nih.gov/pmc/articles/PMC4511409/). The OBO > community has a longer history with the biomedical community but > gaining traction in biodiversity. Since these are all ontologies, > there should be less confusion on the meaning of classes. For example, > the notion of Observation in DwC is broken down into at least some of > the following classes: "Observing process", "Material target of > observation", "Material target of observation role". Relations are > well specified as well and drawn from the Relations Ontology > (http://www.obofoundry.org/ontology/ro.html). BTW, along with the PPO > (plant phenology ontology > -- https://github.com/PlantPhenoOntology/PPO) team, i'm working on > annotating instance data with BCO and PPO now, an ongoing project and > we will have more information on this effort at the upcoming TDWG > meeting. Happy to answer additional questions you have. > > > > John Deck > > > > On Wed, Aug 17, 2016 at 7:59 AM, Paul J. Morris <mole(a)morris.net > <mailto:mole@morris.net>> wrote: > > While commenting on the RDF guide, I wrote implementations of delivery > of flat Darwin Core in RDF into Symbiota and the Harvard University > Herbaria web search using content negotiation. Symbiota, when an > occurrence (or agent record) is requested with an accept header of > text/turtle; will deliver the occurrence record in a turtle > serialization (an example is below), when requested with an accept > header of application/rdf+xml will return flat Darwin Core in RDF/XML > > For structured relations beyond flat Darwin Core, there is another > alternative to darwin-sw (which is also in use in the wild), dwcFP: > http://filteredpush.org/ontologies/FP/2.0/dwcFP.owl Bob Morris can > probably comment further, but one of the design goals of dwcFP was > fewer added inferences than darwin-sw (object properties have ranges > specified, but not domains). > > dwcFP defines a set of object properties for making relations between > core Darwin Core classes that we've been using in annotations: > > owl:ObjectProperty rdf:about="dwcFP:hasIdentification" > owl:ObjectProperty rdf:about="dwcFP:usesTaxon" > owl:ObjectProperty rdf:about="dwcFP:hasCollectingEvent" > owl:ObjectProperty rdf:about="dwcFP:hasLocality" > owl:ObjectProperty rdf:about="dwcFP:hasGeologicalContext" > owl:ObjectProperty rdf:about="dwcFP:hasGeoreference" > owl:ObjectProperty rdf:about="dwcFP:hasAssociatedMedia" > > One object property we added specifically to simplyfy SPARQL queries on > taxonomic trees: > > owl:ObjectProperty rdf:about="dwcFP:descendantTaxonOf" > > And additional object properties that cover more possible relations: > > owl:ObjectProperty rdf:about="dwcFP:relationProperty" > owl:ObjectProperty rdf:about="dwcFP:hasAcceptedNameUsage" > owl:ObjectProperty rdf:about="dwcFP:namePublishedIn" > owl:ObjectProperty rdf:about="dwcFP:hasOriginalNameUsage" > owl:ObjectProperty rdf:about="dwcFP:hasParentNameUsage" > owl:ObjectProperty rdf:about="dwcFP:hasScientificName" > owl:ObjectProperty rdf:about="dwcFP:hasTaxonConcept" > owl:ObjectProperty rdf:about="dwcFP:taxonomicAuthorityFor" > owl:ObjectProperty rdf:about="dwcFP:nomenclaturalCode" > owl:ObjectProperty rdf:about="dwcFP:nomenclaturalStatus" > > Attached is an example RDF document (which is a commented extract from > the body of an annotation in a new occurrence annotation document) > that describes an occurrence. There were about 350,000 such occurrence > records wrapped in annotations generated in the NEVP project. This > representation preceeded the Darwin Core RDF guide, and I've added a > couple of comments about things we would do differently now. > > In using dwcFP, we encountered the same kind of questions you are > raising about where to place datatype properties that might go in more > than one place. We ended up hanging dwc:scientificName, > dwc:scientificNameAuthorship, etc, off of the Identification, and then > a Taxon (through dwcFP:usesTaxon) off the Identification, with only a > guid hung off the Taxon. Bob can probably comment further, but I think > our motivation for this was that the new occurrence annotation > documents are intended to describe transcription of data off of > specimens (and container (herbarium sheet and folder)), and that > conceptually these scientfic names were properties of transcriptions of > identifications. If I recall correctly, we are doing the opposite in > new identification annotations (hanging dwc:scientificName off of a > Taxon instance). > > -Paul > > -- > > Example flat Darwin Core occurrence record as RDF produced by Symbiota: > > http://symbiota4.acis.ufl.edu/scan/portal/collections/individual/index.php?… > <http://symbiota4.acis.ufl.edu/scan/portal/collections/individual/index.php?…> > with > HTTP Accept (through, for example, the Modify Headers firefox plugin): > text/turtle;q=1.0,text/xml,application/xml,application/xhtml+xml,text/html; > q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 > > Delivers: > > @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns# > <http://www.w3.org/1999/02/22-rdf-syntax-ns>> . > @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema# > <http://www.w3.org/2000/01/rdf-schema>> . > @prefix owl: <http://www.w3.org/2002/07/owl# > <http://www.w3.org/2002/07/owl>> . > @prefix foaf: <http://xmlns.com/foaf/0.1/> . > @prefix dwc: <http://rs.tdwg.org/dwc/terms/> . > @prefix dwciri: <http://rs.tdwg.org/dwc/iri/> . > @prefix dc: <http://purl.org/dc/elements/1.1/> . > @prefix dcterms: <http://purl.org/dc/terms/> . > @prefix dcmitype: <http://purl.org/dc/dcmitype/> . > <urn:uuid:00032bdf-8862-4ca1-b8a6-ba35ee59f56a> > a dwc:Occurrence ; > dwc:institutionCode "ASNP" ; > dwc:collectionCode "ENT" ; > dwciri:inCollection > <urn:uuid:af7140c3-4aa2-41ac-b3e9-4c7415b3ce90> ; a > dcmitype:PhysicalObject ; dwc:basisOfRecord "PreservedSpecimen" ; > dwc:catalogNumber "735" ; > dwc:kingdom "Animalia" ; > dwc:phylum "Arthropoda" ; > dwc:class "Insecta" ; > dwc:order "Hemiptera" ; > dwc:family "Miridae" ; > dwc:scientificName "Phytocoris" ; > dwc:scientificNameAuthorship "Fallén, 1814" ; > dwc:genus "Phytocoris" ; > dwc:identifiedBy "G. W. Cowper 2008" ; > dwc:recordedBy "G. W. Cowper" ; > dwc:eventDate "2008-10-18" ; > dwc:year "2008" ; > dwc:month "10" ; > dwc:day "18" ; > dwc:startDayOfYear "292" ; > dwc:fieldNumber "-" ; > dwc:individualCount "1" ; > dwc:preparations "Academy Drawer" ; > dwc:country "United States" ; > dwc:stateProvince "New Jersey" ; > dwc:county "Burlington" ; > dwc:municipality "Woodland" ; > dwc:locality "SW of Chatsworth Beat Pinus along sandy road in > upland pine & oak woodland.; 1 individual(s) collected; Way Point > [-]" ; dwc:decimalLatitude "39.806067" ; dwc:decimalLongitude > "-74.545333" ; dwc:verbatimCoordinates "N+39º48.364' W-074º32.720'" ; > dwc:disposition "ANSP" ; > dcterms:modified "2015-04-25 17:13:22" ; > dcterms:license <http://creativecommons.org/licenses/by-nc/3.0/> ; > dcterms:rightsHolder <Academy of Natural Sciences> ; > dcterms:accessRights "CC BY-NC (Attribution-Non-Commercial)" ; > dcterms:references > "http://symbiota4.acis.ufl.edu/scan/portal/collections/individual/index.php?…". > > On Wed, 17 Aug 2016 06:02:01 +0000 > Douglas Campbell <Douglas.Campbell(a)tepapa.govt.nz > <mailto:Douglas.Campbell@tepapa.govt.nz>> wrote: > > > Thanks for taking the time to bring me up to speed, Steve. > > > > I'm familiar with the complexities of preparing specifications and > > realise I've come in mid-way. I'll spend some time reading up on the > > containers and occurrences history. But I'm unclear whether it is > > better to use DSW terms in anticipation of them having longevity, or > > just to mint our own in the meantime? > > > > For the taxon convenience fields... > > > > I thought I read in the DwC RDF schema that properties like taxonRank > > were in the Taxon class (so using them in Identification conflicts > > with their definition), but looking again I see that the spec uses > > "dwcattributes:organizedInClass" which specifically does not imply > > domain or range. So now I'm at peace with that. :) > > > > However, I am pointing to our own RDF versions of taxon > > classification terms that we use, and using DwC properties to define > > these taxon terms, plus I am combing these all together in a single > > JSON-LD API result. So at this point I don't think I need to repeat > > the convenience properties in Identification (as they are available > > directly in the Taxon object). While this seems to fit our purpose I > > can see that this may be sub-optimal for others who download the data > > and use it separately - I'll need to contemplate that scenario some > > > more. > > > > Cheers, > > Douglas > > > > > > From: Steve Baskauf [mailto:steve.baskauf@Vanderbilt.Edu > <mailto:steve.baskauf@Vanderbilt.Edu>] > > Sent: Wednesday, 17 August 2016 6:32 a.m. > > To: Douglas Campbell > > Cc: tdwg-content(a)lists.tdwg.org <mailto:tdwg-content@lists.tdwg.org> > > Subject: Re: [tdwg-content] Implementing Darwin Core in RDF > > > > Douglas, > > I was the lead author on the DwC RDF Guide, so I can try to answer > > your questions about it. The TDWG RDF Task Group is still in > > operation, although it hasn't been very active for the past several > > years. The RDG TG has an online "home" at the TDWG Github site.[1] > > However, the content didn't survive the migration from Google Code > > very well, so it takes some effort at this point to sort through it. > > The TG also has an email list [2] but there has been little traffic > > on it recently. > > > > *Dereferencing of the DwC IRI namespace* - Unfortunately, the dwciri: > > namespace terms don't dereference at the present time. This needs to > > be corrected. I've created a Turtle serialization [3] of how I think > > the RDF should be written for the dwciri: terms, but it isn't served > > when one attempts to dereference the terms and hasn't been > > incorporated into the official DwC repository. Part of the problem > > here is that the guidelines for documenting terms in machine-readable > > form are still going through the adoption process.[4] I'm hopeful > > that when the Documentation Specification is ratified, we can make > > sure that all existing DwC terms dereference in a consistent manner. > > > > *Best practice for connecting containers together* - By this, I'm > > assuming you mean linking instances of the various Darwin Core > > classes, or in RDF terms, linking nodes. The RDF Guide is silent on > > how to do this. That's not great from the standpoint of actually > > turning Darwin Core records into RDF, but it was a way to complete > > the guide in a finite amount of time. What is missing is a consensus > > domain model that would lay out how instances of the Darwin Core > > classes would be linked. Such a model should be developed, but that > > has not yet happened. Again, there is a draft standard submitted for > > review [5], which if adopted will specify (in Section 4) a process > > for developing such a model. When we wrote the RDF Guide, we > > provided ancillary documents [6], which included examples that > > followed the RDF Guide and linked instances using various proposed > > models. There are links to web pages containing examples using > > TaxonConcept, BiSciCol, and Darwin-SW object properties to link class > > instances. I am not sure whether there is any RDF "in the wild" for > > the first two examples. I'm more familiar with Darwin-SW, as I was > > involved in its development [7]. There is a Semantic Web Journal > > article about Darwin-SW [8], so I won't go into detail about it here, > > except to say that its data model was developed following an > > extensive discussion on the tdwg-content email list [9] about how > > members of the community understood the Darwin Core classes. The > > relationship between Darwin-SW model and the historical 1993 ACS > > Model can be viewed at [10]. There are a bit over a million triples > > of data "in the wild" modeled on Darwin-SW in accordance with the DwC > > RDF guide, accessible at a SPARQL end point. [11] Some examples > > showing how to play around with SPARQL queries of these data are at > > [12]. > > > > *The overlapping scope of Occurrence and Specimen types* - There is a > > long history behind the meaning of "Occurrence". There is an > > out-of-date-summary of some of the discussion around this topic in > > the Darwin-SW documentation [13]. I think that at the time when > > Darwin Core was originally adopted, an Occurrence was considered a > > sort of superclass of the Specimen and Observation classes. However, > > after a lot of discussion, the meaning of dwc:Occurrence was > > clarified by changing it to its current definition: "An existence of > > an Organism (sensu http://rs.tdwg.org/dwc/terms/Organism) at a > > particular place at a particular time." In this view, an Occurrence > > isn't a concrete thing like a Specimen - it's more like a database > > join between an Event instance (time and place) and an Organism, > > which allows for a one-to-many relationship between a Organism and > > Occurrences, and a one-to-many relationships between an Event and > > Occurrences. It also allows for a single occurrence of an organism > > at a time and place to be documented by one-to-many forms of > > evidence, which could include PreservedSpecimens, HumanObservation > > data, or images of various sorts. In RDF terms, an Occurrence could > > be thought of as a node that is linked to Event, Organism, and > > evidence instances nodes. You can see this represented graphically > > at [7], where "dsw:Token" refers to a generic class for evidence. In > > any case, separating Occurrence (as a node linking Events to > > Organisms) from Specimen allows an Occurrence to be documented by one > > to many instances of any kind of evidence, or even multiple kinds of > > evidence. For example, an Occurrence could be documented by a > > PhysicalSpecimen as well as several images. Here is an example of an > > organism with two Occurrences: > > http://bioimages.vanderbilt.edu/org-jorgem/rec13_0004 The first > > occurrence on 2013-07-24 was documented by 42 camera trap images, and > > the second occurrence on 2013-07-25 was documented by 21 camera trap > > images. You can see how this was represented in RDF at [14]. In > > most cases, specimen records will be much simpler than this, with one > > organism, documented at one occurrence, with evidence of one > > PreservedSpecimen. Such a simpler case could be represented with a > > simpler model. But the more complex model allows specimen-derived > > occurrence records to be merged with other kinds of occurrence > > records, such as the camera trap example I gave, mark-recapture bird > > banding observations, iNaturalist occurrences documented by photos of > > the organism, etc. > > > > *Conflicting usage of Taxon fields in the Identification object* - In > > order to explain the rationale behind why what seem to be > > taxon-related properties are assigned to Identification instances, I > > must refer to the idea of "convenience terms" as expressed in Section > > 2.7 of the RDF Guide.[15] In a perfect world, we would have the > > following: > > > > a collection item linked by dwciri:inCollection to an IRI-identified > > collection an identification instance linked by dwciri:toTaxon to an > > IRI-identified taxon (a.k.a. taxon concept) a location instance > > linked by dwciri:inDescribedPlace to an IRI-identified geographic > > place (a.k.a. "feature") > > > > If the linked IRI-identified object resources were described by RDF, > > it would not be necessary to include any of the Darwin Core > > "convenience" properties included in Table 3.5 [16]. The information > > contained in the values of those properties could be discovered by > > dereferencing the object IRIs and traversing subsequent links from > > that RDF. However, if those IRIs don't exist, then the convenience > > properties provide a string-based mechanism to relate the subject > > resource to other resources that should be linked to the same > > (unidentified) object resource. So for example, if we say a specimen > > has the convenience properties and values > > > > dwc:collectionCode="Mamm" > > dwc:institutionCode ="MVZ" > > > > we are not saying that "Mamm" is the collection code of the specimen > > and that "MVZ" is the institution code of the specimen. Rather, we > > mean that the specimen should be linked to a collection (with unknown > > IRI) whose code is MVZ and whose owning institution has the code > > "MVZ". Similarly, if we say that an identification has the > > convenience properties and values > > > > dwc:genus="Hersiliiadae" > > dwc:specificEpithet="yaeyamaensis" > > > > we are not saying that "yaeyamaensis" is the specific epithet of the > > identification and that "Hersiliiadae" is the genus of the > > identification. Rather, we mean that the identification should be > > linked to a taxon (with unknown IRI) for which the specificEpithet > > part of its name string is "yaeyamaensis", which is included in the > > genus "Hersiliiadae". This may seem odd, particularly if you are > > used to thinking of genus and specific epithet as properties of a > > taxon. But the sets of DwC convenience properties are intended to be > > a temporary, string-based way to describe an unidentified resource to > > which the subject resource should be linked. At some future time, if > > IRIs can be discovered, those sets of convenience properties might be > > dropped if dereferencing the IRIs provides the same information. In > > these examples, one might replace with: > > > > a collection item linked by dwciri:inCollection to > > http://grbio.org/cool/0rht-pj95 an identification instance linked to > > http://zoobank.org/75C9EA16-72B1-44C9-AD40-3C3D41323AB9 > > > > although I don't think either of these IRIs currently dereference to > > meaningful machine-readable RDF (although they have human-readable > > web pages). > > > > I hope that this has provided you with some answers, or at least a > > starting point for additional exploration or questions. Please feel > > free to reply if there were parts of what I wrote that weren't clear. > > > > Steve Baskauf > > > > [1] https://github.com/tdwg/rdf > > [2] http://groups.google.com/group/tdwg-rdf > > [3] > > > https://github.com/tdwg/vocab/blob/master/code-examples/darwin-core/dwciri.… > > [4] > > https://github.com/tdwg/vocab/blob/master/documentation-specification.md > > [5] > > https://github.com/tdwg/vocab/blob/master/maintenance-specification.md > > [6] https://github.com/tdwg/rdf/blob/master/DwCAncillary.md [7] > > https://github.com/darwin-sw/dsw [8] > > > http://www.semantic-web-journal.net/content/darwin-sw-darwin-core-based-ter… > > [9] https://github.com/darwin-sw/dsw/wiki/TdwgContentEmailSummary > > [10] > > https://github.com/darwin-sw/dsw/blob/master/img/acs-dsw-poster.pptx > > [11] http://rdf.library.vanderbilt.edu/sparql?view [12] > > > https://github.com/HeardLibrary/semantic-web/blob/master/learning-sparql/le… > > [13] https://github.com/darwin-sw/dsw/wiki/ClassOccurrence [14] > > http://bioimages.vanderbilt.edu/org-jorgem/rec13_0004.rdf [15] > > > http://rs.tdwg.org/dwc/terms/guides/rdf/index.htm#2.7_Darwin_Core_convenien… > > [16] > > > http://rs.tdwg.org/dwc/terms/guides/rdf/index.htm#3.5_Darwin_Core_convenien… > > > > > > > > Douglas Campbell wrote: > > Hi all, > > > > I am implementing Darwin Core in RDF as part of our API at Te Papa > > (Museum of New Zealand). My aim is to map our specimen metadata to > > rich Darwin Core RDF using JSON-LD, then 'dumb down' to Simple Darwin > > Core to contribute to virtual herbariums. I have mocked-up some > > records, however there are some areas where I'm not quite sure how to > > interpret the Darwin Core RDF Guide. > > > > The areas of confusion I have include: > > * Best practice for connecting containers together > > * Dereferencing of the DwC IRI namespace > > * The overlapping scope of the Occurrence and Specimen types > > * Conflicting usage of Taxon fields in the Identification object. > > > > I'm hoping for suggestions: > > 1. Are there any implementations of DwC RDF data online that I could > > look at as examples to follow? 2. What/to whom is the best way to ask > > specific questions about DwC RDF? > > > > At this stage our API prototype is only available internally but > > there is some documentation available publicly at: > > https://github.com/te-papa/collections-api/wiki > > > > Thanks in advance, > > Douglas > > > > Douglas Campbell > > Business Analyst > > Collections Information Services > > Museum of New Zealand Te Papa Tongarewa > > > > ________________________________ > > > > Visit the Te Papa website http://www.tepapa.govt.nz > > The email message together with the accompanying attachments may be > > CONFIDENTIAL. If you have received this message in error, please > > notify https://www.tepapa.govt.nz/about/contact-us/general-enquiries > > immediately and delete the original message. The views expressed in > > this message are those of the individual sender, except where the > > sender specifically states them to be views of Te Papa. Te Papa > > employs strict virus checking measures and accepts no liability for > > any loss caused either directly or indirectly by a virus arising from > > the use of this message or any attached file. > > > > ________________________________ > > This email has been filtered by SMX. For more information visit > > > smxemail.com <http://smxemail.com><http://smxemail.com/> > > > > > > > > -- > > > > Steven J. Baskauf, Ph.D., Senior Lecturer > > > > Vanderbilt University Dept. of Biological Sciences > > > > > > > > postal mail address: > > > > PMB 351634 > > > > Nashville, TN 37235-1634, U.S.A. > > > > > > > > delivery address: > > > > 2125 Stevenson Center > > > > 1161 21st Ave., S. > > > > Nashville, TN 37235 > > > > > > > > office: 2128 Stevenson Center > > > > phone: (615) 343-4582 <tel:%28615%29%20343-4582>, fax: (615) > 322-4942 <tel:%28615%29%20322-4942> > > > > If you fax, please phone or email so that I will know to look for it. > > > > http://bioimages.vanderbilt.edu > > > > http://vanderbilt.edu/trees > > > > > > > > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > Visit the Te Papa website http://www.tepapa.govt.nz > > The email message together with the accompanying attachments may be > > CONFIDENTIAL. If you have received this message in error, please > > notify https://www.tepapa.govt.nz/about/contact-us/general-enquiries > > immediately and delete the original message. The views expressed in > > this message are those of the individual sender, except where the > > sender specifically states them to be views of Te Papa. Te Papa > > employs strict virus checking measures and accepts no liability for > > any loss caused either directly or indirectly by a virus arising from > > the use of this message or any attached file. > > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > > > ______________________________________________________________________________ > > > > This email has been filtered by SMX. > > For more information visit http://smxemail.com > > > ______________________________________________________________________________ > > > > > -- > Paul J. Morris > Biodiversity Informatics Manager > Museum of Comparative Zoölogy, Harvard University > mole(a)morris.net <mailto:mole@morris.net> AA3SD PGP public key available > > _______________________________________________ > tdwg-content mailing list > tdwg-content(a)lists.tdwg.org <mailto:tdwg-content@lists.tdwg.org> > http://lists.tdwg.org/mailman/listinfo/tdwg-content > > > > > > -- > > John Deck > (541) 914-4739 > > ------------------------------------------------------------------------ > > Visit the Te Papa website http://www.tepapa.govt.nz > The email message together with the accompanying attachments may be > *CONFIDENTIAL*. If you have received this message in error, please > notify https://www.tepapa.govt.nz/about/contact-us/general-enquiries > immediately and delete the original message. The views expressed in > this message are those of the individual sender, except where the > sender specifically states them to be views of Te Papa. Te Papa > employs strict virus checking measures and accepts no liability for > any loss caused either directly or indirectly by a virus arising from > the use of this message or any attached file. > > ------------------------------------------------------------------------ > This email has been filtered by SMX. For more information visit > smxemail.com <http://smxemail.com/> -- Steven J. Baskauf, Ph.D., Senior Lecturer Vanderbilt University Dept. of Biological Sciences postal mail address: PMB 351634 Nashville, TN 37235-1634, U.S.A. delivery address: 2125 Stevenson Center 1161 21st Ave., S. Nashville, TN 37235 office: 2128 Stevenson Center phone: (615) 343-4582, fax: (615) 322-4942 If you fax, please phone or email so that I will know to look for it. http://bioimages.vanderbilt.edu http://vanderbilt.edu/trees -- Steven J. Baskauf, Ph.D., Senior Lecturer Vanderbilt University Dept. of Biological Sciences postal mail address: PMB 351634 Nashville, TN 37235-1634, U.S.A. delivery address: 2125 Stevenson Center 1161 21st Ave., S. Nashville, TN 37235 office: 2128 Stevenson Center phone: (615) 343-4582, fax: (615) 322-4942 If you fax, please phone or email so that I will know to look for it. http://bioimages.vanderbilt.edu http://vanderbilt.edu/trees

1 0

Implementing Darwin Core in RDF
by Douglas Campbell 27 Aug '16

27 Aug '16

Hi all, I am implementing Darwin Core in RDF as part of our API at Te Papa (Museum of New Zealand). My aim is to map our specimen metadata to rich Darwin Core RDF using JSON-LD, then 'dumb down' to Simple Darwin Core to contribute to virtual herbariums. I have mocked-up some records, however there are some areas where I'm not quite sure how to interpret the Darwin Core RDF Guide. The areas of confusion I have include: * Best practice for connecting containers together * Dereferencing of the DwC IRI namespace * The overlapping scope of the Occurrence and Specimen types * Conflicting usage of Taxon fields in the Identification object. I'm hoping for suggestions: 1. Are there any implementations of DwC RDF data online that I could look at as examples to follow? 2. What/to whom is the best way to ask specific questions about DwC RDF? At this stage our API prototype is only available internally but there is some documentation available publicly at: https://github.com/te-papa/collections-api/wiki Thanks in advance, Douglas Douglas Campbell Business Analyst Collections Information Services Museum of New Zealand Te Papa Tongarewa +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Visit the Te Papa website http://www.tepapa.govt.nz The email message together with the accompanying attachments may be CONFIDENTIAL. If you have received this message in error, please notify https://www.tepapa.govt.nz/about/contact-us/general-enquiries immediately and delete the original message. The views expressed in this message are those of the individual sender, except where the sender specifically states them to be views of Te Papa. Te Papa employs strict virus checking measures and accepts no liability for any loss caused either directly or indirectly by a virus arising from the use of this message or any attached file. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ______________________________________________________________________________ This email has been filtered by SMX. For more information visit http://smxemail.com ______________________________________________________________________________

5 9

A proposal to improve Darwin Core for invasive species data
by Quentin Groom 25 Jun '16

25 Jun '16

I've been working on a proposal to improve Darwin Core for use with invasive species data. The proposal is detailed on GitHub at https://github.com/qgroom/ias-dwc-proposal/blob/master/proposal.md. The proposal is for a new term "origin" and suggested vocabularies for establishmentMeans and occurrenceStatus. I'd welcome your feedback on the proposal. >From my perspective it provides some needed clarity on the establishmentMeans and occurrenceStatus fields, but also adds the origin that is needed for invasive species research and for conservation assessments. I'm not sure of the best way to discuss this, but if you have concrete proposals for changes you might raise them as issues on GitHub, as well as mentioning them here. Regards Quentin Dr. Quentin Groom (Botany and Information Technology) Botanic Garden Meise Domein van Bouchout B-1860 Meise Belgium ORCID: 0000-0002-0596-5376 <http://orcid.org/0000-0002-0596-5376> Landline; +32 (0) 226 009 20 ext. 364 FAX: +32 (0) 226 009 45 E-mail: quentin.groom(a)plantentuinmeise.be Skype name: qgroom Website: www.botanicgarden.be

13 33

Additional terms for sample event data in DwC
by Kyle Braak 17 Jun '16

17 Jun '16

Hi all, In compliance with the directions for requesting changes to the Darwin Core (DwC) vocabulary, I hereby submit to the TDWG Content list a proposal for four new terms to more faithfully express sample event data. The need for these four new terms is based on several inputs: EU Nodes workshop on sample event data<http://www.gbif.pt/EuropeanNodesMeeting/workshop>, April 2016<http://www.gbif.pt/EuropeanNodesMeeting/workshop>[1]; discussions on the Sample event data publishing interest group<http://community.gbif.org/pg/groups/47949/sample-event-data-publishing-inte…>[2]; experiences publishing the first round of sample event datasets<http://www.gbif.org/dataset/search?q=&type=SAMPLING_EVENT>[3]. While DwC already provides many terms that enable describing sample event data, these four new terms will allow a larger number of underlying protocols to be encoded in a standardised way. Notably the term samplingTaxaRange will also allow for accurate presence/absence data to be recorded. These four terms are: layer https://github.com/tdwg/dwc/issues/125 #Justification Required for describing the different layers within a location. Especially useful for describing the location of sampling when the sampling protocol uses stratification. For example, vegetation surveys (relevés) commonly stratify a plot into vegetation layers and describe each plant species' abundance within each layer. #Definition The layer within a Location. Recommended best practice is to use a controlled vocabulary such as the GBIF vegetation layer vocabulary<http://rs.gbif.org/vocabulary/gbif/vegetation_layer.xml>[4]. The elevation or depth of the layer should be well defined in the vocabulary. Otherwise describe the range of elevation using minimumElevationInMeters and maximumElevationInMeters or the range of depth using minimumDepthInMeters and maximumDepthInMeters. #Comment Examples: "tree", "shrub". #Term group Location siteID https://github.com/tdwg/dwc/issues/126 #Justification Required for identifying a specific sampling site at or within a location. This allows distinction from dwc:locationID, which is an identifier for the sampling location itself. Especially useful for describing permanent sampling sites that haven't been georeferenced. This also enables sampling sites to be referenced across datasets. #Definition An identifier for the sampling site at or within the Location. #Comment May be a global unique identifier or an identifier specific to the dataset. Example: "tr011-s1" identifies a sampling site within a location (locationID= "tr011"). #Term group Location samplingTaxaRange https://github.com/tdwg/dwc/issues/127 #Justification Required for describing the range of taxa that could be observed at the time and place of sampling given a) the sampling protocol or b) the taxonomic coverage of the study and the expertise of the personnel carrying out the identification. This would allow for accurate presence/absence data to be recorded. #Definition A short list (concatenated and separated) of taxa names or the URI of a timestamped checklist describing the range of taxa being sampled during a sampling event. For taxonomic and biogeographical/ecological reasons, however, this checklist should exist solely within the context of the sample event dataset. #Comment The recommended best practice varies depending on whether the list of taxa is short or long. For a short list, the recommended best practice is to separate the values with a vertical bar (' | '). Examples: "Lepidoptera | Coleoptera", "Lepidurus arcticus (Pallas, 1793)". For a long list, the recommended best practice is to use the URI of a timestamped checklist. Example: "http://danbif.au.dk/ipt/resource?r=checklist-bees-denmark" - checklist for the taxa of bees occurring in Denmark. #Term group Event siteTreatment https://github.com/tdwg/dwc/issues/128 #Justification Required for describing the treatments that were intentionally applied to a sampling site before sampling occurred. Especially useful for describing sample events where the underlying protocol tests a control-group versus a treatment-group. For example, an investigation looking at the effects of grazing on vegetation will have a control plot and a plot that has been permanently grazed. Note this is different from dwc:preparations, which only applies to a specimen. #Definition A list (concatenated and separated) of treatments for a sampling site. #Comment The recommended best practice is to separate the values with a vertical bar (' | '). Examples: "permanently grazed", "Imazapyr | Triclopyr" - two herbicides that have been applied. #Term group Event None of the existing DwC terms is sufficient for any of the proposed terms although two are somewhat related: locationID ("An identifier for the set of location information") and preparations ("A list of preparations and preservation methods for a specimen."). Neither are adequate - locationID is an identifier for the sampling location itself but not specific sampling sites within the location and preparations refers exclusively to specimens but not a sampling site. Thank you for your consideration of my proposal, Kyle Braak GBIF Secretariat [1] http://www.gbif.pt/EuropeanNodesMeeting/workshop [2] http://community.gbif.org/pg/groups/47949/sample-event-data-publishing-inte… [3] http://www.gbif.org/dataset/search?q=&type=SAMPLING_EVENT [4] http://rs.gbif.org/vocabulary/gbif/vegetation_layer.xml

1 0

TDWG DwC Text schema references git head
by godfoder 15 Jun '16

15 Jun '16

Recently, iDigBio has seen some errors popping up in our logs related to fetching XML definitions from https. In tracing this problem we found that the current published text XSD: http://rs.tdwg.org/dwc/text/tdwg_dwc_text.xsd References the darwin core terms with the URL: https://raw.githubusercontent.com/tdwg/dwc/master/xsd/tdwg_dwcterms.xsd For those of you not familiar with how git and github work, the URL being used is an unversioned URL pulling right from HEAD off of github (rather than a version tag or branch). This means that any committed change to the file on github will immediately change the behavior of schema validation in client programs, potentially invalidating a previously valid XML file (or simply breaking things if the commit contains errors). This seems to be related to a (potential) issue with the new DwC release process. I get that we're now moving towards more of a "living standard" model with small incremental update. I think we still need some form of release process. Rather than having defintions pulled right from github master, we could create a "latest" tag in github that everything references (in addition to tags for individual releases probably): https://raw.githubusercontent.com/tdwg/dwc/latest/xsd/tdwg_dwcterms.xsd Then, commits could be made to the DwC repo representing the ongoing work of improving the standard, and then when everyone is happy with the changes, the tag could be moved to indicate that the changes are now "published". If we want to leave the URL as is, we should document the commit procees in the contributor documentation. There is a well known pattern that exclusively uses branches that is often called git flow: http://nvie.com/posts/a-successful-git-branching-model/ We could also move to a "no commits to this repo" model, where all changes must come in as pull requests from forks of the main repo. - Alex

3 2

Re: [tdwg-content] A proposal to improve Darwin Core for invasive species data (Quentin Groom)
by Ramona Walls 11 Jun '16

11 Jun '16

Quentin and all: I finally had a chance to read through this long list of emails. It's great to see the discussions inspired by Quentin's proposal. To bring this particular thread back into focus, Quentin, I think it would be helpful if you could summarize the comments and suggestions that pertain specifically to the proposed term changes, perhaps in the github doc if you think that is appropriate. I would like to see some concrete next steps for moving forward. I too am encouraged by Donald's remarks, as they capture much of what inspired work on the BCO and are consistent with the directions that I think TDWG needs to move to keep pace with biodiversity and data science. As important as those high level changes are, I want to make sure we we don't loose track of the much needed work on origin, occurrenceStatus and establishmentMeans. Ramona ------------------------------------------------------ Ramona L. Walls, Ph.D. Senior Scientific Analyst, CyVerse, University of Arizona Research Associate, Bio5 Institute, University of Arizona On Sun, May 29, 2016 at 3:00 AM, <tdwg-content-request(a)lists.tdwg.org> wrote: > Send tdwg-content mailing list submissions to > tdwg-content(a)lists.tdwg.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.tdwg.org/mailman/listinfo/tdwg-content > or, via email, send a message with subject or body 'help' to > tdwg-content-request(a)lists.tdwg.org > > You can reach the person managing the list at > tdwg-content-owner(a)lists.tdwg.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tdwg-content digest..." > > >

2 1

Term change: footprintSRS
by Kyle Braak 02 Jun '16

02 Jun '16

Hi all, I'd like to propose a change to the term footprintSRS<http://rs.tdwg.org/dwc/terms/#footprintSRS>[1] that would allow it to also be provided using the EPSG code as a controlled vocabulary (e.g. "EPSG:4326"). I welcome your feedback in the following GitHub issue<https://github.com/tdwg/dwc/issues/122>[2] where you can find more information about my proposed change. Thanks, Kyle GBIF Secretariat [1] http://rs.tdwg.org/dwc/terms/#footprintSRS [2] https://github.com/tdwg/dwc/issues/122

1 0

Fwd: Fw: PLOS Early Career Travel Award Program is Back!
by Cynthia Parr 04 May '16

04 May '16

This might be of interest for travel to TDWG. ------------------------------ *From:* PLOS <feedback(a)e.plos.org> *Sent:* Tuesday, May 3, 2016 3:39 PM *To:* Parr, Cynthia - ARS *Subject:* PLOS Early Career Travel Award Program is Back! PLOS is once again pleased to announce its Early Career Travel Award Program View this email in your browser <http://view.e.plos.org/?qs=8c6b5ea0b6a1243c24d38be2836dffd3aabeed1a44faba52…> [image: PLOS] <http://click.e.plos.org/?qs=bd46dfd56cae90fe3e0e5a254fe3bd67f6d9319c5923821…> PUBLISH WITH PLOS <http://click.e.plos.org/?qs=bd46dfd56cae90fe167ed6b3ad9d3c676454d10151fae94…> ------------------------------ PLOS Early Career Travel Award Program is Back! Presenting research findings and participating in the scientific dialogue are important experiences in the career development of researchers. To support their growth as effective communicators, PLOS is once again pleased to announce its Early Career Travel Award Program. New this year are multiple award cycles. ARE YOU ELIGIBLE? If you are... • Presenting at a conference taking place between July 1, 2016 – March 31, 2017 • An author on an article published in any PLOS journal by the application date, AND • Currently part of a graduate program or have received a graduate degree within the last five years as of the application deadline ...apply to be considered for the PLOS Early Career Travel Award Program. APPLICATION DEADLINE: MAY 31, 2016 More information is available at plos.org/ecr-travel-awards <http://click.e.plos.org/?qs=bd46dfd56cae90fefd197046c785890f20d72902a8467b6…>. Watch this space for announcements on future Award cycles. *Share with us the subject area(s) that most interest you* Biology and life sciences <http://click.e.plos.org/?qs=bd46dfd56cae90fe10cfd43c519be40123d5c75d91f7891…> Ecology and Earth sciences <http://click.e.plos.org/?qs=bd46dfd56cae90fe212e96c0e3601ff6a94b208425b1529…> Medicine and health sciences <http://click.e.plos.org/?qs=bd46dfd56cae90feb28a0ce588aabb651e2d4c4560ce55b…> Physical sciences <http://click.e.plos.org/?qs=bd46dfd56cae90fe8df12b07dd38f747af4a6919c5d1df5…> Research methods and science policy <http://click.e.plos.org/?qs=bd46dfd56cae90fe52a6b02494e7bd3790b4ed11dbc7f65…> Social sciences <http://click.e.plos.org/?qs=bd46dfd56cae90fe1310872581c0ecda75e90b073be0748…> Other <http://click.e.plos.org/?qs=bd46dfd56cae90fe286759123c749cc45833a6ae8396122…> APPLY NOW <http://click.e.plos.org/?qs=bd46dfd56cae90feac2a40114c7f1eb4c45be0196d0407b…> Public Library of Science 1160 Battery St. Suite 100 San Francisco, CA 94111-1233 US [image: Facebook] <http://click.e.plos.org/?qs=bd46dfd56cae90fe7b5b8ca644c7bd09eeecd7fc40375ad…> Facebook <http://click.e.plos.org/?qs=bd46dfd56cae90fe7b5b8ca644c7bd09eeecd7fc40375ad…> [image: Twitter] <http://click.e.plos.org/?qs=bd46dfd56cae90fe7bb2335b31e04ae0b2dc7307e8c195a…> Twitter <http://click.e.plos.org/?qs=bd46dfd56cae90fe7bb2335b31e04ae0b2dc7307e8c195a…> [image: Website] <http://click.e.plos.org/?qs=bd46dfd56cae90fe01746768f2d37ed1599080d1f23d7b8…> Website <http://click.e.plos.org/?qs=bd46dfd56cae90fe01746768f2d37ed1599080d1f23d7b8…> [image: Email] <feedback(a)plos.org> Email <feedback(a)plos.org> You are receiving this email because you opted to receive PLOS updates and information. Privacy Policy <http://click.e.plos.org/?qs=bd46dfd56cae90fec102242e10488524a4c459098a8c927…> | Unsubscribe <http://click.e.plos.org/unsub_center.aspx?qs=2cc4d08de3cfd95849cfb456239cba…> | Update Preferences <http://click.e.plos.org/profile_center.aspx?qs=2cc4d08de3cfd958def7b9a29790…> | Sign Up <http://click.e.plos.org/?qs=bd46dfd56cae90fede0030842b8328c6639d37f5e491e92…> This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.

1 0

Re: [tdwg-content] Taxonomic name usage files
by Richard Pyle 20 Apr '16

20 Apr '16

Thanks, Terry; and agreed! I’ll claim full-credit for the over-verbosity. But when it comes to taxon names, and how to structure the information appropriately, I’ve tried every strategy for communicating from super-thin to super-verbose (the recent thread epitomizing the latter); and on balance, none of them are effective because there is SO MUCH noise out there in terminology, and concepts of concepts, and such. It’s a perpetual uphill battle. My hope is that, in this case, the information was decipherable to primary audience (Nico). Now… on the topic of uphill battles… we had some great conversations in Florence and Jönköping on how to improve TaxPub to capture the core elements of TNUs (both Protonyms and subsequent usages); but I’m not sure we ever got anywhere. However, given the recent (excellent) progress with the PLAZI workflow, and some other things that are happening later this year in GNUB-space; perhaps it’s time to revisit those conversations, in the context of Nico’s original question, and hammer-out a functional solution (or, if not a “solution”, at least a quantum step forward). Aloha, Rich From: Terry Catapano [mailto:catapanoth@gmail.com] Sent: Wednesday, April 20, 2016 1:30 AM To: Donat Agosti Cc: tdwg-content(a)lists.tdwg.org; vocab(a)noreply.github.com; Michael Rosenberg (Faculty); Chuck Miller (Chuck.Miller(a)mobot.org); Robert Guralnick; Nico Franz; deepreef(a)bishopmuseum.org Subject: Re: [tdwg-content] Taxonomic name usage files Donat, Where did Chuck ask about TaxonX? I'd like to see what the specific question is. In general, it's more effective to clearly and briefly describe *what* we do and *why* and to not discuss what we *dont* currently do, or plan on doing. There is danger to credibility in sustained over-promising. As is evidenced by the verbosity of this thread, there is an even greater danger to communication in over-writing. On Wed, Apr 20, 2016 at 6:13 AM, Donat Agosti <agosti(a)amnh.org> wrote: I am trying to answer two questions in this tread. Taxonx. Chuck asked about TaxonX. We are moving away from TaxonX to use an archival version of TaxPuB, TaxPub-green ( <https://github.com/plazi/TaxPubJATS-green> https://github.com/plazi/TaxPubJATS-green ), which is related to TaxPub that Pensoft already uses for the publishing, and which is based on NLM JATS, that is a widely used “standard” albeit in different flavors. But to have all based on JATS-TaxPub makes it easier to make use of legacy (articles converted into TaxPub) and prospective (born digital based on TaxPub) articles. Once we have this move finished we will release and note and explain in detail. But in brief, let’s focus on TaxPub. Taxonomic names For our work with taxonomic publications we tag all scientific taxonomic names we discover in the articles. Our main focus are names for which a taxonomic treatment is provided in the respective article, or which are cited as a reference to an earlier usage and with that a taxonomic treatment. As an example: <http://treatment.plazi.org/id/87F5BDFA-6C63-C7B7-4A85-A1B39AE6CACE> http://treatment.plazi.org/id/87F5BDFA-6C63-C7B7-4A85-A1B39AE6CACE Agosti (1990) provides a treatment of Catagylphis turcomanicus (Emery). He cites all the earlier usages of this name, beginning from the protonym to all the latter changes in combination. With that he says, that under this understanding of this taxon, he subsumes all the earlier name usages. He does this by citing them. A visualization is provided on the right hand und “taxonomy” A more recent example is this crab: <http://treatment.plazi.org/id/F017F605-AC1E-BB43-FF2A-90F9555CF9CD> http://treatment.plazi.org/id/F017F605-AC1E-BB43-FF2A-90F9555CF9CD This treatmentCitation allows us to build a citation graph which is specific in a sense that this type of taxonomic names have a relationship to an earlier specified usage. Whilst names that are found in the next have this relationship implicit, known probably to the author in most cases, and few exceptional cases to a community that maintains a name server including the currently accepted name (and then there the history that eventually leads to the protonym, such as is the case for ants (and mony more hymenoptera) on the Hymenopter Name Server). But this is a discussion in itself. In Taxpub this is dealt with (somewhat cryptic) <nomenclature-citation-list> <nomenclature-citation> </nomenclature-citation> <nomenclature-citation> </nomenclature-citation> </nomenclature-citation-list> See <https://htmlpreview.github.io/?https://raw.githubusercontent.com/tcatapano/…> https://htmlpreview.github.io/?https://raw.githubusercontent.com/tcatapano/… In RDF we make use of CITO ( <http://purl.org/spar/cito/> http://purl.org/spar/cito/) to model this relationship <https://github.com/plazi/TreatmentOntologies> https://github.com/plazi/TreatmentOntologies and here an example <http://tb.plazi.org/GgServer/rdf/87F5BDFA6C63C7B74A85A1B39AE6CACE> http://tb.plazi.org/GgServer/rdf/87F5BDFA6C63C7B74A85A1B39AE6CACE Donat From: tdwg-content [mailto: <mailto:tdwg-content-bounces@lists.tdwg.org> tdwg-content-bounces(a)lists.tdwg.org] On Behalf Of Richard Pyle Sent: Wednesday, April 20, 2016 12:30 AM To: 'Nico Franz' < <mailto:nico.franz@asu.edu> nico.franz(a)asu.edu> Cc: <mailto:tdwg-content@lists.tdwg.org> tdwg-content(a)lists.tdwg.org; <mailto:vocab@noreply.github.com> vocab(a)noreply.github.com; 'Michael Rosenberg (Faculty)' < <mailto:msr@asu.edu> msr(a)asu.edu> Subject: Re: [tdwg-content] Taxonomic name usage files Good questions! Note that the stuff I was describing isn’t just GNUB; it’s embedded in the DwC terms as well. And the few elements that are missing from DwC are embedded in TCS. The main other aspects are the Reference metadata (the ill-fated TDWG Reference standard; now looking towards NLMS), and Agents (most people I know follow FOAF). Other than those, the main missing holes (in both GNUB and DwC) are the Appearance stuff, and perhaps a more robust approach to the relationshipAssertion stuff. Maybe a task for TCS 2.0? Once the standards fleshed out, I imagine the way to implement this stuff in new literature is via something along the lines of Pensoft’s PWT (now arpha): <http://arpha.pensoft.net/> http://arpha.pensoft.net/ The natural group to focus on this would be PLAZI, which has been going gangbusters in recent months on capturing structured treatments from existing literature. [Pssst… Donat…. That’s your cue….] Rich From: Nico Franz [ <mailto:nico.franz@asu.edu> mailto:nico.franz@asu.edu] Sent: Tuesday, April 19, 2016 11:58 AM To: Richard Pyle Cc: Gaurav Vaidya; greg whitbread; <mailto:tdwg-content@lists.tdwg.org> tdwg-content(a)lists.tdwg.org; <mailto:vocab@noreply.github.com> vocab(a)noreply.github.com; Michael Rosenberg (Faculty) Subject: Re: [tdwg-content] Taxonomic name usage files Thanks, Rich, for catching me up. So then if we can apparently cover a good bit of ground (with what I assume you'd call a "smart [or the only] way of implementing GNUB"), this does raise the question of how to bring this as close as possible to the peer-review/publication process where an author team may be motivated to express their intentions related to name usages in various explicit, structurally recorded ways. Best, Nico On Tue, Apr 19, 2016 at 2:09 PM, Richard Pyle <deepreef(a)bishopmuseum.org> wrote: > 1. Given a multitude of well established and precise historical name usages, I explicitly don't want to commit to one in particular > that my present usage is congruent with, or not. (Indeed, I kind of think this is what the name withOUT a sec. does, "explicitly"). Yes! Exactly! > I choose to be vague - any past usage is ok with me, here. During the TCS days, this is what we referred to as a "Nomenclatural Concept", which is roughly the sum/average of all historical treatments, more or less (ambiguity and vagueness deliberate/intentional). > I think we can presently model the vagueness (by integrating on the strings alone), but not the deliberateness thereof (in contrast to other situations where vagueness is not intended)? Yes - a TNU without any relationshipAssertions. Basically, the only implied associations with other TNUs is via the Protonym link (i.e., a Nomenclatural Assertion). > 2. Franz. 2010. Revision of Apotomoderes (Insecta: Coleoptera). => Actually, "Insecta" here is more of a social concession to an outdated data filing paradigm than > a claim to an active speaker role (related to name usages that I actually care about). I am not intending to apply my taxonomic expertise to "Insecta"; > that is *out of scope* (though the string is being written). So... in that case, the question is whether to represent "Insecta" as used in Franz 2010 as a scientific name, or vernacular name (two different ways of modelling names, as the latter do not have structured Codes). Even if you fall on the side of using it as a scientific (taxon) name, you can still create a TNU for it. In the spirit of Walter's pioneering work on this stuff, TNUs only represent "potential" taxa. Aloha, Rich

1 0

Taxonomic name usage files
by Nico Franz 20 Apr '16

20 Apr '16

Hi TDWG Content group: Perhaps someone can answer these question? Suppose I submitted a new biodiversity study to a journal for peer review and ultimately publication. My study mentions taxonomic names, but some names are used in more than one specific sense throughout the manuscript. As part of my study's data body, I want to say things like: at this point or these sections in my manuscript, I am using the name in the sense of authors X. And: later on in the Discussion, I am using the name in "my new sense" (as an example). I want to submit a table with structured metadata on the various usages of names in my manuscript, as part of the supplementary data provided to the Journal. I believe part of what the table would have to reflect, for each usage, is whether this is my usage, or that of someone else that I am ok with (=> define speaker role). Is there a best TDWG standard to glean terms and definitions from to draft up that table? I assume it is Darwin Core and/or the TCS, but then has someone actually tried this (= extract the subset of terms needed to identify names, usages, speaker roles) in conjunction with (e.g.) a biodiversity inventory or taxonomic revision to be published? The key purpose here would be to facilitate better name usage data practices, tied to the process of publishing new data via journals. To make data about name usages part of the supplementary data, in a structured and rather explicit format. Thanks and best, Nico

4 9