Tony Hammond wrote:
>
> A question from the STM world: To generate useful metadata for
> journal articles I would really like to embed complete bibliographic
> citation data into self-contained DC records in a structured fashion.
> No problem with certain fields (<title>, <creator>, <date>,
> <publisher>, etc.). What I am missing is a means of including journal
> title, volume, issue, page number(s?).
If the metadata set is for the print version, I think this
information would all belong in <identifier> (ie the
identifier of the resource being described). I guess you'd
like to substructure this a bit to handle volume, etc, but
so far that level of qualification is still being worked
out in DC. It will probably end up by "borrowing" a scheme
from another authority (at least I hope it doesn't re-invent one!)
*** DC.Identifier does NOT have to contain a URL ***
(until physical objects have URL's, at least ...) -
it could be a DDC, ISBN or ISSN for print material,
a SSN or TFN* for people, a street-address for a building, etc, etc.
(*TFN - there's one to test you all).
> Considering the case of an electronic (online) resource derived
> from a print resource I can use a URL (URN, or whatever) in the
> <identifier> field for the networked resource. This then leaves me
> with the <source> field to squirrel away those data associated with
> the legacy print object: title, volume, issue, page number. One means
> of accomplishing this (but is this the only means?) would be to use a
> SICI which has relevant compartments for each of these subfields. But
> the SICI only records the ISSN and not the title. Is there any
> sensible way of including this data into my DC record? Or should I
> use repeated fields, such as
>
> <source>Journal Title (free text)
> <source>SICI code
I think that the preferred version coming out of the DC-5
discussions would have Source using the same syntax as
the basic elements but with qualified source element names, eg
<source.identifier>JournalTitle, Volume#, Page#, ...</source.identifier>
<source.creator>the original author</source.creator>
If you want unqualified DC, the information about each source
will all have to go in the one element.
Of course if there are 2 sources, then you'll repeat, but the
precise ways of clustering related elements have not been
worked out (and currently, it is explicit there there is zero
significance to sequencing).
> Also what about
> secondary data that I might want to include such as journal title
> abbreviation (say), journal code, or private identifiers?
Bundle it all into <identifier>
> Second question: <relation>. Is this envisaged as carrying the
> object's parent or a sibling?
I think either, and more. So far we only identified that
there will be a group of Relation types that are all generally
about "collections" which are the "isPartOf" and "hasPart"
variety which does not appear to include siblings. It is
perhaps easier this way - create one overall
DC set for the collection, and let all the components
then identify themselves as belonging to it. But perhaps
the need for "next|previous in series" pointers will become
compelling ...
--
__________________________________________________
Dr Simon Cox - Australian Geodynamics Cooperative Research Centre
CSIRO Exploration & Mining, PO Box 437, Nedlands, WA 6009 Australia
T: +61 8 9389 8421 F: +61 8 9389 1906 [log in to unmask]
http://www.ned.dem.csiro.au/SimonCox/
|