Re: Holdings-as-Offer: wrap-up

I don't think we should assume that branch names are structured. I checked out a book yesterday at "The Arcanaeum", which is a branch of "The College of Winterhold Library System".

Sent from my iPad

> On Oct 19, 2013, at 4:17 PM, "Karen Coyle" <kcoyle@kcoyle.net> wrote:
> 
> 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:27:01 UTC