- tdwg-content - lists.tdwg.org

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

GUIDs for publications (usages and names)
by Steve Baskauf 06 Jan '11

06 Jan '11

I was reviewing some of the previous posts on taxon name usages in an attempt to understand them better. I have learned that the Global Names Index is an attempt to catalog taxon names and that it is possible to generate a URI that points to a name there. Is there a parallel effort to do the same thing for literature references? In other words, if I want to describe the TNU: Andropogon virginicus L. sec. Radford et al. (1968) I think I could find a URI GUID for the name Andropogon virginicus . But is there some place where I could find a unique identifier, or better a URL, or best a URI providing RDF/XML for Linnaeus 1753 (the author and publication for the name) and for Radford et al.1968 (the author and publication that expresses the usage I'm intending). I suppose that this question has previously been answered in the in the many posts on taxon names, concepts, etc. However, since usually my brain goes numb and my eyes glaze over in those threads, I probably missed it. 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

8 26