Re: Schema.org and "Holdings"

On 7/12/13 1:16 PM, Dan Scott wrote:

> 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!


Rather than get into something really complex, could each of these just 
be coded as a schema/Offer, without further detail? Since we don't know 
what would be made of all of this in a rich snippet or whatever other 
use case is imminent, just putting schema.org/Offer around each 
URL+image might be enough. I can't even imagine how many variations 
there are on these services across ILSs, and I haven't even begun to 
think beyond US libraries.

So I retract any suggestion that we need specific offers for the various 
library services, and instead prefer a simple solution until we have a 
good use case for something more detailed. I think that makes the 
holdings area readily do-able.

One remaining question that I have: will we create a schema.org/Holdings 
class, or will all of this just be a best practice using existing 
classes and properties?

kc


>
> 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
>

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet

Received on Friday, 12 July 2013 21:49:41 UTC