Re: Holdings-as-Offer: wrap-up

On Wed, Oct 23, 2013 at 10:49 AM, Karen Coyle <kcoyle@kcoyle.net> wrote:
>
>
> On 10/19/13 2:07 PM, Dan Scott wrote:
>
>>
>> Agreed. Perhaps my fault was in not publishing a complete, ideal example
>> that would demonstrate branch relationships, geographic coordinates,
>> contact info, addresses, etc, where each library had its own URL that
>> contained that structured data so that we could link to those pages
>> rather than falling back to Text values. But that would force us to
>> solve all possible problems first before publishing something that
>> should work for the most common use cases.
>>
>> I was assuming that the group would mentally fill in the gaps, similar
>> to how most of the existing schema.org <http://schema.org> examples
>>
>> reflect only a subset of what is possible and ideal.
>
>
> Dan, et al
>
> Given that our proposal does not make any additions to schema.org, and
> doesn't need schema.org approval (AFAIK), we could think of it as the
> beginning of documentation for libraries/library systems wishing to
> implement schema. I think at this point that we should try some full
> examples, to make sure that our "parts" are compatible and complete.
>
> This is somewhat difficult because I don't think we have clear use cases for
> the data. In other words, I don't think we have articulated what we would
> like from the search engines (or even if they are our primary target), nor
> do we have specific non-search engine goals. However, we do have existing
> library system displays, and could start there.
>
> I'm aware of two primary patterns for LIS displays:
> 1) the search result pages, with multiple items on a page
> 2) the individual item pages
>
> We should think of both linking in to systems, and linking out from them.
>
> The first question is: do we anticipate markup of search results pages, or
> only of individual item pages? Note that the former do not always list the
> full holdings information (that depends on the system and the
> implementation) and usually have a minimal bib display.

Every time I've contemplated marking up search results pages, I've
turned away from it; there is very little data to actually mark up.

> The latter *may*
> have a stable URI (and where it doesn't we just have to wait for systems to
> catch up to that, no?). It also has a fuller bib display and probably a full
> holdings list.

Right. So that's where I've focused my efforts. Systems that don't
have stable URIs aren't even worth consideration. One of the common
approaches to feeding search engines is generally to publish sitemaps
that point to individual item pages (whether those items are
bibliographic or home renovation materials). That's what I did with
our local Evergreen instance over a year ago.

> Then, we need to know what our target(s) are. The WorldCat RDFa has the WC
> page for the item as its target. Plugging that into the rich snippet tool I
> get:
>
> A feast of snakes (Book, 1976) [WorldCat.org]
> www.worldcat.org/oclc/2091649
> The excerpt from the page will show up here. The reason we can't show text
> from your webpage is because the text depends on the query the user types.
>
> The target link is for the item page. (I don't know where the rich snipper
> tool gets the properly camel-cased "WorldCat.org" though. ?)

It seems to be from the <title> element of the page.

> Are there any
> other options for targets? For libraries that do not have URIs for items,
> would the target be the catalog? a search URL?

Perhaps we could eventually use the recently added Actions to expose
specific actions on those targets in the same way that specific
actions can be surfaced in Gmail, but I don't think that's fully baked
yet for general usage.

I honestly think, though, if a system can't generate stable URIs, that
it's not worth trying to figure out how it can play in a structured
data world. How does one go back and see what has changed for a given
item?

> The next is: do we anticipate marking up information about the library
> itself on every page? e.g. the name of the library (or consortium), the
> location(s).

I do not anticipate inlining the entire set of pertinent library
information into each page. I expect to use the power of the Web to
link to a page that contains the corresponding info.

> In my browsing of systems, lists of branches, addresses, and
> hours are part of the library web page but are not directly linked to the
> catalog. If one of our goals is to provide location services, is this a
> markup question or an ILS software question?

It is almost always "both". If you don't have the ability to modify
the library system software, you could painstakingly generate your own
library / branch pages that duplicate all of the information that
you've entered into the system (operating hours, holidays, contact
info, etc), but from the perspective of someone who does have the
ability to modify library system software, that's a terrible
alternative to just teaching the system to do the right thing in the
first place. Which I plan to do for Evergreen in the near future (I
still need to investigate what Koha and VuFind have available at the
moment to expose in markup).

> What information does the ILS
> page provide that could be useful if marked up?

I think a number of attributes have been mentioned in passing in this
thread and previous threads. Perhaps someone would like to start a
wiki page to collect these? If no one else gets there before me, then
I'll create and start populating that page as I teach Evergreen the
way of structured data for http://schema.org/Library :)

Received on Wednesday, 23 October 2013 16:23:16 UTC