Re: Schema.org and "Holdings"

Hi Corey, et al.;

I'm going to try addressing the issue of placing holds on holdings in
this email; there are a few other questions and thoughts that have
popped up in this thread that I'll address in a subsequent email.

On Fri, Jul 12, 2013 at 11:25 AM, Corey A Harper <corey.harper@nyu.edu> wrote:
> Hi Karen, et al.,
>
> This is one great thing about the separation of the discovery layer & the
> ILS: it pretty much guarantees there's some kind of API underneath the link
> you mention. Encore doesn't do holds or circs itself, and it looks like in
> the case of Berkeley Public, that functionality is handed off to III's
> Millennium.

Jeff's suggestion of using Offer.url for a "place hold" action sounds
like a reasonable starting point to me. When I was working through the
examples at http://schema.org/Offer only one of the examples actually
included a URL property, so I hadn't been too worried about offering
something up for Offer.url. But it's a slam-dunk for the electronic
resource, at least!

In the case of current Evergreen, the "place hold" user facing URL is
pretty simple and stable:
https://hostname/eg/opac/place_hold?hold_target=97;hold_type=T (for a
"title" hold placed on record # 97). On that note, I had stripped out
the standard "Place hold / Add to my list / Print / Email / SMS"
actions from the sample record display, but could layer those back in
if it helps us make our efforts more concrete. I assume other library
systems and discovery layers offer similar actions and perhaps there's
some value to bearing them in mind, although I would be happy if, as a
first goal of publishing linked open data, the schema.org consumers
were to simply point users at the persistent URL for the record
display page and let the users navigate from there. (This seems to be
what's going on in 2 out of 3 examples on schema.org/Offer).

Overall, I suspect modelling machine-actionable URIs and tackling the
divide between ILS and discovery layer is a bit out of scope for this
group, given that our mission is to "discuss and prepare proposal(s)
for extending Schema.org schemas for the improved representation of
bibliographic information markup and sharing".

If I build the "place hold == Offer.url" feature into Evergreen, it
will be a configurable option, as some libraries have a "no holds on
available items / first come, first served" policy (like my own
academic library) and following the Offer url to simply get a "hold
denied" message would not be optimal.

Additionally, by default Evergreen restricts the public to placing
holds at the title level, rather than at the copy level, so I suppose
I would have to repeat the same Offer url for each Offer of a physical
copy... which immediately smells bad. It should be a different matter
if the copies are actually distinct parts, such as volumes in an
encyclopaedia, in which case unique "part holds" are offered up,
because getting a copy of Volume Y-Z isn't going to help you when you
want Volume A-Ai -- but right now, the user clicks "Place hold" to
bring them to the place hold screen, and then on the place hold screen
they are given the option to choose which part(s) they want, where
they want to pick up the item, notification options, etc.

I guess this is a good reminder for when we make recommendations for
modelling holdings about the wonderful diversity of policies that
libraries can adopt. :)

Upshot:

1) I will add itemprop="url" to the link for the electronic resource
Offer(s); that's a no-brainer.
2) I will add Offer.url properties for each copy, even though it will
be a repeating value. And I think it will be as <meta itemprop="url"
content="[hold_url]">. It's easy enough to roll back if we decide
that's ugly.

Thanks everyone for their comments so far, and I'll follow up as
promised in a subsequent email on some other issues and suggestions!

Dan

Received on Friday, 12 July 2013 20:17:08 UTC