- tdwg-content - lists.tdwg.org

Spell checker for scientific names?
by Tony.Rees＠csiro.au 19 Jan '11

19 Jan '11

joel sachs wrote: > BTW, does anyone know a good spell checker for scientific names? Sounds like you may be interested in accessing my TAXAMATCH algorithm which is installed over my IRMNG database of generic and species names, available here: http://www.cmar.csiro.au/datacentre/irmng/ The database is around 90%+ complete for generic names (including non-valid ones) and maybe 50% for valid species names plus some synonyms (the latter based mainly on Catalogue of Life 2006 edition, with more to come). If you enter a single name for checking, fuzzy matches are automatically returned together with any exact matches. If you enter e.g. a line delimited list, the first pass does exact matches only (for speed) with the option to do a fuzzy search on any name not matched as a pre-formatted link. Currently it returns human-readable HTML but I will probably make an option for XML return if there is sufficient demand. Take a look and let me know if this is of interest, or if not, what you would prefer to see... Regards - Tony Rees, Tasmania ________________________________________ From: tdwg-content-bounces(a)lists.tdwg.org [tdwg-content-bounces(a)lists.tdwg.org] On Behalf Of joel sachs [jsachs(a)csee.umbc.edu] Sent: Wednesday, 19 January 2011 6:42 AM To: Peter DeVries Cc: tdwg-content(a)lists.tdwg.org Subject: Re: [tdwg-content] Bioblitz as rdf: does this make sense? Pete - I'm glad you're doing cool things with the data. A few comments/answers/questions ... i. The quests for consistently used canonical URIs, and consistently used canonical names are both, for now, somewhat quixotic, and I'm not sure one is more so than the other. GNA/GNI seems to be pursuing both. Is that a fair assessment? ii. I used opaque taxon concept URIs where they were readily available. Laziness motivated me to also use transparent identifiers for a. making sure each taxonConcept had an rdf:resource as an identifier, and b. asserting membership in the various rdfs:classes that I defined. But laziness has its drawbacks, and you point out a few of them. I think best practice when using either names or transparent URIs as identifiers would be to first run them through a spell checker and normalizer that would produce consistent usage of upper and lowe case characters, and probably drop authorship. Of course, this would produce some false positives when doing any sort of querying. But using UUIDs produces false negatives since they're not in common use. If we (as a community) follow through on the enthusiasm for creating competency cases that we showed in the Fall, it would be interesting to consider each case from the question of what's worse - false positives or false negatives. In any event, false positives can be weeded out by using the full scientific names and contextual information in the record, whereas false negatives may never be discovered. BTW, does anyone know a good spell checker for scientific names? iii. Mapping names to opaque URIs doesn't resolve the problems you raise below. Will the identifer for Carpodacus mexicanus be the same as the identifier for Carpodacus mexicanus (Statius Muller, 1776)? How about Arabis laevigata (Muhl. ex Willd.) Poir. vs. Arabis laevigata ? If yes, then why noy just use normalized names as identifiers? If no, then we'll get false negatives in the sorts of SPARQL queries that I gave at http://www.csee.umbc.edu/~jsachs/occurrences/queries/ BTW, is there a lookup service for taxonconcept.org identifiers (i.e. give a list of names, get a list of identifiers)? iv. In what sense do you see Darwin Core as being deficient as a semantic web representation? Regards - Joel. On Thu, 13 Jan 2011, Peter DeVries wrote: > Thanks Joel, > > Here is one of the BioBlitz Occurrence Records marked up with Darwin Core > > http://lsd.taxonconcept.org/describe/?url=http://www.cs.umbc.edu/~jsachs/oc… > > Here is one of the TaxonConcept Records marked up in the txn vocabulary > http://lsd.taxonconcept.org/describe/?url=http://ocs.taxonconcept.org/ocs/f… > > Some people have trouble with how the %23 above is escaped in their email, > they might like this bit.ly bundle > better.<http://lsd.taxonconcept.org/describe/?url=http://ocs.taxonconcept.org/ocs/f…> > <http://lsd.taxonconcept.org/about/html/http/ocs.taxonconcept.org/ocs/f52244…> > http://bit.ly/hZdUpP > > <http://bit.ly/hZdUpP>Also an issue to discuss is that identifications are > to both a name and a concept so > > Should these should be the same dwc:taxonConcepts > > http://spire.umbc.edu/ethan/Apis_mellifera > http://spire.umbc.edu/ethan/Apis_Mellifera > ==> http://bit.ly/g1zzJC (Apis mellifera se:z9oqP) > > http://spire.umbc.edu/ethan/Ascelpius_syruaca > http://spire.umbc.edu/ethan/Asclepias_syriaca > ==> HTML page http://lod.taxonconcept.org/ses/tTEIq.html Concept View > Bit.ly http://bit.ly/dJHJqj > > http://spire.umbc.edu/ethan/Aster_nova-belgii > http://spire.umbc.edu/ethan/Aster_nova-gelgii > > http://spire.umbc.edu/ethan/Baccharis_halimifolia > http://spire.umbc.edu/ethan/Baccharis_halimifolia_L. > > http://spire.umbc.edu/ethan/Bartonia_virginia > http://spire.umbc.edu/ethan/Bartonia_virginica > > http://spire.umbc.edu/ethan/Branta_canadensis > http://spire.umbc.edu/ethan/Branta_canadensis_(Linnaeus,_1758) > > http://spire.umbc.edu/ethan/Carex_pennsylvanica > http://spire.umbc.edu/ethan/Carex_pensylvanica > > http://spire.umbc.edu/ethan/Cyperus_esculantus > http://spire.umbc.edu/ethan/Cyperus_Esculantus > http://spire.umbc.edu/ethan/Cyperus_esculentus > http://spire.umbc.edu/ethan/Cyperus_esculentus_L. > > http://spire.umbc.edu/ethan/Carpodacus_mexicanus > http://spire.umbc.edu/ethan/Carpodacus_mexicanus_(Statius_Muller,_1776) > >> From the taxonconcepts their should be a link to the various name strings. > > vs. modeling the namestring as the concept. > > Also I think that DarwinCore is good for somethings but maybe not as a > semantic web representation. > > Respectfully, > > - Pete > > > On Thu, Jan 13, 2011 at 6:53 AM, joel sachs <jsachs(a)csee.umbc.edu> wrote: > >> Pete, >> Thanks - I corrected the geo properties. >> Joel. >> >> >> >> >> On Wed, 12 Jan 2011, Peter DeVries wrote: >> >> Hi Joel, >>> >>> Cool :-) >>> >>> I just loaded this into my SPARQL endpoint. >>> >>> In the named graph >>> urn:org:linkedopenspeciesdata:dataspace:tdwg2010bioblitz >>> >>> It consists of 19,990 Triples >>> >>> Here is one of the dwc:taxonConceptID entries. >>> >>> *About: http://spire.umbc.edu/ethan/Ampelopsis_brevipedunculata* >>> >>> http://lsd.taxonconcept.org/describe/?url=http://spire.umbc.edu/ethan/Ampel… >>> >>> *About: http://www.cs.umbc.edu/~jsachs/occurrences/tdwg2010bioblitz_1627* >>> < >>> http://lsd.taxonconcept.org/describe/?url=http://spire.umbc.edu/ethan/Ampel… >>>> >>> >>> http://lsd.taxonconcept.org/describe/?url=http://www.cs.umbc.edu/~jsachs/oc… >>> >>> >>> >>> < >>> http://lsd.taxonconcept.org/describe/?url=http://www.cs.umbc.edu/~jsachs/oc… >>>> This >>> should give you an a count of occurrences. >>> >>> SELECT count(*) WHERE {?s a <http://rs.tdwg.org/dwc/terms/#Occurrence>}; >>> >>> = 1882 >>> >>> SELECT count(*) WHERE {?s a <http://rs.tdwg.org/dwc/terms/#taxonConceptID >>>> }; >>> >>> This should give you a list of occurrences >>> >>> >>> http://lsd.taxonconcept.org/describe/?url=http://rs.tdwg.org/dwc/terms/%23O… >>> >>> If this did not come through your email system try the bit.ly. >>> >>> http://bit.ly/g9BcoL >>> >>> I tried the following that should have given me a google map of all the >>> occurrences but it did not result in the map. >>> >>> DESCRIBE ?x WHERE { >>> ?x <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> < >>> http://rs.tdwg.org/dwc/terms/#Occurrence>. >>> } >>> >>> I looked that the RDF and I think I see the problem. >>> >>> In the RDF >>> >>> <geo:latitude> >>> 41.53 >>> </geo:latitude> >>> >>> <geo:longitude> >>> -70.67 >>> </geo:longitude> >>> >>> Should be >>> >>> <geo:lat> >>> 41.53 >>> </geo:lat> >>> >>> <geo:long> >>> -70.67 >>> </geo:long> >>> >>> See http://www.w3.org/2003/01/geo/ >>> >>> I did the following query to get a list of all the dwc:taxonConceptID's >>> and >>> have attached them as a .txt file. >>> >>> select distinct ?o WHERE {?s < >>> http://rs.tdwg.org/dwc/terms/#taxonConceptID> >>> ?o} >>> >>> Pretty neat :-) >>> >>> There are some things that I will get back to Joel on. >>> >>> Here is where you can manually enter a SPARQL query. Click on "Advanced" >>> for >>> the entry window. >>> >>> http://lsd.taxonconcept.org/isparql/ >>> >>> Respectfully, >>> >>> - Pete >>> >>> >>> >>> On Wed, Jan 12, 2011 at 5:55 PM, joel sachs <jsachs(a)csee.umbc.edu> wrote: >>> >>> Hi Everyone, >>>> >>>> I've posted rdf of the bioblitz data. It's at >>>> http://www.cs.umbc.edu/~jsachs/occurrences/TechnoBioblitzOccurrences.rdf. >>>> >>>> Individual occurrences can be retrieved via >>>> http://www.cs.umbc.edu/~jsachs/occurrences/[occurrence_id]<http://www.cs.umbc.edu/~jsachs/occurrences/%5Boccurrence_id%5D> >>>> e.g. http://www.cs.umbc.edu/~jsachs/occurrences/tdwg2010bioblitz_1835 >>>> >>>> Individual identifications can be retrieved via >>>> http://www.cs.umbc.edu/~jsachs/identifications/[identification_id]<http://www.cs.umbc.edu/~jsachs/identifications/%5Bidentification_id%5D> >>>> e.g. >>>> http://www.cs.umbc.edu/~jsachs/identifications/tdwg2010bioblitz_1835_id_1 >>>> >>>> The scripts behind this are on the kludgy side, so reports of errors and >>>> abnormalities will be warmly welcomed. >>>> >>>> Implicit in each of the following notes is the question "Is this a good >>>> way to do it?": >>>> >>>> 1. The data is "normalized" w.r.t. identification. "Normalized" is in >>>> quotes because I mean it in the sense that Steve Baskauf was using in his >>>> Fall 2010 series of posts. His meaning of the term makes sense to me, but >>>> many people (e.g. the OBO folks), take "normalized ontology" to mean >>>> "disentangled" (i.e. no multiple inheritance.) >>>> As an example, here's an occurrence with two crowdsourced determinations: >>>> http://www.cs.umbc.edu/~jsachs/occurrences/tdwg2010bioblitz_1644 >>>> >>>> 2. I used sequential integers for observation and identification IDs; in >>>> practice, a mechanism needs to be in place to prevent two people from >>>> assigning the same id to their respective identifications. >>>> >>>> 3. My answer to Cam Webb's Question #1 from >>>> http://lists.tdwg.org/pipermail/tdwg-content/2010-October/001720.html >>>> is "both". In other words, just as "Joel Sachs" is both me and also my >>>> name, so >>>> http://www.cs.umbc.edu/~jsachs/occurrences/tdwg2010bioblitz_1668 is both >>>> an occurrence and an occurrence_id, expressed as: >>>> --- >>>> <dwc:Occurrence >>>> rdf:about=" >>>> http://www.cs.umbc.edu/~jsachs/occurrences/tdwg2010bioblitz_1644"> >>>> <dwc:occurrenceID> >>>> http://www.cs.umbc.edu/~jsachs/occurrences/tdwg2010bioblitz_1644 >>>> </dwc:occurrenceID> >>>> <blah blah blah/> >>>> </dwc:Occurrence> >>>> --- >>>> >>>> 4. I was surprised to see that the Darwin Core Identification class has >>>> no >>>> "occurrenceID" or "specimenID" term. How is one supposed to tie an >>>> identification to an observation (assuming the identification is not >>>> in-lined, of course)? DeVries and Baskauf each mint their own terms for >>>> doing this (txn:identificationHasOccurrence, and >>>> sernec:basedOnOccurrence, >>>> respectively); I used dwc:occurrenceID as if it were a record level term. >>>> >>>> 5. We had scope for multiple taxonConceptID columns in the Fusion table, >>>> and assigned lsids where possible. I also mean to work with Pete to >>>> assign >>>> GUIDs from taxoncocept.org. In addition, I assigned ethan taxon concept >>>> ids, which look like this: >>>> http:.//spire.umbc.edu/ethan/Coffea_arabica >>>> >>>> In their argument over opaque vs. transparent taxonCoceptIDs, I was >>>> sympathetic to both Pete's and Gregor's arguments. Ultimately, if the >>>> tooling exists to always display the rdfs:labels every time I'm loooking >>>> at a list of opaqueIDs, then transparent IDs are unnecessary. But, for >>>> now, it's really helpful to look at an ID and know what it's referring >>>> to. >>>> >>>> (For species names not in the spire database, the rdf returned by >>>> http:.//spire.umbc.edu/ethan/$name >>>> is simply an rdfs:seeAlso to >>>> http://http://gni.globalnames.org/name_strings?search_term=$name) >>>> >>>> 6. It was easy to assert membership in RDF classes corresponding to >>>> various Cape Cod categories of concern - invasive species, threatenened >>>> species, indicators, etc. You can see these classes at >>>> http://spire.umbc.edu/ontologies/lists (Information of where these lists >>>> come from is included as rdfs:comments. I'll add further documentation, >>>> e.g. links to eml files.) >>>> >>>> Note that "ThingOfConcern" is defined as the superclass of all the other >>>> classes in the collection. The idea here is that people can create their >>>> own "ThingOfConcern" class, and then query for observations that are of >>>> concern to them. You can see sample sparql queries at >>>> http://www.csee.umbc.edu/~jsachs/occurrences/queries/sample.txt >>>> >>>> >>>> As an aside, I think we, as a community, should come up with a >>>> biodiversity benchmark suite of rdf data and corresponding sparql >>>> queries, >>>> that can be >>>> used to test the suitability and scalability of semantic web knowledge >>>> bases. I'll take this up in a future post (unless someone beats me to >>>> it). >>>> >>>> Comments, questions, and better ideas are welcome. >>>> >>>> Thanks - >>>> Joel. >>>> >>>> _______________________________________________ >>>> tdwg-content mailing list >>>> tdwg-content(a)lists.tdwg.org >>>> http://lists.tdwg.org/mailman/listinfo/tdwg-content >>>> >>>> >>> >>> >>> -- >>> --------------------------------------------------------------- >>> 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/> >>> ------------------------------------------------------------ >>> >>> > > > -- > --------------------------------------------------------------- > 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

