- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Sat, 19 Oct 2013 13:16:55 -0700
- To: "Young,Jeff (OR)" <jyoung@oclc.org>
- CC: Dan Scott <denials@gmail.com>, "public-schemabibex@w3.org" <public-schemabibex@w3.org>
Jeff, I'm trying to make a more practical argument, which is that without the name of the library, the branch name isn't meaningful. I don't think we can decide what is a proper seller v. location, but if the locations aren't meaningful alone, then we need the library name. kc On 10/19/13 12:59 PM, Young,Jeff (OR) wrote: > Schema.org <http://Schema.org> has a branchOf property that probably has > a role to play sorting this out. > > I would argue that a "library system" like NYPL (in general) is more > like an administrative agency than it is an agency where books are being > circulated. The fact that the word "library" appears in the name > shouldn't be a huge problem for search engines if the data publishers > are careful. > > Jeff > > Sent from my iPad > > On Oct 19, 2013, at 3:08 PM, "Dan Scott" <denials@gmail.com > <mailto:denials@gmail.com>> wrote: > >> Also, I haven't added availableAtOrFrom to the examples on the >> Holdings proposal page because I was asking for consensus and >> providing sample examples in this thread. >> >> I am worried about this distinction you're introducing between branch >> and library. To me, a branch is a library. The seller represents the >> current physical location of the item (if that item is physical) where >> an interested party can pick it up. I think search engines are trying >> to satisfy an immediate need, not saying "oh it's available in NYPL >> somewhere". >> >> On Oct 19, 2013 2:24 PM, "Karen Coyle" <kcoyle@kcoyle.net >> <mailto:kcoyle@kcoyle.net>> wrote: >> >> Dan, I'm obviously having trouble explaining my point. Here's what >> I would add to the example: >> >> >> >> <div itemprop="offers" itemscope >> itemtype="http://schema.org/__Offer <http://schema.org/Offer>"> >> <meta itemprop="businessFunction" >> content="http://purl.org/__goodrelations/v1#LeaseOut >> <http://purl.org/goodrelations/v1#LeaseOut>"> >> <meta itemprop="seller" content="Example Branch 1</meta> >> <div>Call number: <span >> itemprop="inventoryIdentifier"__>876.54</span></div> >> <div>Location: <span >> itemprop="availableAtOrFrom">__Reference</span></div> >> <div>Item status: <span> >> <link itemprop="availability" >> href="http://schema.org/__InStoreOnly >> <http://schema.org/InStoreOnly>"> >> Library use only >> </span></div> >> </div> >> >> >> >> <div itemprop="offers" itemscope >> itemtype="http://schema.org/__Offer <http://schema.org/Offer>"> >> <meta itemprop="businessFunction" >> content="http://purl.org/__goodrelations/v1#LeaseOut >> <http://purl.org/goodrelations/v1#LeaseOut>"> >> <meta itemprop="seller" content="http://sfpl.org"></__meta> >> <div>Call number: <span >> itemprop="inventoryIdentifier"__>876.54</span></div> >> <div>Location: <span >> itemprop="availableAtOrFrom">__Reference</span></div> >> <div>Item status: <span> >> <link itemprop="availability" >> href="http://schema.org/__InStoreOnly >> <http://schema.org/InStoreOnly>"> >> Library use only >> </span></div> >> </div> >> >> "Seller" becomes the library, not the location within the library, >> and not even the branch. >> >> I see a useful interplay between "seller" and "availableAtOrFrom". >> If we add "availableAtOrFrom" (which I don't see on the examples >> on the web page for the proposal, but it makes good sense here), >> then we have "availableAtOrFrom" for the displayed physical >> location, whatever it is. Seller then becomes something that >> identifies the library qua organization, and should be an >> organization, not a location (like "Reference" or even "West >> branch"). Seller and availableAtOrFrom might be the same, but >> that's not a problem. For most displays, though, I think that they >> would be different, since the holdings display doesn't usually >> contain the library name: >> >> (site is Berkeley Public Library Catalog) >> Location Call no. Status >> CENTRAL LIB 876.54 Check shelf >> >> Imagine how many libraries have a location called "MAIN" or >> "CENTRAL" -- that's a location, not an organization. So you need >> to get the library organization name in there. >> >> <div itemprop="offers" itemscope >> itemtype="http://schema.org/__Offer <http://schema.org/Offer>"> >> <meta itemprop="businessFunction" >> content="http://purl.org/__goodrelations/v1#LeaseOut >> <http://purl.org/goodrelations/v1#LeaseOut>"> >> <meta itemprop="seller" content="Berkeley Public Library"></meta> >> <!-- or ... content="http://__berkeleypubliclibrary.org >> <http://berkeleypubliclibrary.org>" --> >> <div>Call number: <span >> itemprop="inventoryIdentifier"__>876.54</span></div> >> <div>Location: <span itemprop="availableAtOrFrom">__CENTRAL >> LIB</span></div> >> <div>Item status: <span> >> <link itemprop="availability" >> href="http://schema.org/__inStock <http://schema.org/inStock>"> >> Check shelf >> </span></div> >> </div> >> >> Does that make sense? >> >> kc >> >> >> >> I can include an example to cover this use case. >> >> Another case is for electronic >> materials. Library systems handle this differently, but >> there isn't a >> location in many cases: >> >> Online Click here >> >> >> Good question! What we do in Evergreen currently is essentially: >> >> <li property="offers" vocab="http://schema.org/" typeof="Offer"> >> <a href="URL_FOR_ELECTRONIC___MATERIAL">Available online</a> >> <link property="availability" >> href="http://schema.org/__OnlineOnly >> <http://schema.org/OnlineOnly>" /> >> ... >> </li> >> >> Glancing at this, I think I need to add in a property="url" to >> the <a> >> link there. And it certainly can have a <meta> tag for the >> "seller" >> property as well. I can include some documentation and an >> example for >> this use case, too. >> >> I'm thinking that there are cases in which the library >> itself is not >> included in the holdings statement (or anywhere else on >> the page) because it >> is inherent in the context of the system being searched. >> So my question is >> whether there is value in including information about the >> library itself as >> a super-location to the holdings location, or is the >> assumption that this >> connection will be made through, e.g., the URL of the web >> page that has the >> markup? >> >> >> I think there is significant value to creating 1) a page per >> library >> for a given system that contains the physical addresses / >> hours / etc, >> even for single-library systems and 2) linking to that page >> (explicitly, or implicitly via <meta>) from each of the associated >> offers. It will enable the search engines to follow their nose >> based >> on our assertions, rather than having to make assumptions >> about how >> many libraries may inherently be represented by >> library.example.com <http://library.example.com>. >> >> I think my question leads to a broader one about the use >> case for library >> data in schema.org <http://schema.org>. When I look at >> product examples it is clear to me that >> the target is the URL of the product page. Is this also >> the assumption for >> library data in schema.org <http://schema.org> -- that we >> are expecting a search engine >> retrieval of a page for a library resource, and that page >> is the target of >> the search? If so, then that URL is all that is needed to >> link to the >> library and its resource. If, however, we anticipate other >> uses to be made >> of the schema mark-up, such as organizing retrieved items >> by geographical >> location, then we need to get that information into each >> web page. This may >> be unrelated to the markup of holdings, but it was this >> proposal that >> brought it to mind. >> >> >> Good question again. I see the primary use case being the search >> engines ingesting a sitemap, crawling all of the listed pages, and >> sorting out the items and linked offers accordingly. >> >> In the case of our library catalogue, I created a sitemap that >> lists >> each of the record detail pages, which expose metadata & holdings. >> Unfortunately, when I generated the sitemap last year, it was >> before I >> had implemented holdings-as-offers; now that all of the attached >> offers will be part of each record details page, I think a new >> crawl >> of those pages could provoke much more interesting results. >> >> >> -- >> Karen Coyle >> kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> http://kcoyle.net >> m: 1-510-435-8234 <tel:1-510-435-8234> >> skype: kcoylenet >> -- Karen Coyle kcoyle@kcoyle.net http://kcoyle.net m: 1-510-435-8234 skype: kcoylenet
Received on Saturday, 19 October 2013 20:17:23 UTC