W3C home > Mailing lists > Public > public-schemabibex@w3.org > July 2013

Re: Schema.org and "Holdings"

From: Dan Scott <denials@gmail.com>
Date: Tue, 9 Jul 2013 14:38:17 -0400
Message-ID: <CAAY5AM2UE5cXVJVRcBw9bs6K3KCfb5LCQLni0TDKH6GgsBC2Cw@mail.gmail.com>
To: "Young,Jeff (OR)" <jyoung@oclc.org>
Cc: "public-schemabibex@w3.org" <public-schemabibex@w3.org>
Hi Jeff et al:

On Fri, Jun 28, 2013 at 2:30 PM, Young,Jeff (OR) <jyoung@oclc.org> wrote:
> Dan,
> Thanks for volunteering to experiment with schema:Product/Offer for holdings in your system. The attached UML might help illustrate how some of the Schema.org terms fit together. There are at least a couple ways to traverse their model to accomplish it, depending on how expressive you want to be. I look forward to comparing notes.

Thanks for the UML model. I opted to start with schema.org/Offer and
map the Evergreen library system's public holdings display (physical
and electronic) using only existing schema.org properties. As it turns
out, ProductModel / IndividualProduct / SomeProducts /
QuantitativeValue don't seem to be necessary if you're simply
modelling holdings as they surface in many library systems today.

Some of the real-world characteristics that came into play with
Evergreen's sample data (reinforcing many of the examples that Karen
provided at http://kcoyle.net/holdings.html) are:

* Multiple copies may be displayed for any given record. I mapped each
copy to a separate http://schema.org/Offer object. Also, I opted to
use the additionalType of "Product" instead of "IndividualProduct", as
IndividualProduct is defined as "A single, identifiable product
instance (e.g. a laptop with a particular serial number)."
* Each copy has a library at which it is currently circulating. I
mapped this to the http://schema.org/Offer "seller" property (just
using the raw text of the library name as a reasonable starting point;
a future development could be for Evergreen to expose one URI per
library, from which the library coordinates, opening hours, contact
information, branch hierarchy, etc could be derived -- as Evergreen
already knows most of that information).
* Each copy has a call number. I mapped this to the
http://schema.org/Offer "sku" (stock keeping unit) property, as "a
merchant-specific identifier for a product or service" seems like a
good enough match.
* Each copy has a barcode. I mapped this to the
http://schema.org/Offer "serialNumber" property.
* Each copy has a shelving location. I mapped this to the
http://schema.org/Offer "availableAtOrFrom" property (just using the
raw text of the location as a http://schema.org/Place as a reasonable
starting point).
* Each copy has an availability status, which I was able to map to the
http://schema.org/Offer "availability" property. In turn, I was able
to use the stock http://schema.org/ItemAvailability enumeration
without torturing definitions much. For example, "Available" =
http://schema.org/InStock, "Checked Out" =
http://schema.org/OutOfStock, "On Order" = http://schema.org/PreOrder,
"On Reserve" = http://schema.org/InStoreOnly.
* Records _might_ have an ISBN13; if they do, then I map those to the
http://schema.org/Offer "gtin13" property for each copy. In
retrospect, given that we have the addtionalType of
http://schema.org/Product, I could just define that at the Product
level... an optimization for next time! I could also get fancier and
convert ISBN10 identifiers to gtin13 if we don't have an ISBN13.

* Holdings often list electronic resources, as well. If so, I map them
to a http://schema.org/Offer and make the
http://schema.org/ItemAvailability enumeration using
http://schema.org/OnlineOnly. There is some potential for using the
http://schema.org/Offer eligibleCustomerType property to identify
whether a given electronic resource is publicly available, or
restricted to library patrons (or a particular subset of library
patrons) via proxy access or the like.

* The Evergreen record display also includes one or more summary
statements about copy availability, reflecting each level of a
consortium / system / branch hierarchy. For example, if you're
searching at Branch 1, the display might say "36 copies available at
Consortium; 15 copies available at Branch 1". I mapped these
statements to simple http://schema.org/AggregateOffer objects using
just the "seller" and "offerCount" properties.

Thus far, I'm pretty happy with the results. You can see an example at
http://stuff.coffeecode.net/schema.org/holdings_ex1.html and Google's
Rich Snippets Tool appears to be happy with it (at
I did strip out much of the unnecessary fluff from the example, but it
originates from an Evergreen working branch at
so all of this would work in the wild today for Evergreen libraries
eager to expose their holdings via schema.org microdata. Also, I can
easily grab other samples from my local dev instance of Evergreen if
people are interested, and I can import new records / create new
combinations of holdings, etc, on demand. (This record came from
http://laurentian.concat.ca/eg/opac/record/341237 which only has a
minimal level of schema.org microdata).

I didn't want to muddy the waters in the W3 wiki just yet, given that
we already have a few different pages where holdings are being
explored. Perhaps if this direction seems of interest to the group, we
could work towards formalizing the suggestions for implementers.

Received on Tuesday, 9 July 2013 18:38:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:22:21 UTC