Re: Schema.org and "Holdings"

Hi all:

I've worked a little more on holdings, along the following lines:

* Used the schema.org extension mechanism
(http://schema.org/docs/extension.html) to provide more
library-oriented properties, while theoretically[1] enabling
schema.org processors to fall back to using the base property until
such time as they decide they need to differentiate. Also, other
endeavours that have similar needs to libraries, such as publishers,
book stores, etc, can use the same base attributes but extend in a
parallel way. So:

** Library: base attribute = Offer.seller, extended to Offer.seller/library
** Call number: base attribute = Offer.sku, extended to Offer.sku/callNumber
** Barcode: base attribute = Offer.serialNumber, extended to
Offer.serialNumber/barcode
** Shelving location: base attribute = Offer.availableAtOrFrom,
extended to Offer.availableAtOrFrom/shelvingLocation
** ISBN13: base attribute = Offer.gtin13, extended to Offer.gtin13/isbn13

The original record is still at
http://stuff.coffeecode.net/schema.org/holdings_ex1.html but you can
compare it with the extended version at
http://stuff.coffeecode.net/schema.org/holdings_ex1_extended.html

* Modeled two records that express "bound-with" holdings using the
Product.isRelatedTo itemprop, extended to
Product.isRelatedTo/boundWIth:

  ** http://stuff.coffeecode.net/schema.org/holdings_bound_with_ex1.html
is the "parent" record, which shows all of the other records that are
bound with it;
  ** http://stuff.coffeecode.net/schema.org/holdings_bound_with_ex2.html
is a "child" record, which just links back to the parent record

The required code is available for Evergreen at
http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dbs/schema_holdings

As for price = $0 vs. just leaving price as the text node "Library
loan", I'm wary about the latter option because I work in a bilingual
library. If we went the text node route, we would either have to have
the schema.org processor crawl the page twice to pick up the different
translations, or trust in machine translation. That said, I don't have
a concrete proposal yet for expressing a disambiguated "Loan"
property.

Jeff - I've looked at IndividualProduct and SomeProducts a number of
times. The former simply adds "serialNumber", which we have to have at
the Offer level anyway, so I don't see where that improves anything.
For the latter, I suppose I could use the added "inventoryLevel"
property to express the copy counts instead of an AggregateOffer, but
I don't see how either one resolves the bad smell of needing to repeat
the same Offer url for each Offer. Undoubtedly I'm missing something
obvious.

On actionable URIs - for all of the new examples, I've left the raw
Email / Print / Add to My List / Place Hold links in place. Evergreen
is effectively stateless (you should be happy about that, Jeff) so
those links do what you would expect, and we could use them as
examples for further real-world-based modelling exercises. That said,
is any other corner of schema.org trying to model actions like this?
Are there applicable use cases that publishers / vendors / others have
for this effort?

I still tend to think it would be a huge win simply to arrive at some
agreed-upon-standardized-on-schema.org means of expressing
bibliographic metadata and holdings for our first kick at the can,
with the goal of enabling search engines and schema.org processors to
at least provide users with a coherent URL to arrive at where they can
then take further action...

Karen - to your question about whether we need schema.org/Holdings -
at this point I don't think we've identified anything that we can't
model using the existing vocabulary using extended properties for
clarity--with the possible exception of price/loan--but assuming that
the schema.org extension mechanism actually works in practice, we
could extend schema.org/Offer to schema.org/Offer/Holdings if we
wanted a more clear expression of our intention.

[1]. Google's own Rich Snippets testing tool complains about the
extensions, so perhaps this isn't a fruitful direction to take things
(despite being part of schema.org since day one).

[2]. Schema.org enumerations appear to offer no extension mechanism
for adding a type to the enumeration, so sadly this doesn't offer a
simple way out for AudioBook (unless we assumed all AudioBooks were
subclasses of EBooks, which the books-on-tapes would beg to differ
about!)


On Fri, Jul 12, 2013 at 10:11 PM, Young,Jeff (OR) <jyoung@oclc.org> wrote:
> 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 Monday, 15 July 2013 20:45:26 UTC