- tdwg-content - lists.tdwg.org

Re: [tdwg-content] "Wrong" RDF, was Re: What I learned at the TechnoBioBlitz
by Richard Pyle 17 Oct '10

17 Oct '10

Hi Steve, First of all, thank you for taking the time to carefully articulate your perspective on this. As someone who has written more than a few "epic" posts to these lists, I am personally grateful for the careful explanation. I know many people don't have time to read long messages, but I think that the lack of explicit descriptions of things has led to confusion, which, in the long run, has cost us all even more time. For much of your emails, I found myself nodding in agreement. I'm only commenting below on a few passages that caught my attention. I don't know how much your later posts supercede this one, but here are my comments to your first. >From your first post of Oct 15: > In the case of putting "dots on a map" to show the distribution of a > species, the case is simple if the occurrences are specimens where the > whole dead organism is collected. It is not so simple with other > types of occurrences. Let me illustrate with an example. There is > currently precisely one known individual of Crataegus harbisonii in > nature. I have given this individual the URI > http://bioimages.vanderbilt.edu/ind-baskauf/70905 . I have > approximately 62 images of that individual at > http://bioimages.vanderbilt.edu/ind-baskauf/70905.htm and > http://www.cas.vanderbilt.edu/bioimages/species/crha2.htm . > Each one of these images represents an occurrence in that I pressed > the shutter on my camera at different times for each one. Yes, technically, you could represent these 62 images as 62 separate Occurrence records (rather, as 62 separate events). But assuming the 62 shutter releases were all within a reasonable period of time (e.g., the same day), it would be perfectly appropriate to collapse these 62 events into a single event, which spanned in time from the first shutter-release to the last. The reason you would do that is that very, very few end-users would gain much wisdom about nature knowing the precise points in time that the organism occurred at that place. Most would be quite happy to infer that it also existed at the same place in-between the individual shutter-releases. Thus, representing a single event (anchored to the Occurrence) as a range of time from first shutter-release to last, would be adequate for essentially all use-cases. I relaize that each image contains with it the metadata for its moment of capture, but of course that is metadata that applies to the image (evidence of the occurrence); not the occurrence itself (which can be safely flattened to a single occurrence). For analagous reasons, many natural history collections aggregate multiple specimens of the same taxon collected at the same event into a single "lot", which gets a single catalog number, and is represented as a single occurrence. If I collect 100 individuals of [what I identify as] the same fish species at the same poison station, I will establish one specimen record, with individualCount set to 100, and represent it as a single Occurrence (even though technically, the 100 fish were captured at slightly different different times, and thus I could technically generate a different Event instance for each, and thus have 100 different occurrence records). > Ron Lance has collected tissue from this tree for grafting purposes > and now has an occurrence with basisOfRecord="LivingSpecimen" in his > arboretum in North Carolina. Andrea Bishop of the Tennessee Dept of > Environment and Conservation has seeds collected from the tree - I'd > call the collection of those seeds an occurrence record. I would probably do the same, assuming they weren't collected at the same time (plus or minus a few hours to a few days) as the tissue sample. But in either case, the tree at the place and time is the occurrence; the tissue sample and the seeds are just evidence of the occurrence. If either the time is substantially different (certainly possible!), or the location is different (not likely, it being a tree), then I would see justification for treating it as two separate occurrence records, so we know that the tree was at that place at those two (reasonably separate) times. And, of course, we'd want to join the two Occurrences via individualID. > So my > question to Marcus and others at GBIF is: how many dots will you put > on your map for this tree? My answer: one for each distinctly different moment in time that the tree was confirmed to be in that place (by whatever evidence). How does one define "distinctly different"? Well, I suspect that would be best judged by a biologist who could determine whether there is meaningful knowledge to be gained by knowning this tree was at this place at multiple points in time within the span of an hour, vs. multiple points in time within the spann of a day, or a month, or a year. Is diel variation important to document? Is lunar-cycle variation important to document? Is seasonal variation important to document? The answers to these questions would inform the decision of how many of these "potentially unique Occurrences" should be aggregated into a single occurrence, which would be represented by less-precision of time and/or place. > I anticipate that one response > to this question will be to call each imaging bout one "observation" > having a number of dwc:associatedMedia > references. That > collapses the number of occurrence records considerably, but not down > to one. It could be one. What is the time span of a "bout", compared to the time-span of the collection of all bouts combined? How important is it to resolve the time component of each bout individually, vs. aggregate them into a single bout, represented by a broader (less precise) window of time? > I took images of that tree on at least three separate instances over > the course of a year and Ron collected his graft tissue years before > that. Sounds to me like four occurrence records; presuming there is value in distingushing the occurrence of the tree at the place at different times of the year. > There is simply no way to reduce the number of occurrences for this > tree to one, nor should we want to. There is a way -- if you don't care about seasonal variation, you simply define the Event as a span of time covering all four visits to the tree. You probably wouldn't want to do that; but you certainly could. > A possible use > of multiple occurrence records (i.e. my first point above) of this > sort might be to establish how long individuals of Crataegus > harbisonii live and each occurrence record (whether separated by years > or by the seconds between shutter clicks) is a part of the record that > we should be able to (and want > to) preserve. Another use would be to track a non-sessile organism > (e.g. a whale) in both time and space. In that case, the record on a > map for an individual would be some kind of curve rather than a dot. > But in any case, recognizing the existence of an entity that I'm > calling an Individual facilitates these broader uses of occurrence > data and it's really hard for me to see how that is going to happen if > we ONLY have occurrences as separate entities. > Response Markus? > How does GBIF deal with whale tracks or multiple banded bird > observations for a single bird? If I understand your overall point correctly, it is something like this: Individuals potentially span multiple Occurrences. DwC uses individualID to link these multiple Occurrences together. However, there is no class for individualID, and hence no way to apply additional dwc metadata to the object represented by the individualID, other than through one or more occurrence records. Is that about right? I mean, we certainly can provide an individualID as a component of dwc:occurrence; but we have no way with dwc of assigning metadata specific to that individual, except through a series of occrence instances. > (In the oversimplified > examples I gave earlier, I applied a scientific name directly to an > individual. In actual practice, I relate individuals to > identifications and then relate the identifications to > taxa.) Good to know! This is, in my opinion, the right way to do it. > Again, to illustrate with a real-life example, when Bruce Kirchoff was > developing his Woody Plants of the Southeastern US learning software, > he asked a taxonomist to go through the images of mine that he was > using for the project to verify that they were identified correctly. > My old website just threw together all images of a particular species > onto one page without regard to the individuals from which they > originated (e.g. > http://www.cas.vanderbilt.edu/bioimages/species/sarar3.htm > and > http://www.cas.vanderbilt.edu/bioimages/species/soam3.htm). > It turns out that I had carelessly misidentified a vegetative Sambucus > racemosa ssp. > racemosa individual as Sorbus americana. The taxonomist asked me > which of the various bark, twig, leaf, etc. images were from the same > plant and the only way I could find out was through the laborious > process of looking for images with similar time/date values and my > hand written field notes. It was a nightmare finding all of the > particular image records that needed to have their identifications > fixed and then correcting them. On my new website (e.g. > http://bioimages.vanderbilt.edu/metadata.htm, then click on Quercus > chrysolepis), the images are connected to the individual from which > they originated. If I discover by looking at a particularly > informative image that I have misidentified the individual, I only > need to add an updated determination (i.e. identification) to that > individual's record and automatically all images from that individual > are displayed with the correct name and are placed on the correct > species page. Well...I would counter that you could achieve the same thing by representing things via Occurrence, and then cross-linking those Occurences that represent the same individual by using the shared individualID. The only thing you don't have is metdata specific to the individual anchored directly to the individualID. Instead, dwc denormalizes this a bit and aggregates those individual-specific metadata to other classes (Occurrence, Idnetification, etc.) It's not that I disagree that an "individual" is a useful class in the realm of biodiversity informatics. I also think there are a couple of important entities in taxon name/concept space that warrant their own classes. However, as John W. and Markus have both emphasized, DwC (necessarily) represents a compromise between a proper ontological mapping of the information classes, and a practical vehicle for information exchange amongst holders of biodiversity datasets. I find this constraining sometimes, but it helps when I remind myself of the following: DwC is a mechanism for exchanging data & metadata, not a database model or schema. As such, I think it covers most (but not all) of the need, with a reasonable (as opposed to normalized) set of classes and terms. If you have metadata for an individual, you can resolve (err...deference) that metdata by providing an appropriate individualID via dwc occurrence records. So, to re-state -- I don't disagree with your premise that there logically ought to be a class for individual; I'm just not sure it is necessary for DwC at this time. Having said that, and being a database-nerd with a tendency to hyper-normalize data models, I am mostly playing devil's advocate in my message here. In truth, I share your view that there should be (should have been) a class for Individual, and Occurrence should have simply been the union of an Individual and an Event. So....I reserve the right to stop playing Devil's Advocate, and join you in your efforts to make the case for an "individual" class. My only concern is that we may have different perspecives on how to scope "individual". In my mind, a better term would be "organism", rather than "individual"; because in my mind, once you allow a single coral head (as oppose to the individual polyps) to be represented as an "individual", you've just allowed for multiple "individuals" -- which opens the door to ever broader circumscriptions of multiple individuals (colony-->small group-->herd/school/flock-->population-->taxon concept). > I recognize that many "specimen-based" organizations aren't really > going to care one whit about this. That's fine. In their databases > and personal XML schemas they can ignore Individuals as it is their > prerogative. Actually, no we can't. Often is the case that a "lot" of 10 specimens is later determined to contain more than one taxon. In such cases, we *do* need to identify individuals, so we can separate the lot accordingly. I know it's not exactly the same as the examples you give, but fundamentally it's the same basic information flow: aggregated/abstract occurrence needs more precise recognition of individual organism. > But when we build > RDF templates, I believe strongly that for the benefit of those of us > who care about the broader applications of occurrences those templates > should use individuals to connect (one or more) occurrences and (one > or > more) identifications. For those with a technical bent, you can see > how I have done this for an herbarium specimen by looking at the page > source RDF of the example > http://bioimages.vanderbilt.edu/rdf/examples/lsu000/0429.rdf > . For those of a non-technical bent, just look at the webpage that > shows up when you click on the link. It looks just like any other web > page for a specimen and you don't even have to know that the > underlying RDF supports using Individuals as a grouping mechanism. I guess my real question is: is the case for individual as a class because you cannot represent certain information within DwC (via individualID) at all? Or that you could do so more elegantly if individual was broken out as a class? I certainly agree that it would be more elegant to treat individual as a class; I'm just not convinced that the increase in elegance justifies the increase in complexity/normalization of DwC. > In summary, I think we need Individual as a DwC class to enable > understandable rdfs:typing of records of individuals and to create a > context in which instances of individuals can be placed (i.e. people > would assign and use identifiers for individuals when they document > occurrences). These instances (and their assigned URI GUIDSs) would > allow for "connecting" > identifications and occurrences in a more meaningful way. I am not > suggesting that the occurrence be dethroned as the center of > biodiversity records. Assuming that the xxxxID terms end up being > moved out of the various classes and into the record-level terms area > as was suggested recently, I think that there are really only about > two terms that should be put into a new Individual class: the other > new term I have proposed > (individualRemarks) and establishmentMeans (but that is the topic of > another email). It may seem odd to suggest a adding a class that has > very few terms in it, but if you follow my reasoning above you will > hopefully understand why I have done so. OK, I guess I should have read this paragraph first -- it would have saved me a lot of typing above. But the words are already typed above, and I don't have time to go figure out which ones are no longer necessary, so I'm leaving it as written (Sorry!). Anyway, the way you frame it here certainly clarifies things in my mind, and nudges me closer to joining your crusade for establishment of an individual class. But I'm not yet sure we fully agree on the scope of what an "individual" is. The most intruiging passage in your entire email (for me) is this one: > I think that there are really only about two terms that should be put > into a new Individual class: the other new term I have proposed > (individualRemarks) and establishmentMeans (but that is the topic of > another email) By including establishmentMeans in your attributes of individual, you've piqued my interest in reading your "another email".... :-) > I hope that the discussion (and criticism!) will continue. > Again, I'm interested in hearing alternatives. I'll find time later to read and contemplate your other emails. For now, Id be interested in whether my comments in this email are useful, or am I just misunderstanding your basic point. Aloha, Rich

1 0

What I learned at the TechnoBioBlitz
by joel sachs 14 Oct '10

14 Oct '10

One of the goals of the recent bioblitz was to think about the suitability and appropriatness of TDWG standards for citizen science. Robert Stevenson has volunteered to take the lead on preparing a technobioblitz lessons learned document, and though the scope of this document is not yet determined, I think the audience will include bioblitz organizers, software developers, and TDWG as a whole. I hope no one is shy about sharing lessons they think they learned, or suggestions that they have. We can use the bioblitz google group for this discussion, and copy in tdwg-content when our discussion is standards-specific. Here are some of my immediate observations: 1. Darwin Core is almost exactly right for citizen science. However, there is a desperate need for examples and templates of its use. To illustrate this need: one of the developers spoke of the design choice between "a simple csv file and a Darwin Core record". But a simple csv file is a legitimate representation of Darwin Core! To be fair to the developer, such a sentence might not have struck me as absurd a year ago, before Remsen said "let's use DwC for the bioblitz". We provided a couple of example DwC records (text and rdf) in the bioblitz data profile [1]. I think the lessons learned document should include an on-line catalog of cut-and-pasteable examples covering a variety of use cases, together with a dead simple desciption of DwC, something like "Darwin Core is a collection of terms, together with definitions." Here are areas where we augemented or diverged from DwC in the bioblitz: i. We added obs:observedBy [2], since there is no equivalent property in DwC, and it's important in Citizen Science (though often not available). ii. We used geo:lat and geo:long [3] instead of DwC terms for latitude and longitude. The geo namespace is a well used and supported standard, and records with geo coordinates are automatically mapped by several applications. Since everyone was using GPS to retrieve their coordinates, we were able to assume WGS-84 as the datum. If someone had used another Datum, say XYZ, we would have added columns to the Fusion table so that they could have expressed their coordiantes in DwC, as, e.g.: DwC:decimalLatitude=41.5 DwC:decimalLongitude=-70.7 DwC:geodeticDatum=XYZ (I would argue that it should be kosher DwC to express the above as simply XYZ:lat and XYZ:long. DwC already incorporates terms from other namespaces, such as Dublin Core, so there is precedent for this. 2. DwC:scientificName might be more user friendly than taxonomy:binomial and the other taxonomy machine tags EOL uses for flickr images. If DwC:scientificName isn't self-explanatory enough, a user can look it up, and see that any scientific name is acceptable, at any taxonomic rank, or not having any rank. And once we have a scientific name, higher ranks can be inferred. 3. Catalogue of Life was an important part of the workflow, but we had some problems with it. Future bioblitzes might consider using something like a CoL fork, as recently described by Rod Page [4]. 4. We didn't include "basisOfRecord" in the original data profile, and so it wasn't a column in the Fusion Table [5]. But when a transcriber felt it was necessary to include in order to capture data in a particular field sheet, she just added the column to the table. This flexibility of schema is important, and is in harmony with the semantic web. 5. There seemed to be enthusiasm for another field event at next year's TDWG. This could be an opportunity to gather other types of data (eg. character data) and thereby i) expose meeting particpants to another set of everyday problems from the world of biodiversity workflows, and ii) try other TDWG technology on for size, e.g. the observation exchange format, annotation framework, etc. Happy Thanksgiving to all in Canada - Joel. ---- 1. http://groups.google.com/group/tdwg-bioblitz/web/tdwg-bioblitz-profile-v1-1 2. Slightly bastardizing our old observation ontology - http://spire.umbc.edu/ontologies/Observation.owl 3. http://www.w3.org/2003/01/geo/ 4. http://iphylo.blogspot.com/2010/10/replicating-and-forking-data-in-2010.html 5. http://tables.googlelabs.com/DataSource?dsrcid=248798

23 76

Why we may need both a more XML-like DarwinCore and a to be developed truly semantic one later.
by Peter DeVries 13 Oct '10

13 Oct '10

I am starting to see some reasons why there might be a need for an more XML type version of the DarwinCore and a separate, still undefined buy truly "semantic", version that still need to be worked out. Part of this is that I think it that most people don't understand the semantic issues and will not for sometime. So for those who are submitting their data to GBIF, I don't know if they have to understand all the somewhat counterintuitive semantic issues. Here is an example from one of our earlier discussions - I realized only later that I should have brought this up at the time. For XML using "scientificName" makes a lot of sense. However: 1) The current semantic web cannot have literals as subjects. 2) Also if you represent knowledge as triples without ontology-based inferencing, you need to define predicates that for both "directions" in a particular relationship. (In general) So if we had a URI for each scientific name we would need to make both of the following kinds of statements. <concept> *hasScientificNameURI* <name_uri> <name_uri> *isScientificNameURI_Of* <concept> In the LOD cloud, you cannot assume that everyone will load and be able to infer against your specific vocabulary. This is, in part, the result of vocabularies not always playing well together. Also, it is not clear to what extent inferencing will work well on really large data sets or for particular projects. Eventually this will get figured out, but for now we need predicates that can be used to represent both directions. (most of the time) Without them you can only query in one direction. This was not completely obvious to me until I had a test set and realized why I was not able to query it in the ways I wanted. So for the more XML-centric DarwinCore there is no problem with using * scientificName.* For the fully semantic web version, the following pattern might be easiest to clearly interpret. hasScientificName "Puma concolor (Linnaeus 1771)" hasScientificNameURI < http://gni.globalnames.org/name_strings/6c3dc35f-d901-5cc5-b9c8-ad241069b9f8 > This makes it clear that the first form is to be used for a literal while the second form is to be used for a conventionally resolvable URI. Why do we need these name URI's at all? Because some groups will need to relate name strings to each other and name strings to concepts etc. Hard to do when you can't use a literal as a subject. :-) Respectfully, - Pete ---------------------------------------------------------------- Pete DeVries Department of Entomology University of Wisconsin - Madison 445 Russell Laboratories 1630 Linden Drive Madison, WI 53706 TaxonConcept Knowledge Base <http://www.taxonconcept.org/> / GeoSpecies Knowledge Base <http://lod.geospecies.org/> About the GeoSpecies Knowledge Base <http://about.geospecies.org/> ------------------------------------------------------------

