Wolfram,
We have a similar situation in the British Library with eJournal
articles where we work down from the parent/host to the individual
issues or articles. We have journal title level metadata with issue
level metadata and article level metadata. We use identifiers in the
relatedItem elements pointing to the internal identifier at the higher
level. For example, at the article level for resource discovery we plan
to include identification/citation type metadata e.g.
<mods:relatedItem type="host" displayLabel="Journal">
<identifier type="MMC-ID"> MMCID.12345 </identifier>
<mods:identifier type="issn">0098-6569</mods:identifier>
<mods:titleInfo>
<mods:title>International Journal of Urban and Regional
Research</mods:title>
</titleInfo>
<part type="article">
<detail type="volume">
<number>24</number>
<caption>vol.</caption>
</detail>
<detail type="number">
<number>1</number>
<caption>no.</caption>
</detail>
<detail type="articleNumber">
<number>4</number>
</detail>
<extent unit="ingestedPages">
<start>389</start>
<end>393</end>
<total>5</total>
</extent>
<extent unit="actualPages">
<total>4</total>
</extent>
</part>
</relatedItem>
</mods>
Our METS AP states "The journal object is ingested before the issue
object, which in turn needs to be ingested before its articles. Within
the MODS metadata the issue object points to the associated journal
title object. Metadata at the parent level is not fully recorded within
the children's MODS record. At ingest, the archive system checks for the
entity's availability in the digital storage System and will only ingest
the associated issue, if the entity had already been successfully
ingested. The <mods:relatedItem> element is used to record this
relationship. The type-attribute must contain the value "host". The
value of this element is the unique identifier of the parent entity.
Note: whenever a <mods:relatedItem> element is used, an appropriate
<mods:part> element must be used as well to record the position of the
current mets <div> within all its siblings."
I have forwarded your message to my colleague Markus Enders who is our
METS expert.
Best wishes,
Jan
Bibliographic Development
T +44 (0) 1937 546603
[log in to unmask]
The British Library
Boston Spa
WETHERBY
West Yorkshire
LS23 7BQ
www.bl.uk
-----Original Message-----
From: Metadata Object Description Schema List [mailto:[log in to unmask]] On
Behalf Of Wolfram Zieger
Sent: 04 November 2009 11:27
To: [log in to unmask]
Subject: [MODS] outsource related host infos with identifier?
Hello dear MODS experts community,
this is my first post to this list - and I hope the topic I am going to
raise was not discussed before. It is a bit hard to search for this in
terms of a proper search term - so maybe I missed it.
So instead of answering directly to this post I would also appreciate
it, if you just point me to a already "fought through" thread within
this list, dealing with my concerns...
Ok - let's start.
Here at the Kunst Historisches Institut in Florence, Italy, we are about
to do a project involving METS and MODS for cataloging rare "arty"
newspapers from the beginning of the last century. I feel a bit
responsible for this - so I am the one who is doing an example
implementation of one newspaper in METS using wrapped MODS elements for
article descriptions. You may think - ok, that's METS stuff - but no -
my question is indeed related to a special
(wrapped) MODS issue I have.
I will show the (reduced for here) structure below for a deeper look -
but the problem can be easily outlined like this:
The main idea is to have a METS:dmdSec for every single article which is
completely done with wrapped in MODS elements (that is, because I like
to use the fabulous METS:structMap Feature to do different approaches to
the content). But to show the relation of those single articles to the
"hosting"
newspaper I've got to show the "related host" within every Article
again.
Doing it the other way around (starting with the newspaper itself and
then coming up with every single article as related items, which sounds
more logical at first) would not allow to link to the articles from the
METS StructureMap, because within METS I need METS IDs, not wrapped in
MODS IDs (at least if I want to do it in a "clean" way). This way I
would only have the whole Newspaper itself for the METS Structure Map -
so it would make no sense to use this structure map at all. Correct me,
if I am wrong here - but I am pretty sure that this is, how things work
(or not work in my case).
So - having the newspaper itself as a relatedItem type="host" within
every article descriptions leads to some kind of heavyweight XML
structures. I wonder - and this is actually my questions - if I could
shorten this by using <identifier> TAGs pointing to a single MODS file
containing only the newspaper description? I wonder what to do then with
the <part> elements showing the pages the article spans over. This
mods:extent unit="pages"
thing belongs under the related host I want to outsource - but the
mods:extent unit="pages" TAG is different for (almost) any article. Is
this still a valid MODS-XML format if I am doing this (just appending
the <part> section below the <ident>referrer)?
To give you a less theoretical view, here comes the MODS structure so
far itself (and afterwards what I want to do, wondering if it's valid
this way):
The <mods:*> syntax is because of the "wrapped within METS"-nature. And:
I'll do comments in "//" for the mailing list because I don't want to
irritate your browser/mailviewer with those html-tagged comments.
Sorry - I can't do proper indenting from within the web pages mailing
list interface...
<mods:mods>
// an article oft the newspaper starts here <mods:titleInfo>
[...]
</mods:titleInfo>
<mods:genre>open letter</mods:genre>
<mods:name>
[...]
</mods:name>
<mods:subject>
[...]
</mods:subject>
<mods:typeOfResource>text</mods:typeOfResource>
// --- The "hosting" newspaper is coming up here ---
<mods:relatedItem type="host">
<mods:titleInfo>
[...]
</mods:titleInfo>
<mods:name>
[...]
</mods:name>
<mods:originInfo>
[...]
</mods:originInfo>
<mods:genre authority="marcgt">newspaper</mods:genre>
<mods:identifier type="local" displayLabel="KHI Futurismus Projekt">
[...]
</mods:identifier>
<mods:physicalDescription>
[...]
</mods:physicalDescription>
// All the <relatedItem> parts above are fix. They don't change per
article. But the following details change with (almost) every article.
So this <part> section is the (only) variable part of the relatedItem:
<mods:part>
[...]
</mods:part>
</mods:relatedItem>
</mods:mods>
That was the structure so far. What I want to do now is this:
<mods:mods>
// an article oft the newspaper starts here
<mods:titleInfo>
[...]
</mods:titleInfo>
[...]
// The "hosting" newspaper is coming up here
<mods:relatedItem type="host">
<identifier type="uri">some reference to the MODS xml containing
anything
but the part info</identifier>
// The following details change with (almost) every article. So this
<part> section is the (only) variable part of the relatedItem:
<mods:part>
[...]
</mods:part>
</mods:relatedItem>
</mods:mods>
What I want to do is to stay strictly within the METS/MODS specs. So
would
this idea fulfill those requirements? Or am I completely on a wrong
track?
Should I perhaps put the newspaper into its own METS:dmdSEC wrapped MODS
part and refer to this? Refering from a wrapped MOD to a METS:Object
(even
when it only contains a wrapped MODS-Description)?
I would really appreciate it, if one of you MODS-experts could enlighten
me
here!
Thanks a lot in advance, with best regards
Wolfram Zieger, Florence
PS: I will attach the same messages in it's original format again - in
case
the indenting was messed up.
**************************************************************************
Experience the British Library online at http://www.bl.uk/
The British Library’s new interactive Annual Report and Accounts 2008/09 : http://www.bl.uk/knowledge
Help the British Library conserve the world's knowledge. Adopt a Book. http://www.bl.uk/adoptabook
The Library's St Pancras site is WiFi - enabled
*************************************************************************
The information contained in this e-mail is confidential and may be legally privileged. It is intended for the addressee(s) only. If you are not the intended recipient, please delete this e-mail and notify the mailto:[log in to unmask] : The contents of this e-mail must not be disclosed or copied without the sender's consent.
The statements and opinions expressed in this message are those of the author and do not necessarily reflect those of the British Library. The British Library does not take any responsibility for the views of the author.
*************************************************************************
|