Fwd: Annotation Ontology best practice relation for linking to image/machine-opaque docs? biomedical use case
by Peter DeVries 15 Jan '11

15 Jan '11

This discussion of what specific meanings to assign to various widely used predicates reminds me how often this list seems to prefer operating only within itself. A number of these kinds of issues have been discussed elsewhere. The argument has always been made that we should use standards but when those standards are not those proposed on this list they seem to be ignored. Whether it is the appropriate use of rdfs:seeAlso or other existing widely used vocabularies. Note below a separate Annotations vocabulary. Respectfully, - Pete ---------- Forwarded message ---------- From: Tim Clark <tim_clark(a)harvard.edu> Date: Mon, Jan 10, 2011 at 1:34 PM Subject: Re: best practice relation for linking to image/machine-opaque docs? biomedical use case To: "M. Scott Marshall" <mscottmarshall(a)gmail.com> Cc: HCLS IG <public-semweb-lifesci(a)w3.org>, public-lod(a)w3.org, Daniel Rubin <dlrubin(a)stanford.edu>, "John F. Madden" <john.madden(a)duke.edu>, Vasiliy Faronov <vfaronov(a)gmail.com>, Toby Inkster <tai(a)g5n.co.uk>, Peter DeVries < pete.devries(a)gmail.com>, Tim Berners-Lee <timbl(a)w3.org>, Paolo Ciccarese < paolo.ciccarese(a)gmail.com>, Anita de Waard <A.dewaard(a)elsevier.com>, Maryann Martone <maryann(a)ncmir.ucsd.edu> Hi Scott, For referring to a portion of an image, let me point you to work in my group done in collaboration with HCLS Scientific Discourse Task, UCSD, Elsevier, and one of the major pharmas. Paolo Ciccarese is the main author, and this work is based on the earlier W3C project Annotea. AO, Annotation ontology, here: http://code.google.com/p/annotation-ontology/, presented at Bio Ontologies 2010, and full-length paper in press at BMC Bioinformatics. Bio Ontologies 2010 slides here: http://www.slideshare.net/paolociccarese/ao-annotation-ontology-for-science… AO uses a special subclass of Selector to specify the part of the document (image) being referred to. see here for Selectors: http://code.google.com/p/annotation-ontology/wiki/Selectors and here for an example of image annotation: http://code.google.com/p/annotation-ontology/wiki/AnnotationTypes Best Tim On Jan 10, 2011, at 11:30 AM, M. Scott Marshall wrote: > [Scott dusts off old use case and pulls from the shelf. Adjusts > subject of thread. Was: best practice for referring to PDF] > > In Health Care and Life Science domains, image data is a common form > of data under discussion so a best practice for referring to an image > or to an (extractable) feature *within* an image would cover a > fundamental need in biomedicine to point to 'raw' data as evidence (as > well as giving meaning to the raw data!). > > A clinical example from breast cancer: > There is a scan that produces an image that contains features referred > to by the radiologist as 'microcalcifications', which can be > indicative of the presence of a tumor. > > I can think of a few scenarios that would refer to the image data > (mammogram). There are probably more: > 1) The radiology report (in RDF) asserts the presence of > microcalcifications and refers to the entire image as evidence. > 2) The radiology report (in RDF) asserts the presence of > microcalcifications and refers to the entire image as evidence, along > with a image processing/feature extraction program that will highlight > the phenomenon in the image. > 3) The radiology report (in RDF) asserts the presence of > microcalcifications and refers to a specific region in the image as > evidence using some function of a 2D coordinate system such as > polyline. > > The question: How can we refer to the microcalcifications as an > indication of a certain type of tumor in each case 1, 2, and 3 in RDF? > > I am especially interested in the 'structural' aspects: How do we > refer to the image document as containingEvidence ? How can we refer > to a *region* of the image in the document? How can we refer to the > software that will extract the relevant features with statistical > confidence, etc.? > > Any ideas or pointers to existing practices would be appreciated. I'm > aware of some related work in multimedia to refer to temporal regions > but I am specifically interested in spatial regions. > > Note that an analogous question of practice exists for textual > documents such as literature in PubMed that can be text-mined for > (evidence of) assertions. > > * Note: 2D is a simplification that should come in handy in > implementations and often deemed necessary, such as thumbnails. > > -Scott > > -- > M. Scott Marshall, W3C HCLS IG co-chair, http://www.w3.org/blog/hcls > Leiden University Medical Center / University of Amsterdam > http://staff.science.uva.nl/~marshall > > On Mon, Jan 10, 2011 at 4:01 PM, Tim Berners-Lee <timbl(a)w3.org> wrote: >> It is well to look at and make best practices for the things >> we have if we don't >> >> It was the FOAF folks who, initially, instead of using linked data, >> used an Inverse Functional Property to uniquely identify >> someone and then rdfs:seeAlso to find the data about them. >> So any FOAF browser has to look up the seeAlso or they >> don't follow any links. >> >> So tabulator always when looking up x and finding x see:also y will >> load y. So must any similar client or any crawler. >> >> So there is a lot of existing use we would throw away if we >> allowed rdfs:seeAlso for pointing to things which do not >> provide data. (It isn't the question of conneg or mime type, >> that is a red herring. it is whether there is machine-redable >> standards-based stuff about x). >> >> Further, we should not make any weaker properties like seeDocumentation >> subproperties of see:Also, or they would imply >> We maybe need a very weak top property like >> >> mayHaveSomeKindOfInfoAboutThis >> >> to be the superProperty of all the others. >> >> One things which could be stronger than seeAlso is definedBy if it >> is normally used for data, to point to the definitive ontology. >> That would then imply seeAlso. >> >> Tim > > -- --------------------------------------------------------------- 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/> ------------------------------------------------------------

