[tdwg-guid] TDWG LSID Resolver broken?

Richard Pyle deepreef at bishopmuseum.org
Fri Nov 30 02:19:30 CET 2007


Hi Rod,

> I'm not quit sure I understand "flattened". If you are asking 
> whether the entire citation should be written as one string, e.g.
> 
> Baldwin, C. C. and W. L. Smith (1998). Belonoperca pylei , a 
> new species of seabass (Teleostei: Serranidae: Epinephelinae:  
> Diploprionini) from the cook islands with comments on 
> relationships among diploprionins. Ichthyological Research 
> 45(4):325-339.

No -- what I meant was, should the complete tree of "parent" citations be
"flattened" into the parentCitationString content (aka
parentPublicationString:
http://rs.tdwg.org/ontology/voc/PublicationCitation#parentPublicationString)
; or should there be some recusive nesting of each parent "level" on up the
tree.

In the case of a journal article, there's really only one parent level: the
Journal name -- so in this case the parentCitationString would flatten out
to just the journal name.  However, for a chapter in an edited book in a
book series, there would be potentially two levels of "parent" (and other
scenarios could have more levels).  The more I think about this, the more I
think that all parent levels (not all fields of this one citation) should be
included in the parentCitationString element -- not just the immediate
parent.  And depending on the nature of the "parent", there might be several
concatenated attributes.  For example, for this citation:

Pyle, R.L. 2002. Pomacanthidae. pp. 3266-3286. In: Carpenter, K.E. and V.E.
Niem (Eds.) Living marine resources of the western central Pacific.  Volume
5.  Bony fishes part 3 (Menidae to Pomacentridae). Food and Agriculture
Organization of the United Nations (FAO), Rome. i-iv+2791-3379.

...there are at least three "levels" of publication:

1) Pyle, R.L. 2002. Pomacanthidae. pp. 3266-3286.

2) Carpenter, K.E. and V.E. Niem (Eds.) Living marine resources of the
western central Pacific.  Volume 5.  Bony fishes part 3 (Menidae to
Pomacentridae). Food and Agriculture Organization of the United Nations
(FAO), Rome. i-iv+2791-3379.

3) Carpenter, K.E. and V.E. Niem (Eds.) FAO species identification guide for
fishery purposes: Living marine resources of the western central Pacific.
Vols. 1-6. Food and Agriculture Organization of the United Nations (FAO),
Rome. xl+4218 pp.

Granted, some might argue that number 3 is not really a separate citable
"unit", but given that it is a single page number series, I would argue that
it is.

So...if we wanted to cite specifically Pyle 2002, the parentCitationString
might simply be the contents of of #2 above; or it might have two nested
parents (a parent, and agrand parent).

As I said before, I'm leaning towards the simpler solution.

> By all means have this as an additional element, but keep the 
> individual bibliographic elements (volume, issue, pagination, 
> etc) separate. This greatly simplifies the task of anybody 
> trying to find the reference, or assign a GUID.

Yes, absolutely!!!  I was only talking about how to handle the "parent" (and
grandparent, and so on).

> If by flat you mean that the journal information is a link to 
> another LSID for the journal, rather than containing a string 
> for the journal name, to me it seems needlessly complex not 
> to include the journal name in the RDF that has the rest of 
> the bibliographic information (that is, as well as any link 
> to the journal). 

I agree, but I think you ought to have both -- and the draft vocabulary
includes elements for both (currenty called "parentPublication", and
"parentPublicationString" -- but should be "parentCitation" and
"parentCitationString").  My main failure is that I didn't populate the
latter in the LSID resolver service -- which I will fix now.

> The ISSN is already included, which applies 
> to the journal not the article, so if the idea was to cleanly 
> separate articles from containing journals, then the model 
> has already failed to do that.

No -- the idea was to come up with a generic solution to hierarchically
structured publication citations.  "Journal" is not often thought of as a
"parent" to an article (more as a separate attribute).  But from a database
perspective, it's clener to think of a "journal" as a "parentCitation".

> Lastly, I'm sure I missed the discussion, but I don't see why 
> the RDF at 
> http://rs.tdwg.org/ontology/voc/PublicationCitation has it's 
> own vocabulary, rather than using existing vocabularies such 
> as Dublin Core (see 
> http://dublincore.org/documents/dc-citation-guidelines/)
> and PRISM. Another aspect of integration is sharing 
> vocabulary as well as GUIDs.
> 
> Compare
> 
> http://nsdb.bishopmuseum.org/authority/metadata/? 
> lsid=urn:lsid:bishopmuseum.org:tnu:20889795-7EC7-42F3-A4C3-D1D
97704A609
> 
> with
> 
> http://www.connotea.org/rss/uri/876ae25827e2e94426845b277686efca
> 
> Wonder which one is more likely to be integrated into other 
> databases...?

Fair point, and there was a recent meeting in St. Louis (which I attended
virtually) to hammer out a replacement to what's on the LSID Vocabulary
site. There was broad agreement (as I recall) that we (biodiversity folks in
general) should emulate the library community whenever possible, but that we
had special needs based on how we tend to cite publications in our
bibliographies and taxonomic accounts.

As for the ZooBank LSID resolver -- at this point in time conformance trumps
optimization (so we can all get off our collective arses and serve content)
-- so I'm just woking with what's up there now.  If I'm resolving LSIDs, and
I'm doing so because of TDWG standards, then I ought to conform to existing
TDWG standards on vocabularies -- right or wrong.  What we need to do is
update the TDWG standards on this (which the St. Lousi meeting was
attempting to accomplish), so we can conform *and* optimize!

Aloha,
Rich





More information about the tdwg-tag mailing list