1 1

Extending the geo vocabulary to include a "radius" in meters example, with example ontology and RDF file
by Peter DeVries 11 Oct '10

11 Oct '10

I thought that some of the semantic web community might be able to provide some insight as to how we might be able to extend the geo vocabulary without breaking compatibility with existing tools and services. I think it would be best to try the suggestion below with some additional sample data to see if it works as we expect before making any real decision. Also note that this is most relevant to the fully semantic RDF version of the DarwinCore, and less relevant in the XML/CSV implementations. Below is my original question, my test vocabulary and RDF as well as abbreviated versions of the suggestions from others: # Original Question There was some discussion about ways to record species observations using the geo vocabulary at a recent biodiversity informatics meeting. Some see the advantages of using the geo standard, but we really need to have a way to incorporate and error or extent in meters. What would be the best way to extend the current geo vocabulary so that it includes this radius measure but still works well with geo aware tools and services? The addition would be defined as the total extent including calculated error (PointRadiusSpatialFit). This would be used to record that a species or "thing" was observed or collected within this geographical defined area. Something like the example below, but I suspect that this might not make it a real geo:Point? <geo:Point> <geo:lat>55.701</geo:lat> <geo:long>12.552</geo:long> <dwc:radius>10</dwc:radius> </geo:Point> This should work so that if I have 10,000 records recorded from within this same area, I can define it once and then refer to that area description RDF in the 10,000 species occurrence records with one simple URI to that area definition. One solution would be for the geo authors to add the radius to the geo vocabulary. Also there may be unrelated groups that might like the radius attribute for some other use. Another alternative would be to somehow extend the geo vocabulary within a separate vocabulary. It is not clear to me what is the best way to do this and still retain geo compatibility. I look forward to ideas and suggestions, # End of Original Question ... After reviewing the feedback I created a test vocabulary and RDF file. The test vocabulary is in it's own namespace and called dwc_area. It is here: http://lod.taxonconcept.org/ontology/dwc_area.owl The HTML Document is here http://lod.taxonconcept.org/ontology/dwc_area_doc/index.html (For some reason it did not include the imported geo vocabulary) I also made up a small test file that uses both the new geo URI and an shows the suggested way to include a radius measure. It is here: http://lod.taxonconcept.org/rdf/area_example.rdf It should show up in URIburner and Sindice soon. I did submit an earlier incorrect version into Sindice so that might show up as well. Here is what the RDF looks like in URIBurner < http://linkeddata.uriburner.com/about/html/http/lod.taxonconcept.org/rdf/ar…> To get to each of the three "Areas" you need to click on the links in the * topics* list * Note that the final location of the vocabulary is unclear. It will probably end up in the DarwinCore vocabular or in my txn vocabulary. # Below is background info and the suggestions from the LOD community. 1) There is proposed standard that everyone should know about *A Uniform Resource Identifier for Geographic Locations ('geo' URI)* http://tools.ietf.org/html/rfc5870 (from Sean Gillies) * Not clear that all the systems understand this but URIburner and Virtuoso interprets these as a URN type thing so they work but are not understood in the way that the "geo" vocabulary is understood. Note that if and when this becomes a standard it will allow these "Areas" to be universally understood. What this means is that I can markup my 10,0000 mosquito records from one location with one URN type id. 2) I got the following back from Bernard Vatan. > What about something as the following, since the radius is not really a property of the point ... * Note this differs from my final examples <dwc:Area> <geo:center> <geo:Point> <geo:lat>55.701</geo:lat> <geo:long>12.552</geo:long> </geo:Point> </geo:center> <dwc:radius>10</dwc:radius> </dwc:Area> 3) I also got this back from Paul Houle, > For Ookaboo I've worked out an internal data model for points; Ookaboo also knows about real shapes, but the fact is that most people out there will throw points at you and only know how to consume points. > Here are a few bits of extra data that are useful to add to a point > (1) provenance > (2) datum (I try to stick to WGS84, but points from freebase occasionally have a Datum attached, so I store it) > (3) circular error (the accuracy of the determination of the point, for instance the technical limitation of a GPS receiver) > (4) scale length of feature (how accurate do we have to be? it's not worth getting into an edit war over the exact point that represents, say, Finland.) > (5) an overall quality rating (so if we've got ten points we can pick the best) # I am looking forward to comments and suggestions. If people want, this can be incorporated into the DarwinCore, but it would be best if it was done that did not entail some specific TDWG domain and ranges. This would allow it to be use by others, (perhaps for completely different kinds of things) without having to tie their work into some specific conceptualization. Respectfully, - Pete ---------------------------------------------------------------- Pete DeVries Department of Entomology University of Wisconsin - Madison 445 Russell Laboratories 1630 Linden Drive Madison, WI 53706 TaxonConcept Knowledge Base <http://www.taxonconcept.org/> / GeoSpecies Knowledge Base <http://lod.geospecies.org/> About the GeoSpecies Knowledge Base <http://about.geospecies.org/> ------------------------------------------------------------

