holdings and items
Godmar Back
to start a separate discussion, what are your thoughts on
holdings/items records?
Not being a librarian, I'm not fully clear on what the difference
between these is; all I know if that a ILS-DI DLF record can carry
0...m holdings records and 0...n item records in addition to a single
bibliographic record.
What format do you think we should place at the
dlf:record/dlf:holdings and dlf:records/dlf:items/* places?
Ideally, it would be something that would make sense even if a scraper
or Jangle connector could only provide reduced information.
- Godmar
Ross Singer
have been lumping them into the Items entity.
I suppose, though, that 'holdings' can also refer to an abstract, such
as a range of issues in a journal, and that gets a little more
complicated (as does everything with serials).
I think the same model still applies (i.e. a holding = item = Item)
and would be reflected in the record returned (i.e. a MFHD with
multiple chron and enum tags or an ISO 20775 document with multiple
holdings statements).
I think the DLF needs to define their elements a little better, honestly.
Now where things get complicated here (well, differently complicated)
would be something like an archival finding aids system. I suppose,
in a true separation of resources the EAD document should be divided
between the bibliographic data and the item data.
Jangle tries to maintain a FRBR-y relationship between Resources and
Items (originally I kicked around the idea of calling Resources
"Manifestations" to further this point - but found it too awkward of a
label); but this is going to have be contrived in a lot of instances,
I fear.
-Ross.
Godmar Back
>
> I think the same model still applies (i.e. a holding = item = Item)
> and would be reflected in the record returned (i.e. a MFHD with
> multiple chron and enum tags or an ISO 20775 document with multiple
> holdings statements).
>
> I think the DLF needs to define their elements a little better, honestly.
>
The DLF allows arbitrary XML where holdings and items will go inside a
DLF record.
That's where Jangle will place those, correct, or do you envision a
different scheme of reporting holding/item information?
Leaving the choice between "holding" and "item" aside for now, let me
drill further down what to place there.
You mention MFHD - I assume that means "MARC Format for Holdings
Records". Could you explain what that is, in XML? Would that be a
subset of a MARC record that uses 852 fields, such as $b, $c, and $z?
I understand the alternative is ISO 20775, as defined here:
http://www.oclcpica.org/content/1013/xsd/N110_ISO_holdings_v3.1.xsd
Where do you see the trade-off between these two formats?
- Godmar
Emily Lynema
A bib record might have MFHD + items. It might have MFHD only. It might have items only. We struggled with this in the DLF group, and wanted to come up with a structure where folks could return whatever they had. We had not reached the point of specifying how things should be returned uniformly by every system, even though that would be the best goal for interoperability.
ISO 20775 handles this situation better than some other possible formats, in that the standard specifies a way to describe either enumeration and chronology of MFHD or simpler item (physical volume) information. However, it doesn't provide a way to show that an MFHD is attached to a specific group of items. While this association between MFHD and physical items does not exist in every system (we don't have it in SD), it does exist in others (whichever it is that folks at U. Penn. are using).
So, that's the complexity we were facing when we dreamed up (at the last minute, of course) an XML schema.
-emily
Ross Singer
I was just thinking in Jangle terms (not ILS specifics). I'm still
not sure there's any difference as to whether or not you're referring
to a single, physical manifestation with a barcode, call number and a
place on the shelf or a span of journals in a given location. They're
just different kinds of (Jangle) Items.
Still, practically speaking, what would be the difference between a
Holding and an Item in the ILS-DI's HarvestHoldingsRecords method?
A Voyager system (like what Penn uses) would have MFHDs for both
serials and monographic records, right?
-Ross.
Emily Lynema
Well, I think I see the delineation.
I was just thinking in Jangle terms (not ILS specifics). I'm still
not sure there's any difference as to whether or not you're referring
to a single, physical manifestation with a barcode, call number and a
place on the shelf or a span of journals in a given location. They're
just different kinds of (Jangle) Items.
I'm glad that you can think in Jangle terms. :) In Jangle terms, how would you mush together this disparate MFHD and item information? There are plenty of things in MFHD that aren't usually available in an Item that can be really useful, such as a generic call number for a journal, it's status (currently received?), and summary holdings statement (particularly needed if a journal has not had individual volumes barcoded so there are no Items). I would love to have someone come up with a really elegant solution...
It sounds like you would create an Item schema that could cover both types of information. But I'm still not sure how you'd show relationships between MFHD Items and other Items (although I'm not totally convinced that's necessary, either).
Still, practically speaking, what would be the difference between a
Holding and an Item in the ILS-DI's HarvestHoldingsRecords method?
I believe that HarvestHoldingsRecords is Holding only, not items.
A Voyager system (like what Penn uses) would have MFHDs for both
serials and monographic records, right?
Yep. Some systems must have MFHDs for all bibliographic records. Others (like Horizon, I believe) don't even really support MFHDs.
-emily
Ross Singer
> I'm glad that you can think in Jangle terms. :) In Jangle terms, how would
> you mush together this disparate MFHD and item information? There are plenty
> of things in MFHD that aren't usually available in an Item that can be
> really useful, such as a generic call number for a journal, it's status
> (currently received?), and summary holdings statement (particularly needed
> if a journal has not had individual volumes barcoded so there are no Items).
> I would love to have someone come up with a really elegant solution...
Yeah, this gets ugly fast. This gets into what I was referring to
yesterday about the metadata "documents" not mapping 1:1 to the
resources (like the EAD example).
One of the things I've had some problems with is figuring out how to
deal with formats like ISO 20775. Realistically, Jangle wouldn't be
able to serve these records up directly, since it would be including
both Resource and Item entities data. Instead, an adapter service
would construct a valid ISO 20775 (or MFHD) record by combining the
entities.
So this raises the issue of what exactly gets returned from /items/?
I'm not sure Jangle is going to be offering any elegant solutions to
this. This is more of a GI/GO issue, honestly.
Anybody that has any ideas on how to approach this, throw in your ideas please.
-Ross.
Godmar Back
>
> Anybody that has any ideas on how to approach this, throw in your ideas please.
>
First, realize that outside the library world nobody has read Z39.71
or has any idea about whatever relationships may exist in ILS between
records, holdings, and items. Judging from how widely the adopted
conventions vary between libraries, even the understanding within the
library world seems limited.
Should Jangle or ILS-DI help this mess to survive and facilitate
people throwing their ad-hoc data models at the world? I'd say no.
Exporting them will be of little benefit if the receiving application
has to understand whatever idiosyncrasies went into the design. It's
the responsibility of the ILS-DI front-end/Jangle to export them in a
maintainable and consistent format.
The question is whether the ILS-DI XML Schema is one such format. My
understanding is that Ross had envisioned a simpler data model for
Jangle (by dropping the library specific distinction between
"Holdings" and "Items".
If the ILS-DI Schema is viable, we must define what goes in holdings
and items, rather than providing an opportunity for ILS to dump simply
"what they have."
Is such a definition possible? (Even if it means additional mapping or
processing for some ILS-connectors?)
As a practical question, for the 2 systems we're building adapters for
now - (a) III and b) Serials Solutions's JournalList), we'd be getting
a) a location, a call number, and a public note for each copy held (as in:
Newman 3rd Floor HB74.P8 L479 2005 c.2 AVAILABLE
and
b) a URL, a time range, and a description for each journal
as in:
from 2002 to present in PubMed Central + URL
That's the information we have to work with - how would we map those
into the ILS-DI format? (I was thinking for a) to create 1 item child
for each copy and use a to-be-discussed format to create a "holdings
record", and for b) I'm not sure --- are those "holdings"?)
How would Ross map those in Jangle?
- Godmar
Mike Rylander
I can provide two example formats. First:
http://dev.gapines.org/exporter?id=1&format=XML&holdings=1
This is the "standard" MFHD 852 item format. Ignore the 999 in that
record, which is legacy data in the dev system, and focus on the 852.
There is a minor abuse to the 852 there in that it uses subfield z
(public note) to pass availability information. I could certainly be
persuaded to move that to, say, subfield 9 if MFHD were the route we
decided to go.
The second format is an Evergreen construction that is used in the
SlimPAC (xml and xslt based):
You'll need to view the source, since at least in Firefox it displays
as a text blob -- this is due to the inclusion of xhtml elements,
which is a trigger for "render as a web page" for Firefox. Down at
the bottom you'll see a namespaced chunk of data describing the call
number (hold:volume) and copies (hold:copy). It's slim, and could use
a makeover, but it gets the job done for what we need of it, which is
to drive an unAPI-based user interface. As this is only used
internally within Evergreen XSLTs today, it is also mutable.
Anyway, they're options.
--
Mike Rylander
| VP, Research and Design
| Equinox Software, Inc. / The Evergreen Experts
| phone: 1-877-OPEN-ILS (673-6457)
| email: mi...@esilibrary.com
| web: http://www.esilibrary.com
Godmar Back
>
> http://dev.gapines.org/opac/extras/unapi?id=tag:dev.gapines.org,2008:biblio-record_entry/161468/PINES&format=marcxml-full
>
I'd seen that before, and wondered if it's been adopted outside Evergreen.
I tried to learn more about it by reading the schema; unfortunately,
http://open-ils.org/spec/holdings/v1
doesn't give any clues --- do you have the schema?
How would you compare this to ISO 20775 Holdings? Would you drop
yours in favor of ISO or are there reasons why you (and by extension,
us) should prefer your schema?
- Godmar
Godmar Back
>
> This is the "standard" MFHD 852 item format. Ignore the 999 in that
> record, which is legacy data in the dev system, and focus on the 852.
If I understand it correctly, those 852 fields will be inserted into
the bibliographic record. That is, 1 marc:record element represents
both the information that describes bibliographic information such as
title, author, etc. and the information about the copies held by a
library contained in one or more 852 fields and/or subfields. (That's
despite the fact that the underlying data model in the ILS separates
those two by having "items" records that "link" to "bibrecords" ---
I'm using double quotes here because I'm quoting librarians I talked
with.)
The ILS-DI proposed schema, however, advocates the separation of
bibliographic information (they're a child of
dlf:record/dlf:bibliographic) and holdings/items information. I like
that distinction.
If we wanted to in fact maintain this distinction, would using 852
fields be a good option? Or should we just scrap it? You call it the
"standard" MFHD 852 format - how "standard" is it? Is it used in many
external facing systems that provide ILS data besides yours? (*)
- Godmar
Mike Rylander
>
> On Tue, Jul 15, 2008 at 10:57 AM, Mike Rylander <mryl...@gmail.com> wrote:
>>
>> http://dev.gapines.org/opac/extras/unapi?id=tag:dev.gapines.org,2008:biblio-record_entry/161468/PINES&format=marcxml-full
>>
>
> I'd seen that before, and wondered if it's been adopted outside Evergreen.
>
> I tried to learn more about it by reading the schema; unfortunately,
> http://open-ils.org/spec/holdings/v1
> doesn't give any clues --- do you have the schema?
>
There is no schema today, as it's not used outside Evergreen.
Honestly, other than my work on the OpenSearch-based discovery
interface, I'm not aware of anyone that has tackled the problem in
practice in an existing ILS. Instead (my understanding is) they punt
to "use MFHD or something you make up." For instance, most
acquisition systems have a configurable item/holding setup so that
they can conform to how the vendors have decided to supply holdings
information in order records (or vice versa, where the ILS makes up a
format and the vendor conforms), but they often don't use the standard
for various reasons, such as purchasing-oriented richness, or lack
thereof.
> How would you compare this to ISO 20775 Holdings? Would you drop
> yours in favor of ISO or are there reasons why you (and by extension,
> us) should prefer your schema?
>
I'm not trying to advocate strongly for the Evergreen format -- it's
not nearly rich enough today to handle the full gamut of holdings
(items and journals) data in the same way as ISO 20775 or full MFHD (
http://www.oclc.org/support/documentation/localholdings/quickref/default.htm#lhr_fields
). But, as pointed out, what can the systems (that we can't control)
actually provide? If an XSL, a few more elements and codification of
some best practices will get us most of the way there, then it's worth
consideration perhaps.
The ISO format or ONIX ( http://www.editeur.org/onix.html -- a
standard that actually /is/ used outside the library world) may very
well be what Jangle should use as an output format (though not an
input format) and I can get behind that if it's the choice of the
perponderence of those of us interested in seeing Jangle succeed. I
will say, though, that given the slim data coming out of most ILS'
(and other systems) both seem like overkill. I'm happy to be wrong
here.
Mike Rylander
>
> On Tue, Jul 15, 2008 at 10:57 AM, Mike Rylander <mryl...@gmail.com> wrote:
>>
>> http://dev.gapines.org/exporter?id=1&format=XML&holdings=1
>>
>> This is the "standard" MFHD 852 item format. Ignore the 999 in that
>> record, which is legacy data in the dev system, and focus on the 852.
>
> If I understand it correctly, those 852 fields will be inserted into
> the bibliographic record. That is, 1 marc:record element represents
> both the information that describes bibliographic information such as
> title, author, etc. and the information about the copies held by a
> library contained in one or more 852 fields and/or subfields. (That's
> despite the fact that the underlying data model in the ILS separates
> those two by having "items" records that "link" to "bibrecords" ---
> I'm using double quotes here because I'm quoting librarians I talked
> with.)
That's correct, however ...
>
> The ILS-DI proposed schema, however, advocates the separation of
> bibliographic information (they're a child of
> dlf:record/dlf:bibliographic) and holdings/items information. I like
> that distinction.
>
(As do I.)
> If we wanted to in fact maintain this distinction, would using 852
> fields be a good option? Or should we just scrap it? You call it the
The MFHD data can stand alone in a record containing nothing more than
a pointer to the full bibliographic record. In other words, the 852
tags can be passed in a nearly-empty MARC record that points to the
describing bib. However, I'm not in favor of passing MARC around for
items, no, so it would be the format of last resort, in my opinion,
for Jangle. I simply presented it as an ILS-specific format that is
standard to (most) ILSs.
> "standard" MFHD 852 format - how "standard" is it? Is it used in many
> external facing systems that provide ILS data besides yours? (*)
>
All systems the I know of (with, apparently, the exception of
Horizon?) can generate 852 tags for items. It's the standard in the
library world. Most systems can also generate locally defined tags
with more information that can be passed in the 852 alone. When you
request records with holdings from a Z39.50 server, this is the
expected format.
Richard Wallis
throwing their ad-hoc data models at the world? I'd say no."
I couldn't agree more!
We should pass the results of this conversation through the
non-librarian test, with associated question "does this make any sense?"
- if it doesn't we should try again (regardless of it conforming to MFHD
or Zanything).
~Richard
Godmar Back
>
> All systems the I know of (with, apparently, the exception of
> Horizon?) can generate 852 tags for items. It's the standard in the
> library world. Most systems can also generate locally defined tags
> with more information that can be passed in the 852 alone. When you
> request records with holdings from a Z39.50 server, this is the
> expected format.
>
That's not the case for the Z39.50 servers that Aleph and III systems
provide. I've experimented with them quite a bit.
They do not merge 852 fields into the records their Z39.50 servers
output, instead, if you ask for record format "opac", they'll add them
at the end. The Indexdata people then defined their own ad-hoc XML to
report it.
Overall, I agree with the caution about the use of this format you
seem to be advising. Let's not use it.
The question really isn't what can current ILS provide out of the box.
For one, we're writing adapters that can munge the existing
information into whatever format we wish, and secondly, the goal is to
set a copy-able standard for future ILS-DI implementations.
- Godmar
Mike Rylander
>
> On Tue, Jul 15, 2008 at 11:40 AM, Mike Rylander <mryl...@gmail.com> wrote:
>>
>> All systems the I know of (with, apparently, the exception of
>> Horizon?) can generate 852 tags for items. It's the standard in the
>> library world. Most systems can also generate locally defined tags
>> with more information that can be passed in the 852 alone. When you
>> request records with holdings from a Z39.50 server, this is the
>> expected format.
>>
>
> That's not the case for the Z39.50 servers that Aleph and III systems
> provide. I've experimented with them quite a bit.
> They do not merge 852 fields into the records their Z39.50 servers
> output, instead, if you ask for record format "opac", they'll add them
> at the end. The Indexdata people then defined their own ad-hoc XML to
> report it.
>
I'm not surprised at all for XML formated records. I was talking about
MARC21 format, though I should have been more explicit.
> Overall, I agree with the caution about the use of this format you
> seem to be advising. Let's not use it.
>
> The question really isn't what can current ILS provide out of the box.
> For one, we're writing adapters that can munge the existing
> information into whatever format we wish, and secondly, the goal is to
> set a copy-able standard for future ILS-DI implementations.
Oh, I don't care about the format they provide, but the actual
datapoints. They are slim, and the ISO format is deep, wide and rich.
It's also not used outside libraries, AFAIK. The more I think about
ONIX (even though it's absolutely HORRID to read as a human) the more
I like it.
Ross Singer
> Oh, I don't care about the format they provide, but the actual
> datapoints. They are slim, and the ISO format is deep, wide and rich.
> It's also not used outside libraries, AFAIK. The more I think about
> ONIX (even though it's absolutely HORRID to read as a human) the more
> I like it.
>
Since I've been knee-deep in ONIX-SOH for another project that I'm
trying to lasso a bunch of unsuspecting dopes^W^Winterested
participants like yourselves I've been shocked at how easily readable
and understandable the data model is. And then I take a look a the
XML schema and emit blood curdling screams until I go blind.
You raise a good point about about ONIX being used outside of
libraries, but would the consumers of ONIX generally be the consumers
of Jangle? Also, could we take another metadata format (and I'm not
endorsing, just using as an example), like ISO 20775 and that give us
the data we'd need to have an ONIX adapter on the front?
I actually find the ISO standard to be pretty simple (and, like your
MARC example, doesn't /have/ to provide bib information, I don't
think). The only problem is finding documentation for it anywhere.
Then there's Jakob Voss's Document Availability API:
http://www.gbv.de/wikis/cls/Document_Availability_Information_API
...
-Ross.
Tim McGeary
> "Should Jangle or ILS-DI help this mess to survive and facilitate people
> throwing their ad-hoc data models at the world? I'd say no."
>
> I couldn't agree more!
>
> We should pass the results of this conversation through the
> non-librarian test, with associated question "does this make any sense?"
> - if it doesn't we should try again (regardless of it conforming to MFHD
> or Zanything).
While I would generally agree with this, we should expect that IF the
vendors choose to support various elements of the ILS-DI schema, they
are likely to do so with their own variations based on their data
models. The subsequent result of this is libraries wanting to see
support of an ILS-DI connector/adapter that meets what their vendors
support rather than maybe what we, as individuals using a proprietary
ILS, have done on our own in this collaboration.
This isn't to dissuade further investigation of an agreeable solution,
but to add some sensitivity to what less-cutting-edge libraries may
require or need to join in these OS ILS-DI projects.
It's been difficult enough to get our vendor (SirsiDynix) to lend some
support for us to promote (and eventually distribute within our user
community) a proof-of-concept driver for a single ILS-DI app. We are
starting to port our internal discussion to this discussion. Supporting
our driver is a big enough task, but I'm afraid that if we come up with
a somewhat-forced generic (cross-vendor) solution (like fitting a round
peg in a square hole), that we'll end up competing with a
vendor-supported driver/schema, which will either stretch ourselves too
thin or lose support for the generic solution because of the ease of the
vendor-specific solution.
In short, I'd like to see a detailed discussion/investigation of what
each ILS is bringing to the table in this regards, but I don't know how
possible that is without disclosing too much and violating NDAs.
I can say that up to the a recent upgrade, it was impossible to use API
tools to get to the MARC Holdings records. Now it is a little bit
easier to access them on the fly, but still difficult from an export.
They don't get put into a bib field at all, but tagged on to the end in
a text format. It takes massaging from that point to do something with
it. But I haven't played with it much yet. That is on my to-do list
for the summer.
Between Item records and Holdings records, there is a clear distinction
in the SirsiDynix Unicorn/Symphony system that I would want to maintain
in some manner, as the holdings records are mainly key for serials.
Not sure if this helps the discussion, but I wanted to contribute.
Cheers,
Tim
--
Tim McGeary
Senior Systems Specialist
Lehigh University
tim.m...@lehigh.edu
610-758-4998
timmc...@gmail.com
Google Talk: timmcgeary
Yahoo IM: timmcgeary
Richard Wallis
> Tim McGeary wrote
>
> While I would generally agree with this, we should expect
> that IF the vendors choose to support various elements of the
> ILS-DI schema, they are likely to do so with their own
> variations based on their data models. The subsequent result
> of this is libraries wanting to see support of an ILS-DI
> connector/adapter that meets what their vendors support
> rather than maybe what we, as individuals using a proprietary
> ILS, have done on our own in this collaboration.
>
It is exactly this that justifies the need for a non-vendor specific
community initiative like Jangle. A developer from outside our
community will want to consume 'Library' APIs, not 'SD Library' or 'III
Library' or 'Talis Library' or 'Evergreen Library' APIs. They shouldn't
have to care who's code or data schema it is coming from.
So no doubt SD, as you describe, will produce their proof-of-concept
driver as will all their competitors. If they do, it will make the
production of Jangle connectors even easier - all it will need to do is
translate the vendor specific output from their API into a Jangle
vanilla. (OK I maybe over doing the easy bit, but I hope you see what
I mean)
So in Tim's case the API stack will look like this:
SD -> [SD]ILS-DI -> Jangle_connector(SD) -> Jangle ->
[Jangle]ILS-DI -> consuming application
~Richard
Godmar Back
>
> I actually find the ISO standard to be pretty simple (and, like your
> MARC example, doesn't /have/ to provide bib information, I don't
> think). The only problem is finding documentation for it anywhere.
>
I'm concerned about this lack of documentation as well. When I brought
it up on the ILS-DI mailing list, I got a response that indicated a us
vs them mentality, or a one secretive group vs. another. From what I
understand, ISO Holdings is mostly designed by a group around the
European OCLC subsidiary Pica. I was surprised that ISO Holdings ended
up so prominently positioned in the final ILS-DI draft.
Not sure if this should deter us - I'd be happy with going forward on
it and filling in gaps as we find them.
- Godmar
Tim McGeary
>> Tim McGeary wrote
>>
>> While I would generally agree with this, we should expect
>> that IF the vendors choose to support various elements of the
>> ILS-DI schema, they are likely to do so with their own
>> variations based on their data models. The subsequent result
>> of this is libraries wanting to see support of an ILS-DI
>> connector/adapter that meets what their vendors support
>> rather than maybe what we, as individuals using a proprietary
>> ILS, have done on our own in this collaboration.
>>
>
> It is exactly this that justifies the need for a non-vendor specific
> community initiative like Jangle. A developer from outside our
> community will want to consume 'Library' APIs, not 'SD Library' or 'III
> Library' or 'Talis Library' or 'Evergreen Library' APIs. They shouldn't
> have to care who's code or data schema it is coming from.
From the developer's perspective, absolutely. From the library's
perspective, this needs to be very simple for them to implement. From
what I'm reading here and other places so far, are we going to be able
to come up with a generic framework that is sensitive enough to all of
the vendor's ways of output to make it simple for the average library
that is sick of their OPAC, or like us and have a EOL on their OPAC?
> So no doubt SD, as you describe, will produce their proof-of-concept
> driver as will all their competitors. If they do, it will make the
> production of Jangle connectors even easier - all it will need to do is
> translate the vendor specific output from their API into a Jangle
> vanilla. (OK I maybe over doing the easy bit, but I hope you see what
> I mean)
How easy it is going to be desalinate vendor-specific output to
freshwater Jangle vanilla?
> So in Tim's case the API stack will look like this:
> SD -> [SD]ILS-DI -> Jangle_connector(SD) -> Jangle ->
> [Jangle]ILS-DI -> consuming application
Actually, what I'm thinking of is:
soon, we hope:
SD -> [SD]API -> [Tim, et al.] API serverside connector ->
Jangle_connector(SD) -> Jangle -> [Jangle]ILS-DI -> consuming application
later add:
SD -> [SD]ILS-DI API -> XYZ -> consuming application
I'm expecting it to be more like [Tim, et al.] build an SD connector for
Jangle, and later SD says "Here's our version of what we are opening for
the ILS-DI. Hook into ours..." and it be doing things enough
differently that it forces us either to rejects SD's or we have to spend
more time (again) building XYZ, but differently.
Both are going to require API into SD's server, which incurs risk.
Which is my user community going to want to do? If the later version,
how much time should I invest in something temporary. How long is
"temporary" in this case?
How many people are going to sit and wait until SD does something to
jump in, only to say "The Jangle-discussion group should have done X
instead of Y when building their generic framework. Now we have to do
ABC to convert it..." That's the scary scenario playing in my head. Am
I paranoid?
Ross Singer
> How many people are going to sit and wait until SD does something to
> jump in, only to say "The Jangle-discussion group should have done X
> instead of Y when building their generic framework. Now we have to do
> ABC to convert it..." That's the scary scenario playing in my head. Am
> I paranoid?
>
It depends on how desperate they are to get at their data and would
prefer to use Jangle than a proprietary API.
The solution to the scenario above (in my mind) would be to deprecate
the Y output format. One of the practices I would encourage for
Jangle use is to always include the record_type (or whatever parameter
we agree on) parameter in public feeds and applications.
So, in your case, you could have:
http://jangle.library.lehigh.edu/unicorn/item/123456?record_type=stupid_availability
SD makes their above claim and standardizes on format X. You keep
stupid_availability (at least, if the logs show any use lately), but
begin migrating your public applications to:
http://jangle.library.lehigh.edu/unicorn/item/123456?record_type=smart_availability
I have a similar issue with the connector for the TalisLMS. By
default, for the OPAC, the records are transformed out of the ILS to a
format called bibrdf, which is a little like a flat MODS (although far
simpler) and has no capability of being round tripped back to the
MARC. As such, by default, the TalisLMS connector will have to return
bibrdf documents. MARCXML will be available on request, but it would
be too expensive to use as the default.
However, there's a good possibility that eventually the MARCXML /will/
be available as easily as the bibrdf, and, in that case, it would be
the more desirable default.
So to ease this transition at /talislms/resources/12345, it would be
easier if clients used /talislms/resources/12345?record_type=bibrdf or
/talislms/resources/12345?record_type=marcxml or whatever.
Now, specifically regarding items/holdings/availability are there core
elements that appear in nearly every metadata format (MFHD, ISO, NCIP,
etc.) that convey enough of the story to be useful that exist in all
ILSes?
I feel like every ILS has to have "location", "callnumber", "status"
and, in the case of serials, "start range" and "end range". Now, the
problem with serials that aren't MFHDs is that the holdings are free
text fields that contain all sorts of information:
"Vols. 1-21, Vol. 3, Issue 4 missing"
I think these have to be dealt with differently and possibly on a case
by case basis (since different libraries may have cataloged them
differently).
However, in the case of monographs, what are the data fields?
In the case of serials, what are the data fields?
Can we agree on what's important and not worry about every possible use case?
-Ross.
Richard Wallis
Sent: Tue 15/07/2008 19:18
Tim McGeary
> On Tue, Jul 15, 2008 at 2:18 PM, Tim McGeary <timmc...@gmail.com> wrote:
>
>> How many people are going to sit and wait until SD does something to
>> jump in, only to say "The Jangle-discussion group should have done X
>> instead of Y when building their generic framework. Now we have to do
>> ABC to convert it..." That's the scary scenario playing in my head. Am
>> I paranoid?
>
> It depends on how desperate they are to get at their data and would
> prefer to use Jangle than a proprietary API.
Desperation is certain part of it. It's expertise and time that are the
keystones of their decision. The more they have, the better preference
I could see to use Jangle. The less they have, I don't know if it
matters how desperate they are, they may just have to wait for SD to
come along.
> The solution to the scenario above (in my mind) would be to deprecate
> the Y output format. One of the practices I would encourage for
> Jangle use is to always include the record_type (or whatever parameter
> we agree on) parameter in public feeds and applications.
>
> So, in your case, you could have:
> http://jangle.library.lehigh.edu/unicorn/item/123456?record_type=stupid_availability
>
> SD makes their above claim and standardizes on format X. You keep
> stupid_availability (at least, if the logs show any use lately), but
> begin migrating your public applications to:
> http://jangle.library.lehigh.edu/unicorn/item/123456?record_type=smart_availability
I think this makes sense, and I hope this is the case.
> I have a similar issue with the connector for the TalisLMS. By
> default, for the OPAC, the records are transformed out of the ILS to a
> format called bibrdf, which is a little like a flat MODS (although far
> simpler) and has no capability of being round tripped back to the
> MARC. As such, by default, the TalisLMS connector will have to return
> bibrdf documents. MARCXML will be available on request, but it would
> be too expensive to use as the default.
>
> However, there's a good possibility that eventually the MARCXML /will/
> be available as easily as the bibrdf, and, in that case, it would be
> the more desirable default.
>
> So to ease this transition at /talislms/resources/12345, it would be
> easier if clients used /talislms/resources/12345?record_type=bibrdf or
> /talislms/resources/12345?record_type=marcxml or whatever.
> Now, specifically regarding items/holdings/availability are there core
> elements that appear in nearly every metadata format (MFHD, ISO, NCIP,
> etc.) that convey enough of the story to be useful that exist in all
> ILSes?
That is the million dollar question, I think. And honestly, I don't
know the answer. But I will say that within the last 3 months, I've
worked with various pieces of systems from each of the 3 major vendors,
trying to come up with a way to integrate bibliographic and holdings
data from two of them into a 3rd. The bib data was a snap, the holdings
data load failed. The requirements of data manipulation was just too
great and complex.
> I feel like every ILS has to have "location", "callnumber", "status"
> and, in the case of serials, "start range" and "end range". Now, the
> problem with serials that aren't MFHDs is that the holdings are free
> text fields that contain all sorts of information:
>
> "Vols. 1-21, Vol. 3, Issue 4 missing"
>
> I think these have to be dealt with differently and possibly on a case
> by case basis (since different libraries may have cataloged them
> differently).
We definitely have cases like this. Maybe more than just cases.
> However, in the case of monographs, what are the data fields?
>
> In the case of serials, what are the data fields?
That's what I am trying to investigate from the SD point of view.
> Can we agree on what's important and not worry about every possible use case?
I hope so - I just want to make it accessible for as many libraries as
possible.
Tim McGeary
Richard Wallis wrote:
> I always reject any offer to pronounce on someone else's paranoia - it's
> safer that way ;-)
;)
> But having said that, I think we can safely say that there will be far
> more potential consuming applications than there are ILSs.
>
> In the same way that http and Apache insulate web developers from
> differing operating systems, application servers, languages and
> databases, Jangle can insulate developers from different ILSs, internal
> schema and preferred data formats.
>
> If SD do come up with a better ILS-DI implementation, it would still
> probably differ from all the others in some subtle ways. In which case
> the whole community would benefit the most if a new Jangle connector was
> produced for it. So I'm saying in your scenario XYZ would probably still
> be best done as another connector as against a separate stand-alone
> thing. Maybe SD could be convinced to build a Jangle connector themselves.
That sure would be nice. But I'm less concerned with a vendor coming up
with a better ILS-DI than I am with them coming up with a more limited
ILS-DI, even as limited available only to their user community, which is
the model they are supporting with the VUFind-Unicorn team now. I know
that's a philosophically different angle than is intended by this whole
ILS-DI task force, but I won't be surprised if this is how it ends up.
> Any developer of a consuming application, taking advantage of Jangle to
> interface it to several library systems, wouldn't thank you for
> developing an XYZ for them to worry about and test against.
>
> As to waiting around to see what will happen, some will always do that,
> others will get stuck in learn from both mistakes and success in moving
> the whole community forward.
Definitely agree here. This area is the most proactive I've been with a
major and potential new technology or schema since ERMI. I just hope
that whatever efforts and contributions I can add will be sustainable
for the others in the SD user community to use as their own.
Tim
--
Tim McGeary
Senior Systems Specialist
Lehigh University
tim.m...@lehigh.edu
610-758-4998
timmc...@gmail.com
Google Talk: timmcgeary
Yahoo IM: timmcgeary
> ------------------------------------------------------------------------
> *From:* jangle-...@googlegroups.com on behalf of Tim McGeary
> *Sent:* Tue 15/07/2008 19:18
> *To:* jangle-...@googlegroups.com
> *Subject:* [jangle-discuss] Re: holdings and items
Richard Wallis
> But I'm less concerned with a vendor coming up
> with a better ILS-DI than I am with them coming up with a more limited
> ILS-DI, even as limited available only to their user community, which is
> the model they are supporting with the VUFind-Unicorn team now. I know
> that's a philosophically different angle than is intended by this whole
> ILS-DI task force, but I won't be surprised if this is how it ends up.
Tim McGeary
No, they can't and wouldn't restrict what application uses it. It would
just be more restricting in sharing information for a Jangle connector
openly with this and other communities. It's one thing to have an API,
it's another to have it open, and if it isn't open, then much of the
connector may not be publishable outside of the individual user
community. Just another hurdle, but not an impossible one.
Richard Wallis
> No, they can't and wouldn't restrict what application uses
> it. It would just be more restricting in sharing information
> for a Jangle connector openly with this and other
> communities. It's one thing to have an API, it's another to
> have it open, and if it isn't open, then much of the
> connector may not be publishable outside of the individual
> user community. Just another hurdle, but not an impossible one.
>
If the Jangle connector consumed their ILS-DI API then there wouldn't be
any restricted information in the connector.
~Richard.