Re: Schema.org and "Holdings"

Dan,

If you reconsider the use of schema:IndividualProduct and schema:SomeProducts, you should be able to pass the smell test again on item-level assertions.

Also, rather than schema:price=$0, I would point out that the range on this property can also be a text string. For example, "Library Loan". My earlier suggestion about using gr:businessFunction would also work for systems that wanted to be more expressive, but with some extra cost in terms of semantic overhead.

Jeff

Sent via a cracked screen :-(

On Jul 12, 2013, at 4:17 PM, "Dan Scott" <denials@gmail.com> wrote:

> 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 Saturday, 13 July 2013 00:03:31 UTC