1 0

What RDF is (Was Re: Idea for Discussion, Differentiating between "type's" of identifiers)
by Bob Morris 07 Oct '10

07 Oct '10

On Wed, Oct 6, 2010 at 8:53 AM, Peter DeVries <pete.devries(a)gmail.com> wrote: >[...] > I think part of the problem we are having is that people are not recognizing > how different RDF is from straight XML. > ... It's way worse than that. RDF is not XML at all. RDF/XML is merely a serialization of RDF It's not even the most human readable serialization. In fact it is one of the \worst/ for humans who need to figure out what triples are actually in play. It is so ubiquitous only because there are more tools that can process RDF/XML than any of the other RDF serialization syntaxes (syntices???). The persistent myth that human readability is an advantage of XML pretty much ignores all the use cases that humans have for reading something. It's about as readable as Lisp. Indeed, a Lisp loving colleague said of XML on the occasion of its first W3 recommendation : "I get it. It's Lisp with pointy brackets." Bob -- Robert A. Morris Emeritus Professor of Computer Science UMASS-Boston 100 Morrissey Blvd Boston, MA 02125-3390 Associate, Harvard University Herbaria email: morris.bob(a)gmail.com web: http://bdei.cs.umb.edu/ web: http://etaxonomy.org/mw/FilteredPush http://www.cs.umb.edu/~ram phone (+1) 857 222 7992 (mobile) _______________________________________________ tdwg-content mailing list tdwg-content(a)lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-content

