ILS-DI item and holding information
Walker, David
As I mentioned on code4lib, I'm converting a PHP class I wrote that screen-scrapes Innovative catalogs to match the DLF ILS-DI tech recommendations.
My first question (kinda long, sorry) has to do with the apparent difference between how 'GetAvailability' and 'GetRecords' treat item and holding information.
The spec says that 'GetAvailability' should return a list of 'item availability objects'. Cool. But then 'GetRecords' and 'Search' say that I should include holdings and item information together with the bibliographic record in the specified schema. Is that right?
So, if the calling code invoking 'GetRecords' or 'Search' specifies the schema as MARC-XML, for example, should I include item and holding information in the bibliographic record, like in an 852 (or similar) field? Or should that data be separate from the bibliographic record, but also in MARC-XML?
The spec says that I should include item and holdings information 'unless the specified return schema does not support it'. But then section 6.4.2 and Appendices 2 and 3 show examples where holdings and item information are in a different schema altogether from the bib record, like NCIP or ISO holdings.
It seems to me that 'GetRecords' and 'Search' should return a list of Record objects that would contain, say, three properties: (a) the bibliographic record, (b) an array of item availability objects, and (c) an array of (not defined in the recommendation) holdings objects. The 'schema' parameter, then, should *only* apply to the bibliographic record.
It would then be up to the calling code to convert the item availability and holding objects into the appropriate XML schema (e.g., ISO Holding or NCIP), situating them together with the bib record using the <dlf: /> wrapper elements, should the calling code be implementing a web service.
That would make those functions behave more like 'GetAvailability', I think.
Or am I just misunderstanding this?
--Dave
==================
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu
Godmar Back
bibliographic records.
They'll go under dlf:record/dlf:items and use ISO holdings format.
In addition, the dlf:simpleavailability child provides a summary of
the availability status of the items.
See the earlier thread (-> mailing list archives) regarding why our
current thinking discourages Marc 852 use.
- Godmar
Tim McGeary
Tim
--
Tim McGeary
Senior Systems Specialist
Lehigh University
tim.m...@lehigh.edu
610-758-4998
timmc...@gmail.com
Google Talk: timmcgeary
Yahoo IM: timmcgeary
Walker, David
For me the question is not so much whether the item and holdings information should be in the bibliographic record or not -- I may have derailed you in that example -- but rather what the 'schema' parameter in 'GetRecords' and 'Search' is meant to define.
The documentation seems to indicate that the schema parameter in those functions applies to *both* the bibliographic record and items/holdings data. But that doesn't seem right, since other parts of the documentation clearly show that bib and item records can (and in most cases likely will) be in two different schemas.
I guess what I'm saying is that either I or the documentation is confused on this point -- likely the former. ;-)
--Dave
==================
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu
From: jangle-...@googlegroups.com [jangle-...@googlegroups.com] On Behalf Of Godmar Back [god...@gmail.com]
Sent: Friday, July 18, 2008 10:03 AM
To: jangle-...@googlegroups.com
Subject: [jangle-discuss] Re: ILS-DI item and holding information
Tim McGeary
Tim
--
Tim McGeary
Senior Systems Specialist
Lehigh University
tim.m...@lehigh.edu
610-758-4998
timmc...@gmail.com
Google Talk: timmcgeary
Yahoo IM: timmcgeary
Tim McGeary
Tim
--
Tim McGeary
Senior Systems Specialist
Lehigh University
tim.m...@lehigh.edu
610-758-4998
timmc...@gmail.com
Google Talk: timmcgeary
Yahoo IM: timmcgeary
Godmar Back
>
> Yeah, that sounds cool, Godmar.
>
> For me the question is not so much whether the item and holdings information should be in the bibliographic record or not -- I may have derailed you in that example -- but rather what the 'schema' parameter in 'GetRecords' and 'Search' is meant to define.
>
My opinion: let's ignore that parameter for now and always return
expanded DLF records. This is simplest for our clients. Later on, we
can add/define the ability for a client to request a specific format.
Other people have different opinions. Compare, for instance, Peter's
implementation, which returns DLF records only if you ask for
"expanded" or "dlfexpanded" as the schema. In my view, that's not
ILS-DI - it's just a SRU (or whatever) server for records using some
schema. Mind you, it's great if people create SRU servers that
return, say MARC records - but ILS-DI's raison d'etre really is the
expanded format. That's what will provide the information and
interoperability that could make ILS-DI successful.
> The documentation seems to indicate that the schema parameter in those functions applies to *both* the bibliographic record and items/holdings data. But that doesn't seem right, since other parts of the documentation clearly show that bib and item records can (and in most cases likely will) be in two different schemas.
>
I see your point.
Presumably, if you requested some other schema that's not
DLF-expanded, you're not getting DLF records back but records in some
other schema (like your SRU implementations). Then, holdings and items
will occur - if they do occur - in however that other schema defines
them.
Again, my opinion is to implement 1 expanded format first which has
the information we need for our use cases now, then let's worry about
flexibility - where the client can request certain formats - later.
- Godmar
Godmar Back
very good at scraping serial holdings anyway (unless David has added
that.)
What are the current customs? Return serial holdings as "dlf:holdings"
and monograph holdings as "dlf:items"?
The alternative option would be to define a simplified view that does
away with this very library-specific and possibly unnecessary
distinction and use resources vs. items instead whereby an item can
represent either a "holdings records" for serials or an "item record"
for monographs. I think the ILS-DI wanted to keep their options open
by designing both dlf:holdings and dlf:items in their record format to
reflect common practice in the library world, however uneven it plays
out between libraries.
Ideas are appreciated.
- Godmar
Ross Singer
serial holdings?!
I kid.
This discussion, while I don't want to discourage it, is probably
better suited for the ILS-DI group, since people there might know
better what was meant by that.
http://groups.google.com/group/ils-di
However, if you ask there, please cc this group.
The ILS-DI group defined a new schema, called ExpandedRecords, which,
I think is what they're calling for there.
http://onlinebooks.library.upenn.edu/schemas/dlfexpanded.xsd
-Ross.
On Fri, Jul 18, 2008 at 3:35 PM, Tim McGeary <timmc...@gmail.com> wrote:
>
Emily Lynema
I think the recommendation did not do a good job of addressing this complexity. The schema parameter was part of our initial work in the function definition for GetRecords and Search, with the idea of returning bibliographic records in marcxml vs. dublin core as was most useful to the api consumer. It wasn't until quite a bit later when we began to consider the implications of including holdings and item metadata in a response that we realized multiple schemas might be required in a single response. I guess when never went back to consider how that impact a schema parameter. I see a note made it into the final version of the recommendation that holdings and item metadata should be included in the response only when supported by the requested schema. That seems a little odd to me, since there really aren't single schemas that support all this information, aside from the newly proposed dlf schema. I don't think that we ever intended standards like marcxml to be tweaked to bring holdings and item information into the the bibliographic record. So at this point, maybe it makes sense to default this function to supporting the expanded dlf schema, and encourage discussion about whether it makes sense to support a schema parameter. And if it does, does it needed to be expanded in what it covers?
This discussion really belongs with the ILS-DI group, so I have cc'ed that list.
-emily
Walker, David
> maybe it makes sense to default this
> function to supporting the expanded
> dlf schema
It seems to be concerned with lower-level code: there are references to hashes, keys, objects, etc. Some function like 'GetAvailability' are expected to return a list of 'Item Availability Objects', which could then be mapped by higher-level code to any number of bindings.
But 'GetRecords' and 'Search' as they are defined in the docs, and as your comment here is sorta indicating, Emily, already seem to be looking forward to on of the possible bindings, in this case a web service.
It seems to me that you wouldn't want the (lower-level) function itself to return XML within a DLF schema. But rather a list of OBJECTS, as 'GetAvailability' does. Higher-level code, then, could map those variously to different outputs, including a DLF schema.
That distinction is important to me for two reasons: (1) I'd like to call this code I'm creating natively within my own (PHP) application, and others might too, so good to standardize. And (2) if I wanted to output to a non-XML structure (JSON, say, for jangle?), it would make a lot of sense to not have to map Object -> XML -> JSON if you can just do Object -> JSON.
--Dave
==================
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu
________________________________
Sent: Sunday, July 20, 2008 1:18 PM
To: jangle-...@googlegroups.com; ils...@googlegroups.com
I think the recommendation did not do a good job of addressing this complexity. The schema parameter was part of our initial work in the function definition for GetRecords and Search, with the idea of returning bibliographic records in marcxml vs. dublin core as was most useful to the api consumer. It wasn't until quite a bit later when we began to consider the implications of including holdings and item metadata in a response that we realized multiple schemas might be required in a single response. I guess when never went back to consider how that impact a schema parameter. I see a note made it into the final version of the recommendation that holdings and item metadata should be included in the response only when supported by the requested schema. That seems a little odd to me, since there really aren't single schemas that support all this information, aside from the newly proposed dlf schema. I don't think that we ever intended standards like marcxml to be tweaked to bring holdings and item information into the the bibliographic record. So at this point, maybe it makes sense to default this function to supporting the expanded dlf schema, and encourage discussion about whether it makes sense to support a schema parameter. And if it does, does it needed to be expanded in what it covers?
This discussion really belongs with the ILS-DI group, so I have cc'ed that list.
-emily
Yeah, that sounds cool, Godmar.
For me the question is not so much whether the item and holdings information should be in the bibliographic record or not -- I may have derailed you in that example -- but rather what the 'schema' parameter in 'GetRecords' and 'Search' is meant to define.
The documentation seems to indicate that the schema parameter in those functions applies to *both* the bibliographic record and items/holdings data. But that doesn't seem right, since other parts of the documentation clearly show that bib and item records can (and in most cases likely will) be in two different schemas.
I guess what I'm saying is that either I or the documentation is confused on this point -- likely the former. ;-)
--Dave
==================
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu
________________________________________
In our implementation, we will not be putting holdings in the
bibliographic records.
They'll go under dlf:record/dlf:items and use ISO holdings format.
In addition, the dlf:simpleavailability child provides a summary of
the availability status of the items.
See the earlier thread (-> mailing list archives) regarding why our
current thinking discourages Marc 852 use.
- Godmar
Walker, David
> as "dlf:holdings" and monograph holdings as "dlf:items"?
I'm not a cataloger, so I may not be describing this accurately. Please correct me here.
I take holdings records to be a summary statements of a journal's holdings. You would typically have one for the stuff in print, one for the stuff in microfilm, and I think potentially one for stuff online (although the online info sometimes go in the bib record itself).
An item record for a journal or magazine, on the other hand, would contain information on just one bound volume, for example -- which might actually circulate, so good to have a record -- or one of those microfilm reels.
--Dave
==================
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu
From: jangle-...@googlegroups.com [jangle-...@googlegroups.com] On Behalf Of Godmar Back [god...@gmail.com]
Sent: Friday, July 18, 2008 1:45 PM
To: jangle-...@googlegroups.com
townxelliot
I'm working on precisely this issue at the moment, and it would be
good to attempt to code close(-ish) to the Jangle API.
Elliot
On Jul 21, 6:51 pm, "Walker, David" <dwal...@calstate.edu> wrote:
> > What are the current customs? Return serial holdings
> > as "dlf:holdings" and monograph holdings as "dlf:items"?
>
> Not quite. Serials can have *both* item and holding records.
>
> I'm not a cataloger, so I may not be describing this accurately. Please correct me here.
>
> I take holdings records to be a summary statements of a journal's holdings. You would typically have one for the stuff in print, one for the stuff in microfilm, and I think potentially one for stuff online (although the online info sometimes go in the bib record itself).
>
> An item record for a journal or magazine, on the other hand, would contain information on just one bound volume, for example -- which might actually circulate, so good to have a record -- or one of those microfilm reels.
>
> --Dave
>
> ==================
> David Walker
> Library Web Services Manager
> From: jangle-...@googlegroups.com [jangle-...@googlegroups.com] On Behalf Of Godmar Back [god...@gmail.com]
> Sent: Friday, July 18, 2008 1:45 PM
> To: jangle-...@googlegroups.com
> Subject: [jangle-discuss] Re: ILS-DI item and holding information
>
> That's also to-be-defined. Currently, the Innopac scraping code isn't
> very good at scraping serial holdings anyway (unless David has added
> that.)
>
> What are the current customs? Return serial holdings as "dlf:holdings"
> and monograph holdings as "dlf:items"?
>
> The alternative option would be to define a simplified view that does
> away with this very library-specific and possibly unnecessary
> distinction and use resources vs. items instead whereby an item can
> represent either a "holdings records" for serials or an "item record"
> for monographs. I think the ILS-DI wanted to keep their options open
> by designing both dlf:holdings and dlf:items in their record format to
> reflect common practice in the library world, however uneven it plays
> out between libraries.
>
> Ideas are appreciated.
>
> - Godmar
>
>
> > Does this vary at all for monograph holdings vs. serial holdings?
>
> > Tim
>
> > --
> > Tim McGeary
> > Senior Systems Specialist
> > Lehigh University
> > 610-758-4998
>
> > timmcge...@gmail.com
> > Yahoo IM: timmcgeary
>
> > Godmar Back wrote:
> >> In our implementation, we will not be putting holdings in the
> >> bibliographic records.
>
> >> They'll go under dlf:record/dlf:items and use ISO holdings format.
> >> In addition, the dlf:simpleavailability child provides a summary of
> >> the availability status of the items.
>
> >> See the earlier thread (-> mailing list archives) regarding why our
> >> current thinking discourages Marc 852 use.
>
> >> - Godmar
>
Ross Singer
You have a couple of choices here. Basically the "community profile"
process for ILSes (which would determine the lowest common
denominators for maximum interoperability) hasn't begun yet.
That being said, I think it's pretty much a given that Resources
should support MARCXML (and possibly MARC8/21/etc.). Designing a
Jangle-specific data format seems counterproductive.
Items are trickier and depend on if they're a serial item or not. I
raised the question a week or two ago about what data elements we'd
need for either, but didn't get much response. Let's try again.
First off, what's your use case? Monographic holdings (basically
items), serials holdings (basically coverage spans) or both?
I honestly think we can knock out monographic holdings in a day or two
if we start with something like ISO 20775 or DAIA and add some
location information and any other data we think they're leaving out.
Given that ISO 20775 is only available as a schema publicly (no spec
or HOWTOs or anything are available to the public) makes me a little
concerned about going down that path.
And... serials. Again, ISO should be able to handle this or ONIX-SOH.
Do you know what data elements you need for Prism?
Some use cases might make this simpler.
-Ross.
townxelliot
On Wed, 2008-07-23 at 09:49 -0400, Ross Singer wrote:
> Elliot,
>
> You have a couple of choices here. Basically the "community profile"
> process for ILSes (which would determine the lowest common
> denominators for maximum interoperability) hasn't begun yet.
>
> That being said, I think it's pretty much a given that Resources
> should support MARCXML (and possibly MARC8/21/etc.). Designing a
> Jangle-specific data format seems counterproductive.
>
> Items are trickier and depend on if they're a serial item or not. I
> raised the question a week or two ago about what data elements we'd
> need for either, but didn't get much response. Let's try again.
>
> First off, what's your use case? Monographic holdings (basically
> items), serials holdings (basically coverage spans) or both?
Serials holdings. We already have mono availability in a very
proprietary (but working for our purposes) form.
>
> I honestly think we can knock out monographic holdings in a day or two
> if we start with something like ISO 20775 or DAIA and add some
> location information and any other data we think they're leaving out.
>
> Given that ISO 20775 is only available as a schema publicly (no spec
> or HOWTOs or anything are available to the public) makes me a little
> concerned about going down that path.
>
> And... serials. Again, ISO should be able to handle this or ONIX-SOH.
>
> Do you know what data elements you need for Prism?
For Prism, we basically want to show (for serials):
- Location
- Shelfmark
- Details about the holding (e.g. which volumes)
- General notes/descriptive notes (I think they can be conflated, though
the ordering seems to matter to old Prism)
- "Wants" (e.g. "Wants: vol. 1, no. 2; vol. 2, no. 3") - this is
free-form text in Alto
We aren't covering lending of Talis "items" (which I don't think are
quite the same as FRBR items; basically they are physical copies), even
if serials have items catalogued against them.
Any suggestions you can provide would be gratefully received.
Elliot
Ross Singer
>> First off, what's your use case? Monographic holdings (basically
>> items), serials holdings (basically coverage spans) or both?
>
> Serials holdings. We already have mono availability in a very
> proprietary (but working for our purposes) form.
>
Proprietary as in "company secret"? Or proprietary as in "specific to
our use case"? Can you disclose what data, and roughly how it's
defined?
You can see how good our company communication model is :)
>> Do you know what data elements you need for Prism?
>
> For Prism, we basically want to show (for serials):
>
> - Location
What would this be for electronic? "EBSCO Academic Search Premier" or
something?
> - Shelfmark
This is English for "Call number"?
> - Details about the holding (e.g. which volumes)
I would definitely lean more towards ONIX-SOH than MFHD for this...
> - General notes/descriptive notes (I think they can be conflated, though
> the ordering seems to matter to old Prism)
Well, this gets into an interesting point.
My mental picture of 'holdings' in Jangle are roughly thus:
- They are Items just like monographic Items
- They can be defined by an atom:category or something as a holding
-- I'm open to ideas for specifics here.
- The Items themselves are related to a particular span and
location. So if there are breaks in coverage, these would be separate
Item resources. Supplements might also fall into this category, if
they're cataloged conveniently.
The last part is assuming that the data is even available (location to
date span) in a machine readable way. If the holdings are just all
shoved in a single MARC field (whatever it is that pre-MFHD records
use), I'm not sure the best way to do this. Possibly a single Item
resource.
Thoughts?
> - "Wants" (e.g. "Wants: vol. 1, no. 2; vol. 2, no. 3") - this is
> free-form text in Alto
What exactly does "wants" mean? Are these missing? Or waiting to be
checked in?
>
> We aren't covering lending of Talis "items" (which I don't think are
> quite the same as FRBR items; basically they are physical copies), even
> if serials have items catalogued against them.
No, I think that's roughly what FRBR items are. Can anyone clarify?
-Ross.
Emily Lynema
There has not been total agreement on this. The recommendation we wanted to push was implementation as web services, but John didn't want to eliminate the possibility of language-based bindings, which would provide hashes and objects, etc. The language that you see reflects this ambiguity. In general, I think the ILS-DI recommendation is intended to be focused on functions and data, and less on lower-level code.
When we said 'item availability objects', we were really thinking xml objects, not objects in the programming language sense.
In general, I don't believe what was outlined in the recommendation is intended to be the final word on implementation. We've provided more details in terms of XML schemas for the basic discovery interface functions in particular in part just to clarify the functionality desired. What we would like to see now is have the community work together to figure out best consensus for how to do actual implementations, rather than have a few people make all the decisions before any code is written.
As for outputting JSON, it seems like your code could provide both Object -> JSON and Object -> XML. The recommendation is not insistent that XML always be used; rather, the idea is to use metadata schemas that are current and transportable over the web.
-emily
Richard Wallis
At least with having XML as a start point you can get to most any other format, like JSON using xslt.
Ross Singer
> In general, I don't believe what was outlined in the recommendation is
> intended to be the final word on implementation. We've provided more details
> in terms of XML schemas for the basic discovery interface functions in
> particular in part just to clarify the functionality desired. What we would
> like to see now is have the community work together to figure out best
> consensus for how to do actual implementations, rather than have a few
> people make all the decisions before any code is written.
>
seems somewhat chicken-or-the-egg... It's difficult to pave the cow
paths when nobody's even walking.
-Ross.
Ross Singer
the output is fairly simple and very tightly defined.
For instance, I greatly prefer to get JSON back from the Yahoo APIs.
I would be less interested in JSON back from, say, an NCIP or SRU
service.
-Ross.
Godmar Back
> like to see now is have the community work together to figure out best
> consensus for how to do actual implementations, rather than have a few
> people make all the decisions before any code is written.
>
What I'd like to see is a participation by the ILS working group to
provide feedback to those people who are actually doing design and
writing code now. So far, I've seen only little of that. I found
this unfortunate, because us implementors do not have the luxury to
wait for whenever you decide to address the important decisions of
binding and implementation. If what we design and implement now is
ignored by the ILS-DI group, and if there are later attempt to
redesign interfaces and bindings, you're imposing unnecessary workload
on us.
In addition, you're not providing guidelines for vendors who may
actually attempt to implement this interface. You'll force them to
come up with their own, likely ad hoc designs and solutions. As a
result, interoperability of different implementations may be
jeopardized.
- Godmar
Walker, David
And thanks to the DLF committee too for all their hard work. I've found the document to be very useful, even at this (early) stage.
So too, I don't mean my questions here to be taken as criticisms, but rather as requests for clarification. I think I'm much clearer now on what I should be focusing on.
Thanks!
--Dave
==================
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu
________________________________
Sent: Thursday, July 24, 2008 8:15 AM
To: jangle-...@googlegroups.com
Cc: ils...@googlegroups.com
Subject: [ils-di] Re: [jangle-discuss] Re: ILS-DI item and holding information
Dave,
There has not been total agreement on this. The recommendation we wanted to push was implementation as web services, but John didn't want to eliminate the possibility of language-based bindings, which would provide hashes and objects, etc. The language that you see reflects this ambiguity. In general, I think the ILS-DI recommendation is intended to be focused on functions and data, and less on lower-level code.
When we said 'item availability objects', we were really thinking xml objects, not objects in the programming language sense.
In general, I don't believe what was outlined in the recommendation is intended to be the final word on implementation. We've provided more details in terms of XML schemas for the basic discovery interface functions in particular in part just to clarify the functionality desired. What we would like to see now is have the community work together to figure out best consensus for how to do actual implementations, rather than have a few people make all the decisions before any code is written.
As for outputting JSON, it seems like your code could provide both Object -> JSON and Object -> XML. The recommendation is not insistent that XML always be used; rather, the idea is to use metadata schemas that are current and transportable over the web.
-emily
Thanks, Emily, that's a great clarification for me.
> maybe it makes sense to default this
> function to supporting the expanded
> dlf schema
This kinda gets at another question I have: Is the ILS-DI technical recommendation concerned with defining BOTH the underlying functions (i.e., to be implemented in programming code) and the bindings (e.g., the output of a web service), or is it ultimately really only concerned with the bindings?
It seems to be concerned with lower-level code: there are references to hashes, keys, objects, etc. Some function like 'GetAvailability' are expected to return a list of 'Item Availability Objects', which could then be mapped by higher-level code to any number of bindings.
But 'GetRecords' and 'Search' as they are defined in the docs, and as your comment here is sorta indicating, Emily, already seem to be looking forward to on of the possible bindings, in this case a web service.
It seems to me that you wouldn't want the (lower-level) function itself to return XML within a DLF schema. But rather a list of OBJECTS, as 'GetAvailability' does. Higher-level code, then, could map those variously to different outputs, including a DLF schema.
That distinction is important to me for two reasons: (1) I'd like to call this code I'm creating natively within my own (PHP) application, and others might too, so good to standardize. And (2) if I wanted to output to a non-XML structure (JSON, say, for jangle?), it would make a lot of sense to not have to map Object -> XML -> JSON if you can just do Object -> JSON.
--Dave
==================
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu
________________________________
Dave,
I think the recommendation did not do a good job of addressing this complexity. The schema parameter was part of our initial work in the function definition for GetRecords and Search, with the idea of returning bibliographic records in marcxml vs. dublin core as was most useful to the api consumer. It wasn't until quite a bit later when we began to consider the implications of including holdings and item metadata in a response that we realized multiple schemas might be required in a single response. I guess when never went back to consider how that impact a schema parameter. I see a note made it into the final version of the recommendation that holdings and item metadata should be included in the response only when supported by the requested schema. That seems a little odd to me, since there really aren't single schemas that support all this information, aside from the newly proposed dlf schema. I don't think that we ever intended standards like marcxml to be tweaked to bring holdings and item information into the the bibliographic record. So at this point, maybe it makes sense to default this function to supporting the expanded dlf schema, and encourage discussion about whether it makes sense to support a schema parameter. And if it does, does it needed to be expanded in what it covers?
This discussion really belongs with the ILS-DI group, so I have cc'ed that list.
-emily
Yeah, that sounds cool, Godmar.
For me the question is not so much whether the item and holdings information should be in the bibliographic record or not -- I may have derailed you in that example -- but rather what the 'schema' parameter in 'GetRecords' and 'Search' is meant to define.
The documentation seems to indicate that the schema parameter in those functions applies to *both* the bibliographic record and items/holdings data. But that doesn't seem right, since other parts of the documentation clearly show that bib and item records can (and in most cases likely will) be in two different schemas.
I guess what I'm saying is that either I or the documentation is confused on this point -- likely the former. ;-)
--Dave
==================
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu
________________________________________
In our implementation, we will not be putting holdings in the
bibliographic records.
They'll go under dlf:record/dlf:items and use ISO holdings format.
In addition, the dlf:simpleavailability child provides a summary of
the availability status of the items.
See the earlier thread (-> mailing list archives) regarding why our
current thinking discourages Marc 852 use.
- Godmar