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