6 9

FYI: I am currently using the DBpedia URI's for TaxonAuthors where appropriate
by Peter DeVries 04 Oct '10

04 Oct '10

Steve and I have again run into similar issues when trying to create something that works well as LOD RDF. I have started to link to the DBpedia entries for those taxonomic authors that I recognize and exist in DBpedia. In one case, I created a page for an arachnologist so that he would have a resolvable URI. There is some lag between creating a Wikipedia page and it showing up in DBpedia but that is shortening. Also these Wikipedia pages are not as stable as I would like, but I think the DBpedia people probably can devise some solution. In this species concept I include both a link to the species description PDF and to the URI for the Author. HTML http://lod.taxonconcept.org/ses/2mqjL.html <http://lod.taxonconcept.org/ses/2mqjL.html>RDF http://lod.taxonconcept.org/ses/2mqjL.rdf <http://lod.taxonconcept.org/ses/2mqjL.rdf> Note that these species concepts have as a "Part" an original description, which has it's own section in the RDF. <txn:SpeciesOriginalDescription rdf:about=" http://lod.taxonconcept.org/ses/2mqjL#OriginalDescription">  <dcterms:title>Original Published Description relating to Species Concept Hentzia alamosa se:2mqjL</dcterms:title> <dcterms:identifier> http://lod.taxonconcept.org/ses/2mqjL#OriginalDescription </dcterms:identifier> <dcterms:description>LOD metadata about the original species description relating to Species Concept Hentzia alamosa se:2mqjL</dcterms:description> <dcterms:isPartOf rdf:resource=" http://lod.taxonconcept.org/ses/2mqjL#Species"/> <txn:hasAuthorURI rdf:resource=" http://dbpedia.org/resource/David_B._Richman"/> <txn:basionymName>Hentzia alamosa Richman, 2010</txn:basionymName> <txn:year>2010</txn:year> <txn:hasPDFVersion rdf:resource=" http://www.americanarachnology.org/JoA_free/JoA_v38_n1/arac-38-01-73.pdf"/> <txn:speciesOriginalDescriptionHasSpeciesConcept rdf:resource=" http://lod.taxonconcept.org/ses/2mqjL#Species"/> </txn:SpeciesOriginalDescription> Here is the view of this concept from within my triple store * Note that some email clients - notably AppleMail tries to change the encoded URI so the link below might not work for you. You can get to this same view by clicking on icon next to "Salticidae" on the html page < http://lsd.taxonconcept.org/describe/?url=http%3A%2F%2Flod.taxonconcept.org… > - Pete ---------------------------------------------------------------- Pete DeVries Department of Entomology University of Wisconsin - Madison 445 Russell Laboratories 1630 Linden Drive Madison, WI 53706 TaxonConcept Knowledge Base <http://www.taxonconcept.org/> / GeoSpecies Knowledge Base <http://lod.geospecies.org/> About the GeoSpecies Knowledge Base <http://about.geospecies.org/> ------------------------------------------------------------ _______________________________________________ tdwg-content mailing list tdwg-content(a)lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-content

