FW: [TaxonLit] Re: Journal Series
Jerry Cooper
I assume journal series data is not to be confused with the category of serial publication? i.e. one that may appear at irregular intervals and usually (but not always) has single author issues, and often associated with journals as a supplementary addition, for example Beihefte Nova Hedwigia (serial) and Nova hedwigia (Journal), Beihefte Sydowia (serial) and Sydowia (journal), Kew Bulletin Miscellaneous series (serial) and Kew Bulletin (Journal), Memoirs of the New York Botanic garden (stand alone serial), Arkiv fur Botanik (stand alone serial), Opera Botanica (stand alone serial) etc.
That's not the same category as 'Proceeding of the Royal Society of ..., series A', is it?
And these not to be confused with series(volumes) of books under a common title, e.g. Fungi of New Zealand, volume 1, author1, volume 2, author 2 etc.
The worst 'books under a common title' case I've come across are early publications like Hooker's 'Botany of the Antarctic Voyage ...' which has a multi-layer title/author/part hierarchy that is difficult to disentangle and doesn't sit happily in any finite enumerated title/subtitle/sub-subtitle ... set of fields
Many pre-date ISSN/ISBN so you can't categorise using the publisher's own decision.
Librarians frequently struggle with the categorisation of journals, serial publication and books in a series - as evidenced by most library catalogues I've ever looked at.
And I'll also add a regular comment from Paul Kirk aimed at those who digitise bibliographic data (Paul is suspiciously quiet on this list?!)
'Part' information is often considered by librarians to be of use (and therefore worth capturing) when volumes are left unbound on the stack. If they are bound then 'part' information is considered superfluous. Which is OK except there are some journals that reset pagination between parts! I categorise these anomalies as serial publications and not journals.
I trust this potential structural complexity will be captured adequately for matching/disambiguation and data exchange.
Jerry
-----Original Message-----
From: taxo...@googlegroups.com [mailto:taxo...@googlegroups.com] On Behalf Of Richard Pyle
Sent: Tuesday, 17 November 2009 12:45 p.m.
To: 'Taxonomic Literature'
Subject: [TaxonLit] Re: Journal Series
Thanks, Rod. I think most agree that each series represents a separate
journal, worthy of its own unique identifier. I think it's outside the
scope of the exchange standard to map all the different related journals
together. In the example you gave, I see the following:
GUID: 1
Title: Royal Entomological Society of London. Proceedings of the
Entomological Society of London
Series:
ISSN (Print): 1472-0949
ISSN (Online):
GUID: 2
Title: Proceedings of the Royal Entomological Society of London
Series:
ISSN (Print): 1472-0981
ISSN (Online):
GUID: 3
Title: Proceedings of the Royal Entomological Society of London
Series: Series A, General entomology
ISSN (Print): 0375-0418
ISSN (Online):
GUID: 4
Title: Proceedings of the Royal Entomological Society of London
Series: Series B, Taxonomy
ISSN (Print): 0375-0434
ISSN (Online):
GUID: 5
Title: Proceedings of the Royal Entomological Society of London
Series: Series C, Journal of meetings
ISSN (Print): 1946-1496
ISSN (Online): 1946-150X
GUID: 6
Title: Journal of Entomology
Series: Series A, General entomology
ISSN (Print): 0047-2409
ISSN (Online):
GUID: 7
Title: Journal of Entomology
Series: Series B, Taxonomy
ISSN (Print): 0047-2417
ISSN (Online):
GUID: 8
Title: Proceedings of the Royal Entomological Society of London. Journal of
meetings
Series:
ISSN (Print): 0080-4355
ISSN (Online):
GUID: 9
Title: Journal of Entomology
Series: Series A: Physiology & behaviour
ISSN (Print): 0308-5007
ISSN (Online):
GUID: 10
Title: Physiological Entomology
Series:
ISSN (Print): 0307-6962
ISSN (Online):
GUID: 11
Title: Antenna
Series:
ISSN (Print): 0140-1890
ISSN (Online):
As shown above, "Series" is captured as a separate element from "Title".
Are there examples of other journals where it's not appropriate to include
the series label as a separate element? (i.e., where it is appropriate to
treat it as part of the journal title?)
Another question that we need to decide amongst ourselves is whether in the
example of GUID: 5 above wheter this should be treated as one uniquely
identified journal (as seems to be implied by the diagram at the website),
or whether it should really be counted as two (one for print, and one for
online).
Here my gut feeling is the same as what seems to be rendered in the diagram:
it's one journal with two different ISSNs representing the two different
forms in which the same cited reference it is published. But I could be
persuaded to treat them as two separate records (with two separate GUIDs),
which would allow us to, for example, track Code-governed nomenclatural Acts
directly to the print version. On the other hand, if we can reliably assume
in such cases that the two versions are identical in terms of information
content, then it would be a bit cumbersome to have to double-up on all
citation records (not to mention Name-Usage records in GNUB) for every
journal that publishes a separate print & electronic version (with separate
ISSNs). I doubt that anyone would indicate which of the two versions
they're spcifically citing in a bibliography of a published paper; so it
seems that they represent the "same" citation (in the same way that reprints
have been historically treated as the "same" citation as the originally
published form).
Lots of stuff to think about!
Aloha,
Rich
> -----Original Message-----
> From: taxo...@googlegroups.com
> [mailto:taxo...@googlegroups.com] On Behalf Of Rod Page
> Sent: Monday, November 16, 2009 4:58 AM
> To: Taxonomic Literature
> Subject: [TaxonLit] Re: Journal Series
>
>
> Series need not always be parts of journals. Series may be
> different journals (or at least be treated as such by some
> databases). For example, take a look at
>
> http://worldcat.org/xissn/titlehistory?issn=0375-0434
>
> Decisions about whether series belongs in a separate field or
> as part of the contents of the title field could based (at
> least in part) on whether the series have distinct ISSNs (or
> other identifiers, such as OCLC numbers).
>
> Regards
>
> Rod
>
>
> On Nov 16, 3:06 am, saut...@ira.uka.de wrote:
> > Hi Rich,
> >
> > >> The appropriate model for storing the series designator separate
> > >> from the journal title would be making the former an
> attribute of
> > >> the latter.
> > >> This way, we have a clear relationship between the two in the
> > >> presence of multiple titles.
> >
> > > Wouldn't it be better to have the Element contain the full
> > > concatenated title (with Series, etc.), then have attributes for
> > > things like "periodicalTitle" (for the non-series part)
> and something like "seriesLabel"
> > > for the series bit?
> >
> > Good point ... putting the plain data in the textual
> content and the
> > parsed data in one or more attributes generally seems to be a good
> > guideline. This allows for a clear one-to-one association
> between raw
> > and normalized data without having to use container elements. Sorry
> > for not thinking of this one earlier.
> >
> >
> >
> >
> >
> >
> >
> > > Or, maybe a structure something like:
> >
> > > <ReferenceTitles>
> > > <ReferenceTitle kindOfTitle="StandardTitle" title="Annals and
> > > Magazine of Natural History, Series 9">
> > > <PeriodicalTitle>Annals and Magazine of Natural
> > > History</PeriodicalTitle>
> > > <SeriesLabel>Series 9</SeriesLabel>
> > > </ReferenceTitle>
> > > <ReferenceTitle kindOfTitle="AbbreviatedTitle"
> title="Ann. Mag. Nat.
> > > Hist., Ser. 9">
> > > <PeriodicalTitle>Ann. Mag. Nat. Hist.</PeriodicalTitle>
> > > <SeriesLabel>Ser. 9</SeriesLabel>
> > > </ReferenceTitle>
> > > </ReferenceTitles>
> >
> > Not so fund of this one, like the other variant better.
> >
> > - Guido
> >
>
Please consider the environment before printing this email
Warning: This electronic message together with any attachments is confidential. If you receive it in error: (i) you must not read, use, disclose, copy or retain it; (ii) please contact the sender immediately by reply email and then delete the emails.
The views expressed in this email may not be those of Landcare Research New Zealand Limited. http://www.landcareresearch.co.nz
Roderic Page
complexities of publication. Is this really what we need? For my
(possibly atypical) purposes, I'd like:
1. identifier that enable me to link a publication identifier to, say
a name identifier (e.g., uBio LSID to DOI)
2. Services that can take a citation (be it book, journal, article,
page) and map it to an identifier (DOI, Handle, URL, BHL PageID,
PubMed, etc)
I personally don't really care what the actual citation is (book,
serial publication, article, etc.), I just want the ability to
discover that, for example, two references (one may be an article, the
other may be a page in an article) are the same thing.
In a digital world everything boils down to resolvable identifiers,
unless we want to get stuck in the mire of bibliographic modelling,
can't we strive for something simple? Otherwise we're heading towards http://www.loc.gov/cds/FRBR.html
, and that way lie madness.
Regards
Rod
Roderic Page
Professor of Taxonomy
DEEB, FBLS
Graham Kerr Building
University of Glasgow
Glasgow G12 8QQ, UK
Email: r.p...@bio.gla.ac.uk
Tel: +44 141 330 4778
Fax: +44 141 330 2792
AIM: rodpa...@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
Richard Pyle
> the hideous complexities of publication. Is this really what
> we need?
No, it's absolutely not what we need. We want to keep it simple, yet allow
us to communicate the information that our community needs. In my mind, the
primary objectives are:
1) Define a set of citation metadata elements that uniquely identify a
specific "Reference" (mostly publications/literature, but not strictly
restricted to those things), and map them to reusable GUIDs covering the
entire scope of our community's needs (things like DOIs and ISSNs will not
really work for these GUIDs, because they do not cover all historical
literature, they do not apply to many unpublished reference sources we want
to track, and they don't resolve at the granularity of individual
treatments).
2) Extend the level of resolution of what items we uniquely identify beyond
what the library community normally deals with (e.g., to include
microcitations/taxon treatments).
3) Extend the scope of metadata to include things that are important to our
community, but not necessarily dealt with well by the library community
(especially concerning authors & dates).
Of secondary importance, but still worth considering in our community:
4) Implementation of a clear hierarchy of cited items (Treatments contained
within Articles, contained within journals; etc.)
5) Conveyance of metadata useful for formatting purposes (such as some sort
of markup within titles, as we have been discussing)
> For my (possibly atypical) purposes, I'd like:
>
> 1. identifier that enable me to link a publication identifier
> to, say a name identifier (e.g., uBio LSID to DOI)
>
> 2. Services that can take a citation (be it book, journal, article,
> page) and map it to an identifier (DOI, Handle, URL, BHL
> PageID, PubMed, etc)
>
> I personally don't really care what the actual citation is
> (book, serial publication, article, etc.), I just want the
> ability to discover that, for example, two references (one
> may be an article, the other may be a page in an article) are
> the same thing.
Agreed on all points.
> In a digital world everything boils down to resolvable
> identifiers, unless we want to get stuck in the mire of
> bibliographic modelling, can't we strive for something
> simple? Otherwise we're heading towards
> http://www.loc.gov/cds/FRBR.html
> , and that way lie madness.
Yes, simple is good; and I think the general philosophy is "stackable
complexity" (a term I invented just now). In other words, at the very
simplest you have can just have one blob of unparsed text purported to
represent a citation (think GNI namestring). At the next tier, there would
be the major blobs of text separated (e.g., Authorship, Title, Date,
PublishedIn, CitationNumbers, Pagination). Then each of these could be
further parsed into more specific details. So, no matter how parsed or
unparsed the source content is, it can be represented. But as you say, we
don't want to go nuts either -- just far enough to meet the objectives
listed at the top of this email.
There will be a few areas we'll need to think through carefully, such as the
enumerated list of RefereneTypes (aka: KindOfReference). More on this
(thorny) topic later.
Rich