Re: Schema.org and "Holdings"

I would also argue that "modeling machine-actionable URIs and tackling the divide between ILS and discovery layer" absolutely is in scope. Search engines need to be library's new "discovery layer" or else "we" will soon be toast. 

Also note that Linked Data URIs are "machine-actionable". The question is whether our "services" are stateless enough to take advantage of this. The alienation of "service-oriented" systems and "resource-oriented" systems is absurd. We are screwing ourselves when we think and design "ILS" systems with stateful URIs.

Jeff

Sent via a cracked screen :-(

On Jul 12, 2013, at 8:03 PM, "Young,Jeff (OR)" <jyoung@oclc.org> wrote:

> 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 02:11:47 UTC