1 0

Request to be added to the TDWG Google Project
by Peter DeVries 01 Oct '10

01 Oct '10

I did not see how to request to be added to the project on the google site. Could I be added to the list? Thanks :-) - Pete ---------------------------------------------------------------- Pete DeVries Department of Entomology University of Wisconsin - Madison 445 Russell Laboratories 1630 Linden Drive Madison, WI 53706 TaxonConcept Knowledge Base <http://www.taxonconcept.org/> / GeoSpecies Knowledge Base <http://lod.geospecies.org/> About the GeoSpecies Knowledge Base <http://about.geospecies.org/> ------------------------------------------------------------ _______________________________________________ tdwg-content mailing list tdwg-content(a)lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-content

1 0

Why the Linked Data Approach Makes Sense For Biodiversity Informatics
by Peter DeVries 29 Sep '10

29 Sep '10

I got a question tonight at TDWG about the advantages of the Linked Data approach. I described one of the main advantages in this blog post. http://www.taxonconcept.org/taxonconcept-blog/2010/8/5/why-linked-open-data… As with the BHL example, it often makes more sense to link to related data curated maintained by a group which has that area as their primary concern. The alternative is to spend resources replicating and curating data that is outside the main focus of your work. A related benefit is that the value of both linked resources is enhanced. I am not a biographer, and there are often very good articles about significant taxonomic authors on Wikipedia. The value of both DBpedia and TaxonConcept are increased when I correctly link between a species concept and a DBpedia resource describing a taxon author. For many of the taxa, you can go from a URI of a taxonomic author to lots of additional information related to the taxa he or she described. Respectfully, - Pete ---------------------------------------------------------------- Pete DeVries Department of Entomology University of Wisconsin - Madison 445 Russell Laboratories 1630 Linden Drive Madison, WI 53706 TaxonConcept Knowledge Base <http://www.taxonconcept.org/> / GeoSpecies Knowledge Base <http://lod.geospecies.org/> About the GeoSpecies Knowledge Base <http://about.geospecies.org/> ------------------------------------------------------------ _______________________________________________ tdwg-content mailing list tdwg-content(a)lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-content