3 2

dcterms:creator
by Hannu Saarenmaa 14 Jan '11

14 Jan '11

Greetings We would need a term to store the name of the person who has digitised a sample. The current Darwin Core does not seem to include such term. Dublin Core's "creator" is what we'd use. I wonder why not all of the Dublin Core's 15 basic terms are included in Darwin Core terms web page, but just a subset of them, which subset seems to be somewhat random to me? We could also use the DC term "contributor" or something for someone who has proof-read the digitisation result. I understand that nothing breaks if we use dc:creator because the Dublin Core schema loads it along with other elements. But because of this omission some applications like GBIF IPT omit it from their mapping capabilities, which is a problem. Your advise is sppreaciated, Hannu -- Hannu Saarenmaa, Project Manager Digitisation Centre of the Finnish Museum of Natural History Faculty of Science and Forestry University of Eastern Finland P.O. Box 111 FIN-80101 Joensuu Street address: Länsikatu 15, room 2C113 in Joensuu Science Park hannu.saarenmaa(a)helsinki.fi Telephone +358-13-251-5705 Mobile +358-50-4479668

6 7

[Fwd: Re: most GUIDs/URIs for names/taxon stuff not ready for prime time]
by Donat Agosti 11 Jan '11

11 Jan '11

Rod's point that "they offer no added value" reflects pretty much the discussion we have on names. Nobody asks the question "name of what?". Names are linked to observations ie specimens. Any identifier, or indeed the underlying treatment, that does not deliver this data is up in the air and thus meaningless. Not just for the publisher who wants to use the name, but also the taxonomists, who can not discuss the meaning of names. Discussions are done through publications and they don't allow this either at the very moment, not for the machine (or at best with a considerable, prohibitive effort), nor people. A simple solution would be that in future to each usage of a name in taxonomic literature, at least for treatments, the name has to be explicitly linked to the underlying specimen or observation data. Since this is part of a treatment, the identifier should allow to retrieve the treatment and through it the specimen data or at least the observation data and the author who used it in this specific selection. Donat > Why aren't identifiers reused? > ---------------------------------------- > > Because in most cases they offer no added value. If I have a ITIS TSN > there's not much I can do with it. I can get a name from ITIS (with > some vague assurance that thus name is accepted - or not - with no > evidence for this assertion). I can think of only two taxonomic > identifiers that have real value and get much reuse, NCBI taxonomy ids > and uBio NameBankIDs. NCBI ids are reused because they underpin the > genomics databases, and genomics does real computational biology, and > makes extensive reuse of data (as exemplified by the annual Nucleic > Acids Research database issue). uBio NameBankIDs get reused because > uBio has lots of names, and provides services for discovering those > names in text (see, e.g., their use by BHL). > > Few taxonomic name databases provide a compelling reason for anyone to > use their identifiers, most being digital sinks (you go there, get an > identifier for a name, and nothing else). > > > Why UUIDS? > ---------------- > > UUIDs are ugly, and solve a problem that for the most part we don't > have. They are ideal for minting globally unique identifiers in a > distributed system, but we don't have distributed systems. Catalogue > of Life uses UUIDs, but these are centrally created (I suspect using > MySQL's UUID function, given how similar the UUIDs are to each other). > ZooBank uses them, but it is not (yet) a distributed system. If the > Catalogue of Life were genuinely a distributed system UUIDs would make > sense, but that's not actually how it works. > > I think users would cope with UUIDs if the databases using them > provides clear value. For example, MusicBrainz uses UUIDs > http://musicbrainz.org/artist/563201cb-721c-4cfb-acca-c1ba69e3d1fb.html > , as does Mendeley, the latter hiding them from users via human- > readable URLs. Given that we have obvious user-friendly candidates for > URLs (taxonomic names), it would be trivial to hide UUIDs in names > (making homonyms distinct by adding authorship, or whatever it took to > make them unique as strings). > > What, if anything, is a taxonomic name? > ---------------------------------------------------- > > In my experience, when non-taxonomists meet taxonomists things get > ugly. For example, a publisher wanting to mark up taxonomic names in > text might ask taxonomists how to do this,and within minutes the > taxonomists are off into discussions of namestrings versus usages > versus concepts and pretty soon the publisher deeply regrets ever > asking the question. I've been at meetings where the look in > publishers' eyes said "run away, run away". > > Part of the reason we have multiple databases is because different > projects are capturing different things (roughly speaking, uBio is > mostly about namestrings, Catalogue of Life is about concepts, IPNI > and ZooBank are about first usage of a name, etc.) > > Most users outside our field won't give a damn about the niceties of > these distinctions, yet we persist in discussing them ad nauseam. > Until we provide a single, very simple service that takes a name > string and hides all this complexity (unless the user chooses to see > the gory details) while still providing useful information, we will be > stuck in multiple identifier hell. The tragedy is we've never had > more people genuinely interested in linking to names than at present > -- publishers are desperately trying to add "semantic value" to their > content, and we are spectacularly ill-equipped to deliver this (and > it's our own fault). > > I rather suspect we're rapidly approaching the point where users > outside taxonomy will simply say "to hell with these taxonomists, > let's just use Wikipedia and be done with it." > > Regards > > Rod > > --------------------------------------------------------- > Roderic Page > Professor of Taxonomy > Institute of Biodiversity, Animal Health and Comparative Medicine > College of Medical, Veterinary and Life Sciences > Graham Kerr Building > University of Glasgow > Glasgow G12 8QQ, UK > > Email: r.page(a)bio.gla.ac.uk > Tel: +44 141 330 4778 > Fax: +44 141 330 2792 > AIM: rodpage1962(a)aim.com > Facebook: http://www.facebook.com/profile.php?id=1112517192 > Twitter: http://twitter.com/rdmpage > Blog: http://iphylo.blogspot.com > Home page: http://taxonomy.zoology.gla.ac.uk/rod/rod.html > > > > > > > > _______________________________________________ > tdwg-content mailing list > tdwg-content(a)lists.tdwg.org > http://lists.tdwg.org/mailman/listinfo/tdwg-content > -- Dr. Donat Agosti Research Associate, American Museum of Natural History and Smithsonian Institution Email: agosti(a)amnh.org Web: http://antbase.org CV: http://research.amnh.org/entomology/social_insects/agosticv_2003.html Swiss Residence Elahieh Ave. Khazer no. 74 19649 Teheran Iran +98-21-2200 8765 (office) +98-21-2260 6160 (home) +98-919-489 2744 (mobile) +1-202-558 0330 (skype-in US) +41-44-5862911 (skype-in Switzerland) -- Dr. Donat Agosti Research Associate, American Museum of Natural History and Smithsonian Institution Email: agosti(a)amnh.org Web: http://antbase.org CV: http://research.amnh.org/entomology/social_insects/agosticv_2003.html Swiss Residence Elahieh Ave. Khazer no. 74 19649 Teheran Iran +98-21-2200 8765 (office) +98-21-2260 6160 (home) +98-919-489 2744 (mobile) +1-202-558 0330 (skype-in US) +41-44-5862911 (skype-in Switzerland)

3 3

Re: [tdwg-content] most GUIDs/URIs for names/taxon stuff not ready for prime time
by Tony.Rees＠csiro.au 09 Jan '11

09 Jan '11

Dear all, >From where I sit (very much on the sideline of this debate, waiting to see what happens), the main trouble I see is that (1) anyone and his dog can mint yet another unique identifier for the same taxon name, leading to uncontrolled proliferation and never ending ID reconciliation issues, and (2) there are always some names not on any particular external "identifier assigning" list which therefore lack an identifier (however have a scientific name) just when you want one. No problem, just mint your own, however that feeds back into (1) again... Just curious - ITIS TSNs would have to be one of the longest established and promoted systems of "non-name" identifiers for taxon names - have they been successful in anyone's view, or if not, why not... Any comments appreciated. Regards - Tony

4 8

Fwd: Tim Berners-Lee .. Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?, existing predicate for linking to PDF?
by Peter DeVries 08 Jan '11

08 Jan '11

---------- Forwarded message ---------- From: Tim Berners-Lee <timbl(a)w3.org> Date: Fri, Jan 7, 2011 at 10:47 AM Subject: Re: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?, existing predicate for linking to PDF? To: Peter DeVries <pete.devries(a)gmail.com> Cc: public-lod(a)w3.org Certainly. the tabulator follows rdfs:seeAlso and expects some terse RDF. and so would be crippled by any large file, and PDF would not of course help it at all. I take seeAlso as a fairly strong request to see the other thing, like an HTTP redirect. Not a generic "this is vaguely related" link at all, and not in general to point to human-readable stuff. Tim On 2011-01 -06, at 14:40, Peter DeVries wrote: I was wondering if there is an existing predicate for linking to a PDF file? I would like to incorporate a link between bibliographic reference description and a URL to the location of a PDF of that document. I had minted a predicate txn:hasPDFVersion, as demonstrated in this RDF snippet. (Part of http://lod.taxonconcept.org/ses/v6n7p.rdf ) <txn:SpeciesOriginalDescription rdf:about=" http://lod.taxonconcept.org/ses/v6n7p#OriginalDescription">  <dcterms:title>Original Published Description relating to Species Concept Puma concolor se:v6n7p</dcterms:title> <dcterms:identifier> http://lod.taxonconcept.org/ses/v6n7p#OriginalDescription </dcterms:identifier> <dcterms:description>LOD metadata about the original species description relating to Species Concept Puma concolor se:v6n7p</dcterms:description> <dcterms:isPartOf rdf:resource=" http://lod.taxonconcept.org/ses/v6n7p#Species"/> <txn:hasAuthorURI rdf:resource=" http://dbpedia.org/resource/Carl_Linnaeus"/> <txn:hasBasionymName>Felis concolor Linnaeus 1771</txn:hasBasionymName> <txn:year>1771</txn:year> <txn:hasPDFVersion rdf:resource=" http://assets.geospecies.org/spec_concept_uuid/603bebac-cc44-4168-bbf7-b11b… "/> <txn:speciesOriginalDescriptionHasSpeciesConcept rdf:resource=" http://lod.taxonconcept.org/ses/v6n7p#Species"/>  <wdrs:describedBy rdf:resource=" http://lod.taxonconcept.org/ses/v6n7p.rdf"/> </txn:SpeciesOriginalDescription> Some have suggested using rdfs:seeAlso to link to what could be a multimegabyte PDF, but I think this would cause problems for a number of RDF crawlers like Elmo. In summary, I think it would be useful to have a predicate that can be used for linking specifically to a PDF document. Is there an existing predicate for this? What do people think about the suggestion to use rdfs:seeAlso to link to a PDF? I would also like to know of others thoughts or suggestions regarding this issue, 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/> ------------------------------------------------------------ -- --------------------------------------------------------------- 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

most GUIDs/URIs for names/taxon stuff not ready for prime time
by Steve Baskauf 07 Jan '11

07 Jan '11

Well, I have continued my quest for resolvable, RDF-producing GUIDs for taxon/name-related stuff. I have gotten a lot of good information from reading Rod Page's BMC Bioinformatics paper (http://dx.doi.org/10.1186/1471-2105-10-S14-S5) and from investigating his http://bioguid.info/ site. From the standpoint of the "sec./sensu" part of a TNU/taxon concept, based on the recent discussion, it sounds like the DIO solution for publications is a good direction to go IF resolution services producing RDF comes into existence and IF it becomes possible to actually search for the DIOs of more obscure publications. I tried using Rod's site to look up a journal article using the ISSN, volume, and page and the web interface found the DOI and generated RDF just fine. However, an attempt to use the web to find the DIO of Gleason and Cronquist's Manual of vascular plants of Northeastern United States and adjacent Canada failed despite a half hour of effort (I found the UPC, the LOC call number, and the ISBN, but no DOI). Maybe there just isn't a DOI for it but there should be a way for me to know that. So DOIs for books and old journal articles are not really ready for prime time. From the standpoint of the "scientific name" part of a TNU/taxon concept, I had better luck (sort of). Rod's "Status of biodiversity services" page (http://www.bioguid.info/status/) was really cool. I saw resources I hadn't known about before. I tried out several of the services that claimed to issue LSIDs. Catalog of Life's LSIDs didn't work with either the http://www.bioguid.info/ or http://lsid.tdwg.org/ proxies with either a web browser or the OpenLink RDF browser. I only got an empty RDF element in response. Index Fungorum was down. IPNI seemed to work. However, I was somewhat appalled to observe that they seem to change the revision identifier any time that they change any part of the metadata. That renders the LSID useless as a permanent GUID for the name and I believe is inconsistent with the design of LSIDs where the revision is only supposed to change if the underlying data itself (NOT metadata) changes. (Catalog of Life says that they change the revision identifier EACH YEAR for all of their records! That's even worse!) If I'm remembering the TDWG LSID recommendations, it is not even recommended to use the revision part of an LSID at all in the biodiversity informatics context. ubio.org's LSIDs seemed to work properly. [sorry - didn't try zoobank since I was looking for plants] I don't know which (if any) of the Web sites listed on Rod's status page use generic HTTP URI guids (rather than LSIDs) to refer to taxon names. I tried out the Global Names index that Pete was mentioning. The URI version of the UUIDs (e.g. http://gni.globalnames.org/name_strings/3a70f04d-fd29-5570-ba91-52dae0c3d07f) do resolve under content negotiation, but the only useful information that the RDF representation seems to provide is the actual name string that was used to generate the UUID. Until some other useful linked information is added to the RDF, there doesn't seem to be much advantage in pointing a semantic client to the URI over just using a string literal for the name. So the bottom line is that of the LSID services for names that I've tried so far, only ubio.org seems to have LSIDs for names that are unchanging, can work as a proxied URI, and that produce actual useful RDF. That's pretty disappointing given the apparently huge amount of work that's been put into building these various systems. Steve -- Steven J. Baskauf, Ph.D., Senior Lecturer Vanderbilt University Dept. of Biological Sciences postal mail address: VU Station B 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) 343-6707 http://bioimages.vanderbilt.edu

5 14

More LOD on Linking to PDF's
by Peter DeVries 07 Jan '11

07 Jan '11

I should note that followed that Christopher Gutteridge <cjg(a)ecs.soton.ac.uk> followed that response with a note " *But that's me making a reasonable guess and getting on with it. The EPrints document is a URI which represents a conceptual document which consists of a number of actual files, eg. HTML+JPG+CSS, so the dct:hasPart makes sense there. The main issue is how to relate the document to the metadata record, and you rapidly decend into FRBR hell. Until a few people have consumed my data I consider it very much a work in progress! *" I will summarize the future messages on this thread. -- 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

Fwd: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?, existing predicate for linking to PDF?
by Peter DeVries 07 Jan '11

07 Jan '11

I thought that I would run the PDF question past the some lod experts. Here is the first reply - Pete ---------- Forwarded message ---------- From: Hugh Glaser <hg(a)ecs.soton.ac.uk> Date: Thu, Jan 6, 2011 at 2:44 PM Subject: Re: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?, existing predicate for linking to PDF? To: Peter DeVries <pete.devries(a)gmail.com> Cc: "<public-lod(a)w3.org>" <public-lod(a)w3.org> I see that Chris Gutteridge uses dc:hasPart for the ePrints RDF (eprints.org ). Eg: <http://eprints.ecs.soton.ac.uk/21681/> dc:format "text/html"; dc:title "HTML Summary of #21681 Consuming multiple linked data sources: Challenges and Experiences"; foaf:primaryTopic <http://eprints.ecs.soton.ac.uk/id/eprint/21681> . ... <http://eprints.ecs.soton.ac.uk/id/eprint/21681> ep:hasDocument <http://eprints.ecs.soton.ac.uk/id/document/36430>, ... <http://eprints.ecs.soton.ac.uk/id/document/36430> dct:hasPart < http://eprints.ecs.soton.ac.uk/21681/1/cold2010%2Dpaper16%2Dcamera%2Dready.… >; ... Cheers Hugh On 6 Jan 2011, at 19:40, Peter DeVries wrote: > I was wondering if there is an existing predicate for linking to a PDF file? > > I would like to incorporate a link between bibliographic reference description and a URL to the location of a PDF of that document. > > I had minted a predicate txn:hasPDFVersion, as demonstrated in this RDF snippet. (Part of http://lod.taxonconcept.org/ses/v6n7p.rdf ) > > <txn:SpeciesOriginalDescription rdf:about=" http://lod.taxonconcept.org/ses/v6n7p#OriginalDescription"> >  > <dcterms:title>Original Published Description relating to Species Concept Puma concolor se:v6n7p</dcterms:title> > <dcterms:identifier> http://lod.taxonconcept.org/ses/v6n7p#OriginalDescription </dcterms:identifier> > <dcterms:description>LOD metadata about the original species description relating to Species Concept Puma concolor se:v6n7p</dcterms:description> > <dcterms:isPartOf rdf:resource=" http://lod.taxonconcept.org/ses/v6n7p#Species"/> > <txn:hasAuthorURI rdf:resource=" http://dbpedia.org/resource/Carl_Linnaeus"/> > <txn:hasBasionymName>Felis concolor Linnaeus 1771</txn:hasBasionymName> > <txn:year>1771</txn:year> > <txn:hasPDFVersion rdf:resource=" http://assets.geospecies.org/spec_concept_uuid/603bebac-cc44-4168-bbf7-b11b… "/> > <txn:speciesOriginalDescriptionHasSpeciesConcept rdf:resource=" http://lod.taxonconcept.org/ses/v6n7p#Species"/> >  > <wdrs:describedBy rdf:resource=" http://lod.taxonconcept.org/ses/v6n7p.rdf"/> > </txn:SpeciesOriginalDescription> > > Some have suggested using rdfs:seeAlso to link to what could be a multimegabyte PDF, but I think this would cause problems for a number of RDF crawlers like Elmo. > > In summary, I think it would be useful to have a predicate that can be used for linking specifically to a PDF document. > > Is there an existing predicate for this? > > What do people think about the suggestion to use rdfs:seeAlso to link to a PDF? > > I would also like to know of others thoughts or suggestions regarding this issue, > > Respectfully, > > - Pete > > > > --------------------------------------------------------------- > Pete DeVries > Department of Entomology > University of Wisconsin - Madison > 445 Russell Laboratories > 1630 Linden Drive > Madison, WI 53706 > TaxonConcept Knowledge Base / GeoSpecies Knowledge Base > About the GeoSpecies Knowledge Base > ------------------------------------------------------------ -- Hugh Glaser, Intelligence, Agents, Multimedia School of Electronics and Computer Science, University of Southampton, Southampton SO17 1BJ Work: +44 23 8059 3670, Fax: +44 23 8059 3045 Mobile: +44 78 9422 3822, Home: +44 23 8061 5652 http://www.ecs.soton.ac.uk/~hg/ -- --------------------------------------------------------------- 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

Can all DwC be Simple DwC?
by joel sachs 06 Jan '11

06 Jan '11

It may be worth teasing out the boundary of what can/cannot be represented via simple (i.e. flat) Darwin Core. Auxilliary terms (which comprise the classes "MeasurementOrFact" and "ResourceRelationship") are currently left out of Simple Darwin Core. The DwC Terms Quick Reference Guide [1] states: "The terms found under the Auxiliary Terms section can only be meaningfully implemented in an application that supports relational structures". The Simple Darwin Core reference [2] explains "Every field in the Simple Darwin Core may appear either once or not at all in a single record - otherwise how could you distinguish one 'scientificName' field from another one?" Couldn't this be addressed using subscripts? E.g. MeasurementID_1="tail length" MeasurementID_2="brain volume" MeasurementUnit_1="cm" MeasurementUnit_2="cubic cm" MeasurementValue_1="9" MeasurementValue_2="8" (There is precedent for subscripting rdf properties: http://www.w3.org/TR/rdf-schema/#ch_containermembershipproperty) Allowing this would increase the types of data that can be exchanged via spreadsheet. It would also have the virtue of permitting a single DwC standard, which would help to lesssen confusion amongst potential adopters. (The existence of a "Simple Darwin Core" seems to imply that "regular Darwin Core" is not simple.) Are there reasons not to do this? Thanks - Joel. 1. http://rs.tdwg.org/dwc/terms/ 2. http://rs.tdwg.org/dwc/terms/simple/index.htm

3 4