- From: Corey A Harper <corey.harper@nyu.edu>
- Date: Fri, 12 Jul 2013 11:25:30 -0400
- To: Karen Coyle <kcoyle@kcoyle.net>
- Cc: "Young,Jeff (OR)" <jyoung@oclc.org>, "public-schemabibex@w3.org" <public-schemabibex@w3.org>
- Message-ID: <CAE4UJ7VvG1L1OXL2vg-YuQYt5CY9avtJhjwOYkB2=HOAf-hR2w@mail.gmail.com>
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. Millennium, in turn, _does_ have restful APIs that represent those services. This is an area where the library technology community (and our vendors) need to be involved though. Ideally, the hold-request service provided here would be a simple patron-facing layer put on top of "My Millennium's" patron APIs, which are what Encore uses to make these hold requests from the stateful URI you provide. This powerpoint, particularly slides 15-17, provide more III specific information: www.eiug.org/c2011/*MillenniumAPIs*.pptx I really think we need to all be asking our vendors for well defined APIs & then coming up with best practices for describing the services that said APIs expose. Some groundwork for that has already been laid by HBZ, though with more of an RDF basis: https://wiki1.hbz-nrw.de/display/SEM/Howto+-+Describing+libraries,+their+collections+and+services+in+RDF -Corey On Fri, Jul 12, 2013 at 10:08 AM, Karen Coyle <kcoyle@kcoyle.net> wrote: > Jeff, there is a (very complex) URI for that particular hold, which will > be in the html. In my local library's pages I don't see anything that would > indicate a place hold service. > > http://encore.berkeley-public.**org/iii/encore/**SearchResultsPage,** > searchResultsComponent.**resultComponent.**searchBrowseResultBibComponent* > *.requestLinkComponent.**requestDialogLinkComponent.** > sdirect?lang=eng&sp=Sb1578523&**sp=**ZH4sIAAAAAAAAAFvzloG1rojBODk%** > 2FVy8zM1MvIz8npSi1sDS1uETPMam4**pCgxucQDKBYEEVOB0iGVBakMUCDEwF** > BRxMCXlViWqJeTmJeu55pXmossWVDC**wB7k6h7q4xgEAImPhxFvAAAA&**suite=pearl<http://encore.berkeley-public.org/iii/encore/SearchResultsPage,searchResultsComponent.resultComponent.searchBrowseResultBibComponent.requestLinkComponent.requestDialogLinkComponent.sdirect?lang=eng&sp=Sb1578523&sp=ZH4sIAAAAAAAAAFvzloG1rojBODk%2FVy8zM1MvIz8npSi1sDS1uETPMam4pCgxucQDKBYEEVOB0iGVBakMUCDEwFBRxMCXlViWqJeTmJeu55pXmossWVDCwB7k6h7q4xgEAImPhxFvAAAA&suite=pearl> > > I also wonder whether we should include something for "due date" or if > this becomes the content of the availability property. I think it is the > latter, so it would be: > > > Central Library Mystery Hillerman, T DUE 07-26-13 > > availableAtorFrom: Central Library Mystery > sku: Hillerman, T > outOfStock: DUE 07-26-13 > > kc > > > On 7/11/13 5:46 PM, Young,Jeff (OR) wrote: > >> Also, it occurs to me that the http URI of the library's "place hold" >> service for a manifestation could be used as the URI of the schema:Offer >> in the markup. In Dan's mockup these are blank nodes anyway, so this >> would kill two birds with one stone. >> >> Jeff >> >> Sent via a cracked screen :-( >> >> On Jul 11, 2013, at 8:25 PM, "Young,Jeff (OR)" <jyoung@oclc.org >> <mailto:jyoung@oclc.org>> wrote: >> >> Good Relations has a http://purl.org/goodrelations/**v1#LeaseOut<http://purl.org/goodrelations/v1#LeaseOut>term >>> that can be used in combination with the schema:businessFunction >>> property on schema:Offer. Our case is kind of like that. Perhaps we >>> could get Martin Hepp to add "#LibraryLoan to his GoodRelations >>> vocabulary and >>> tackle it from that direction. >>> >>> Jeff >>> >>> Sent via a cracked screen :-( >>> >>> On Jul 11, 2013, at 8:11 PM, "Karen Coyle" <kcoyle@kcoyle.net >>> <mailto:kcoyle@kcoyle.net>> wrote: >>> >>> Dan, thanks so much for this. I think we need to extend your >>>> experiment to some other holdings displays (ebook, periodical). I'm >>>> especially curious to see how to handle something like a book that is >>>> checked out (OutOfStock) but where the library offers an online >>>> 'place hold' service. How can we highlight those services? >>>> >>>> I'm a bit nervous about linking the ISBN to the item -- the ISBN will >>>> be recorded in the schema/Book description, but, as we've argued at >>>> length on the BIBFRAME list, library data often has multiple ISBNs >>>> but these are not associated with individual copies. In fact, the >>>> library may not even have a copy for each ISBN in its bibliographic >>>> record. >>>> >>>> Jeff suggested a while back something about listing the price as $0. >>>> I don't think that conveys the concept of lending, even though the >>>> price is right. It feels to me that we need something that means >>>> "lending" as well as the ability to give the loan period. I don't see >>>> anything similar to this in schema.org <http://schema.org> -- maybe >>>> >>>> I'm missing it? >>>> >>>> If I get a chance (not until next week, at least) I'll see if I can't >>>> mock up some other examples, but of course if anyone else has some >>>> time... >>>> >>>> kc >>>> >>>> On 7/9/13 11:38 AM, Dan Scott wrote: >>>> >>>>> Hi Jeff et al: >>>>> >>>>> On Fri, Jun 28, 2013 at 2:30 PM, Young,Jeff (OR) <jyoung@oclc.org >>>>> <mailto: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 <http://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 >>>>> <http://schema.org/Offer> and >>>>> >>>>> map the Evergreen library system's public holdings display (physical >>>>> and electronic) using only existing schema.org <http://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<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<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<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<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<http://stuff.coffeecode.net/schema.org/holdings_ex1.html>and Google's >>>>> Rich Snippets Tool appears to be happy with it (at >>>>> http://www.google.com/**webmasters/tools/richsnippets?** >>>>> q=stuff.coffeecode.net%**2Fschema.org%2Fholdings_ex1.**html<http://www.google.com/webmasters/tools/richsnippets?q=stuff.coffeecode.net%2Fschema.org%2Fholdings_ex1.html> >>>>> ). >>>>> I did strip out much of the unnecessary fluff from the example, but it >>>>> originates from an Evergreen working branch at >>>>> http://git.evergreen-ils.org/?**p=working/Evergreen.git;a=** >>>>> shortlog;h=refs/heads/user/**dbs/schema_holdings<http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dbs/schema_holdings> >>>>> so all of this would work in the wild today for Evergreen libraries >>>>> eager to expose their holdings via schema.org <http://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<http://laurentian.concat.ca/eg/opac/record/341237>which only has a >>>>> minimal level of schema.org <http://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. >>>>> >>>>> Dan >>>>> >>>>> >>>>> >>>> -- >>>> Karen Coyle >>>> kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> http://kcoyle.net >>>> >>>> ph: 1-510-540-7596 >>>> m: 1-510-435-8234 >>>> skype: kcoylenet >>>> >>>> >>>> > -- > Karen Coyle > kcoyle@kcoyle.net http://kcoyle.net > ph: 1-510-540-7596 > m: 1-510-435-8234 > skype: kcoylenet > > -- Corey A Harper Metadata Services Librarian New York University Libraries 20 Cooper Square, 3rd Floor New York, NY 10003-7112 212.998.2479 corey.harper@nyu.edu
Received on Friday, 12 July 2013 15:25:58 UTC