1 0

Species Concept to GNI Namestring Linking - Initial Experiments
by Peter DeVries 29 Sep '10

29 Sep '10

In preparation for the Nomina session on Thursday. Here are some things to look at for the session titled "Exploring Semantic Web Technologies for Global Names Architecture Name Resolution" Dima and I have figured out a way to expose the name strings in the GNI to the Semantic Web. At this point it is really about exploring ways in which distributed data projects can link to entities in the GNI. In these experiments we have been exploring the mapping of names strings to species concepts. For the most part these should work with different kinds of species concepts but for now this experiment is using the TaxonConcept.org concepts. The html version for humans of the relevant species concept is < http://lod.taxonconcept.org/ses/v6n7p.html> The RDF version for computers of the relevant species concept is < http://lod.taxonconcept.org/ses/v6n7p.rdf> The initial stages were fairly basic. This concept has some association with the following name strings in the GNI. There was no real effort to determine the nature of these relationships until very recently. I marked up an RDF file that makes the following relationship assertions about how a concept is related to a particular name string. The GBIF site mentioned a movement toward databasing names in the following plain text form *Puma concolor (Linnaeus 1771)* * * * Italics can be added in web views etc. For the sake of argument, lets say that the preferred from is like that above with no comma between the author and date. This particular string could them be mapped to slight variations that are correctly formed and mean the same thing. This particular string could also be mapped to common misspellings etc of the same name. Those various alternatives form a lexical group. Similarly, the synonym *Felis concolor Linnaeus 1771* also has a list of essentially correct strings of characters and common malformed variants. This would be a second lexical group. So the concept represented by this page and URI can then be related to these name variants and a linkage is formed between the entities in the TaxonConcept Dataset and the GNI dataset. These relationships can be represented in the N3 form which some humans find easier to interpret than the alternative RDF/XML form. Note that these predicates have the "URI" suffix to differentiate between those predicates that expect URI object and and similar predicates that expect a literal object. Subject Predicate Object <http://lod.taxonconcept.org/ses/v6n7p#Species> txn:hasAcceptedScientificNameURI < http://gni.globalnames.org/name_strings/772d5162-f5aa-596c-98e0-a1c6c5a29bb9 > <http://lod.taxonconcept.org/ses/v6n7p#Species> txn:hasSynonymNameURI < http://gni.globalnames.org/name_strings/35da7f30-25ff-5111-ab29-1a4f9988ef51 > <http://lod.taxonconcept.org/ses/v6n7p#Species> txn:hasBasionymNameURI < http://gni.globalnames.org/name_strings/35da7f30-25ff-5111-ab29-1a4f9988ef51 > Rather than rely on inferencing I also make the reverse relationship Subject Predicate Object < http://gni.globalnames.org/name_strings/772d5162-f5aa-596c-98e0-a1c6c5a29bb9> txn:isAcceptedScientificNameURI_Of < http://lod.taxonconcept.org/ses/v6n7p#Species> < http://gni.globalnames.org/name_strings/35da7f30-25ff-5111-ab29-1a4f9988ef51> txn:isAcceptedScientificNameURI_Of < http://lod.taxonconcept.org/ses/v6n7p#Species> < http://gni.globalnames.org/name_strings/35da7f30-25ff-5111-ab29-1a4f9988ef51> txn:isBasionymNameURI_Of < http://lod.taxonconcept.org/ses/v6n7p#Species> These same statements are made in RDF/XML in the following RDF < http://lod.taxonconcept.org/tdwg_nomina.rdf > When exposed to the Linked Open Data Cloud those statements are associated with both the species concept and the GNI namestrings. In my own quad store you can see that they appear in this view of the species concept: < http://lsd.taxonconcept.org/describe/?url=http%3A%2F%2Flod.taxonconcept.org… > Not that relevant statements from other databases also appear - demonstrating one of the key advantages of the Linked Data approach. The nomina RDF and other information is part of this view even though it was not part of the basic species concept RDF above. The same concept is viewable on the cloud via the prettier Sig.ma service. < http://sig.ma/search?pid=9421eef0751cff0694b481d744607c98 > Note Sig.ma service also resolves the GNI namestring URI and exposed the rdf:label associated with that URI. - Pete ---------------------------------------------------------------- Pete DeVries Department of Entomology University of Wisconsin - Madison 445 Russell Laboratories 1630 Linden Drive Madison, WI 53706 TaxonConcept Knowledge Base <http://www.taxonconcept.org/> / GeoSpecies Knowledge Base <http://lod.geospecies.org/> About the GeoSpecies Knowledge Base <http://about.geospecies.org/> ------------------------------------------------------------ _______________________________________________ tdwg-content mailing list tdwg-content(a)lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-content

