---------------------- Forwarded by Cliff Morgan/Chichester/Wiley on
07/08/98 14:41 ---------------------------
Cliff Morgan
07/08/98 14:30
To: [log in to unmask]
cc:
Subject: RE: Version of actual doc. - Title or relation? (Document link
not converted)
You add "page" to the discussion, which is new, but considering
enumeration (e.g., volume or issue) as part of the title does have
significant history and widespread use, at least among the library
community.
>>(CM): Let's think about metadata for a journal article. DC.Title in this
metadata set would be the title of the article - I would contend that
Volume, Issue etc. doesn't belong here.
>>(CM): I'm assuming that we can attach metadata at all sorts of levels, so
you might have the metadata for an article, the metadata for an issue
(where DC.Title was the title of that issue, e.g. a special issue), the
metadata for a volume (which wouldn't normally have a title) and the
metadata for a journal (where DC.Title is the title of the journal).
>>(CM): Another interesting piece of metadata for journals is the cover
date. Now, the cover date is not really a date in the DC.Date sense of the
term because it doesn't actually identify the date when anything actually
happened - all it really identifies is the issue: it's an issue attribute,
not a date. For example, the January issue of a monthly journal may be
published (i.e. released to the world) in the previous November or
December, or in January itself, or as late as you can possibly imagine. No
matter when it's published, it will still be known as (identified as) the
January issue. So where would this information best go in Dublin Core? Not,
I think, in DC.date (where you would want to put things like receipt,
modification, published, updated, etc. dates), but where? Another case for
a local extension (STM.CoverDate?)?
>>(CM): I was alarmed to see fairly recently a suggestion that, if all else
fails, stick your metadata into DC.Description. I wouldn't like to see this
as some big bucket.
It occured to me recently that capturing such information in a
> structured way might be done by using SICIs (Serial Item and
> Contribution Identifier), and then using this SICI as the (or one of
> several) dc:Identifier values.
[Jul,Erik]
Wouldn't this depend upon the assignement of a SICI? What if one does
not exist? Is this methods mutually exclusive of alternative
expressions (i.e., "volume" or "number")?
>>(CM): This is an interesting point. Wiley tends to be more
pro-SICI than most. All of our journal articles have SICIs at both the
article and abstract
level, but many of the other large STM publishers have not assigned SICIs
to this degree,
preferring often to use PIIs (Publisher Item Identifiers) instead. (These
are about half the
length of SICIs and do not contain chronology, enumeration or location
information such as
Cover date, Volume, Issue, Page - they are specifically designed to be
assignable at the
earliest stage in production, before an article has been allocated to an
issue.) SICIs aren't
really in such widespread use as might be imagined.
>>(CM): It is, though, possible to assign a SICI independently to any
article as long as you
have the ISSN, Cover date, Volume, Issue, Page (first page number only: the
SICI won't give
you a page range) and article title (although the Title Code has some
pitfalls for the
unwary). You also need the algorithm for the check character, but the SICI
was designed to be
derivable from any article that you had in hand, and quite a bit of it can
be derived from a
standard citation to an article.
>>(CM): I don't think you can rely on the SICI as anything more than
DC.Identifier: it doesn't quite give you everything you need if you want to
express an article as being on
these pages in this issue in this volume of this journal.
>>Cliff Morgan
>>Publishing Technologies Director
>>John Wiley & Sons Ltd
>>Chichester, UK
|