Thanks Ashley,

It was people like yourselves that I was thinking of. (It might be a
good idea for us to get together and align what we are doing with MODS,
I'll get in touch when I'm back in the office next week.) It's
interesting to see that someone else thinks the Z39.50 holdings schema
is overkill for what they need in certain situations as well. Even if I
attempt to use the summary bibliographic holdings (level B2) it's not
clear where I should best put information for consistency e.g. our
shelfmarks are not union catalogue shelfmarks.

However, as I said before, I'm concerned that if we start using our own
local holdings schema in <extension> then we're going to lose overall
interoperability and have to start proliferating application profiles
with our users.

I know why using the Z39.50 holdings schema is recommended (to provide
for consistency and interoperability) but is there a requirement for
some simple holdings/locations elements within MODS itself to cater for
the simpler examples we have here? It would be great to hear from
someone who has managed to cater for similar situations within standard
MODS, because I know I may very well be missing something obvious!

Thanks again,


-----Original Message-----
From: Ashley Sanders [mailto:[log in to unmask]] 
Sent: 23 March 2006 11:07
To: Metadata Object Description Schema List
Cc: Ashton, Jan
Subject: Re: [MODS] Journal holdings not using <extension>?

Hi Jan,

> I am working on a MARC to MODS mapping for one of our journal files. 
> Each journal record may contain holdings information from the 852 and 
> from local holdings fields as below:
> ISI Bulletin
> Location: British Library
> Sub-collection: DSC
> Shelfmark: 4582.950000
> Holdings: Vol.1, 1949- 39(2), 1987
> Location: British Library
> Sub-collection: STI
> Shelfmark: (P)BY40-E(1)
> Holdings: Vol.5, 1953-8, 1956; 1962-39(3), 1987
> Is my only (or best) way to handle this in MODS to use an <extension> 
> holdings schema? I have some concerns about interoperability issues if

> I use the <extension> element. For example, I know that in the UK, 
> another consortium is developing its own local holdings extensions 
> while the example in the MODS Guidelines is for the Z39.50 XML 
> Holdings schema (which may be overly complex for these simple holdings
summaries anyway).
> So I've been looking at using <location> and <physicalLocation> as 
> elements for Location/Sub-collection and Shelfmark but am having 
> problems linking the relevant holdings to the right location using 
> <physicalDescription> <extent>.

We have the same issue. What we are currently doing (though it's not
quite yet too late to change) is using our own schema in the extension
element. A simple holdings statement goes something like this:

  <cpc:lhi libCode="Abc" libName="Aybesee" crn="01234567890">
     <cpc:branchLoc code="STRM">Store room</cpc:branchLoc>
     <cpc:classmark>HN740.Z9.S6 M54</cpc:classmark>
   <cpc:localNote>Some local note would go here</cpc:localNote>

Which satisfies our basic requirements. The attributes in the first line
contain stuff very specific to CURL/Copac.
There are other tags (not shown above) for enum & chrons and for textual
holdings statements.

It would be nice to be interoperable (especially as we have your records
on Copac.) I'm afraid the Z39.50 XML Holdings Schema had passed me by.
Do many people use it? (Having had a quick look at it, it seems overly
complex for what we need.)

 > 1. Are my concerns about interoperability and the use of the  >
<extension> element too great?

I wish I knew the answer to that.


Ashley Sanders [log in to unmask] Copac -- A
MIMAS service funded by JISC

Experience the British Library online at
Help the British Library conserve the world's knowledge. Adopt a Book.
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 [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.