1 0

Potential predicates to relate species concepts to GNI namestring URI's
by Peter DeVries 28 Sep '10

28 Sep '10

I was working toward creating some consensus on a vocabulary on how to relate the namestrings in the Global Names Index to some sort of species concept. The goal is to have a vocabulary that works with a number of different "types" of species concept. It was suggested to me that I just go ahead and make one. Here is what I am proposing and hope to demonstrate at the Nomina section on Thursday at TDWG. One of the first things to decide is what should be the "best" form of a scientific name string. After looking through the GBIF info it seems that the following form which has no comma between the author and year might be preferred form. For example Puma concolor (Linnaeus 1771) The other various forms of the "same" name can then be related to each other using semantic web predicates in addition to the relationship between a name string and species concept. Using this as a model, I thought the following triple structure might work well to map the concept to Accepted, Synonym etc. Since the GNI namestrings are in the form of URI's they can serve as both subjects and objects. Literals can not be used as subjects. I use the form hasAcceptedScientificNameURI to distinguish between the URI form and the the literal form txn:hasAcceptedScientificName. I was a little reluctant to do this within the txn namespace since it might be something for the TDWG vocabulary. GUID Forms <concept> txn:hasAcceptedScientificNameURI < http://gni.globalnames.org/name_strings/772d5162-f5aa-596c-98e0-a1c6c5a29bb9 > <concept> txn:hasSynonymNameURI < http://gni.globalnames.org/name_strings/35da7f30-25ff-5111-ab29-1a4f9988ef51 > <concept> txn:hasBasionymNameURI < http://gni.globalnames.org/name_strings/35da7f30-25ff-5111-ab29-1a4f9988ef51 > < http://gni.globalnames.org/name_strings/772d5162-f5aa-596c-98e0-a1c6c5a29bb9> txn:isAcceptedScientificNameURI_Of <concept> < http://gni.globalnames.org/name_strings/35da7f30-25ff-5111-ab29-1a4f9988ef51> txn:isAcceptedScientificNameURI_Of <concept> < http://gni.globalnames.org/name_strings/35da7f30-25ff-5111-ab29-1a4f9988ef51> txn:isBasionymNameURI_Of <concept> Humans, note that the RDF representation of these GNI namestring information can be seen by adding ".rdf" to the end of the URI. Semantic Web applications already understand the distinction between the html and rdf representations. For example http://gni.globalnames.org/name_strings/772d5162-f5aa-596c-98e0-a1c6c5a29bb… It is also important to discuss and make a decision about the Domain and Range for each of these predicates. txn:hasAcceptedScientificNameURI Domain - Some sort of TaxonConcept but may be best to leave the Domain unspecified except that it should be a URI. Range - Some sort of Namestring represented in RDF. Within a typical browser, the RDF form of the URI It might make some sense to have a range that follows some standard RDF representation, but they do not necessarily have to be namestrings in the GNI. I was thinking that those RDF representations that follow a specific structure could be seen as instances of the class "NameString" If these are namestrings provided only by the GNI, then they might be in a modeled as instances of the class "GNI_NameString" ========== Literal Forms txn:hasAcceptedScientificName "Ochlerotatus triseriatus (Say 1823)" txn:hasAcceptedScientificName "Aedes triseriatus (Say 1823)" txn:hasBasionymName "Culex triseriatus Say 1823" GUID Forms <concept> txn:hasAcceptedScientificNameURI < http://gni.globalnames.org/name_strings/3f418cbf-358a-5174-ade1-25ae846a219e > <concept> txn:hasAcceptedScientificNameURI < http://gni.globalnames.org/name_strings/e9f5e126-5cdb-52bf-9050-349df4a9dd18 > <concept> txn:hasBasionymNameURI < http://gni.globalnames.org/name_strings/6ce63b2c-58be-5335-826b-622b7b4bc328 > < http://gni.globalnames.org/name_strings/3f418cbf-358a-5174-ade1-25ae846a219e> txn:isAcceptedScientificNameURI_Of <concept> < http://gni.globalnames.org/name_strings/e9f5e126-5cdb-52bf-9050-349df4a9dd18> txn:isAcceptedScientificNameURI_Of <concept> < http://gni.globalnames.org/name_strings/3f418cbf-358a-5174-ade1-25ae846a219e> txn:isBasionymNameURI_Of <concept> ========== Do we want to also include information like that described below. In some cases, each of the databases have their own version of the "Accepted Name" This would allow one to determine which DB's have different "Accepted" names <concept> txn:hasCOL2010_ScientificNameURI <> <concept> txn:hasNCBI_ScientificNameURI <> <concept> txn:hasITIS_ScientificNameURI <> <concept> txn:hasGBIF_ScientificNameURI <> Tracking the Catalog of Life LSID's over time. Since there is a new COL LSID each year, you will need to create some mapping between these. <concept> txn:hasCol2009LSID <urn:lsid:catalogueoflife.org: taxon:24e7d624-60a7-102d-be47-00304854f810:ac2009> <concept> txn:hasCol2010LSID <urn:lsid:catalogueoflife.org: taxon:24e7d624-60a7-102d-be47-00304854f810:ac2010> These LSID will work within VIrtuoso only because this quadstore has written extensions that allow them. LSID's themselves are not really true LOD identifiers. Most semantic web tools do not know how to deal with these. The relationships between these "properly formed" Accepted Names, Synonyms, Basionyms can then be represented with additional predicates depending on the relationship between the concept and the namestring. I have choosen to not emphasize what kind of taxon concept we are using since these should be usable with many "kinds" of taxon concepts. The advantage of representing these namestrings as URI's is that once loaded into a triplestore / quadstore one will be able to see and query what namestrings are related to a specific concept and what namestrings are related to various concepts. Unless their is some disagreement, I plan to modify my ontology and upload the example triples to the cloud so the namestring relationships are viewable in SIndice etc by the time of the Nomina meeting on Thursday. Respectively, - Pete -- ---------------------------------------------------------------- Pete DeVries Department of Entomology University of Wisconsin - Madison 445 Russell Laboratories 1630 Linden Drive Madison, WI 53706 TaxonConcept Knowledge Base <http://www.taxonconcept.org/> / GeoSpecies Knowledge Base <http://lod.geospecies.org/> About the GeoSpecies Knowledge Base <http://about.geospecies.org/> ------------------------------------------------------------ _______________________________________________ tdwg-content mailing list tdwg-content(a)lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-content

1 0