Add per-library TPAC pages with schema.org structured data support

[Dan Scott]

* Evergreen master

In the past, we have added structured data support to describe records and copies to search engines using a common structured data vocabulary (schema.org via RDFa). However, typically the items that are on offer are linked to a "seller"; currently, the copies for each record do not normally point at a seller object, so search engines have no good way of knowing that "BR1" has email and phone contact information, opening hours, one or more addresses, etc.

In the 2.4 series, we added an AOUS that enabled libraries to link their library names in the copy table of the record details page to an external web site. As there was no guarantee that the web site on the other side of that link would provide information useful to a search engine, however, this was not particularly useful. It also suffered a bit from being mystery navigation; the library name was styled as a link, but the user might be surprised that a link in the middle of a details display leads to a different site entirely.

In this branch, we add a new class of pages--library pages--to the TPAC, offering several advantages:

1. The library names link to the TPAC library page, keeping navigation within the TPAC.

2. If the library.info_url AOUS is set, then it appears on the TPAC library page with a clearly labelled "External website" link.

3. The TPAC library page shows opening hours, email and telephone contact info, mailing address, and branch relationships... all of which are currently maintained within Evergreen, but are typically duplicated in external web sites. This gives small libraries a simple "basic library information at a glance" page.

4. The TPAC library page marks all of this up using schema.org in RDFa, clarifying the relationship between the copies and the branches that own them, along with exposing core library information to the web in a meaningful way that the search engines can take advantage of (without having to rely on a central service like OCLC or others to feed that information to the search engines).

5. This may be a bit of a stretch, but a large consortium may want to rely on the data exposed on the TPAC library pages to refresh their own hours of operation / contact information content; given that the library itself is motivated to keep the hours accurate for purposes of correctly generating fines, it reduces the duplication of effort required to maintain the same information in multiple systems. (One could tap the database directly or use OpenSRF APIs but running an RDFa parser against a public HTML page is arguably much simpler).

Thus, I offer up http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dbs/library_schema_org

The TPAC library pages are functional, but they're not the height of design. I certainly welcome enhancements to the display :)

Aside: this branch is easiest to kick the tires of if you merge the branch from bug # 1261896 first, which adds useful sample data for testing purposes. But it's not required, if you like making up your own sample data :)

[Dan Scott (denials)]

Merged current master into the branch and (prompted by a question from Ben Shum on IRC) added one commit that uses the "format.time" OUS to control the formatting of the opening / closing hours for the libraries via the Date plugin for TT2.

Note that we use today's date as the basis for the formatted hours display, as using a static date like "1/1/1000" will undoubtedly lead to daylight savings time misery...

[Dan Scott (denials)]

Pushed one more commit to use "%l" instead of "%H" so that we get "11" instead of "23" for hour display (as we're using AM/PM in the absence of a format.time setting). Thanks again Ben!

[Kathy Lussier (klussier)]

From IRC earlier today:

[09:27:14] <bshum> dbs: bug 1261939 was entertaining. Took me a few moments to figure out that the example.com external URL was being used instead of the hostname/eg/opac/library/shortname path I was initially expecting to get me to a given library page.
[09:27:16] <pinesol_green> Launchpad bug 1261939 in Evergreen "Add per-library TPAC pages with schema.org structured data support" (affected: 1, heat: 6) [Wishlist,New] https://launchpad.net/bugs/1261939
[09:28:35] <bshum> I'm not entirely sure I like that, but we don't get external URLs in our system for org units (yet). So I'm unsure how we'd implement it down the road.
[09:35:25] <dbs> Yes, MassLNC wanted the OUS for a URL to an external library page; the built-in pages just get dropped into place if there's no OUS
[09:35:49] <dbs> Good to expose that OUS via sample data so that people are aware that it exists I guess :)
[09:36:07] <bshum> Hehe
[09:37:36] <bshum> I guess it's just my personal opinion that if we create catalog library pages, I'd like to keep us within the catalog primarily and then have those links out to external library pages based on the OUS at the point you see it on the library info page.
[09:37:49] <bshum> Rather than link straight to the external URLs
[09:37:56] <bshum> But then, I don't use the feature.
[09:38:18] <bshum> So I don't really know.
[09:39:13] <dbs> bshum: sure, we could check with MassLNC to see if that would work for them
[09:39:43] <dbs> I suspect that if they had the built-in library pages to start with, then they might have opted for that design too
[09:40:02] <kmlussier> What exactly is it that you want? The library names to link to the library page which would then link to the external URL?
[09:40:37] <dbs> kmlussier: that's what bshum is suggesting, yes... so that you don't get thrown out of the context of the catalogue when you're just browsing copies
[09:40:52] <dbs> (or at least that's what I think he's saying)
[09:41:09] <kmlussier> Yes, we came up with that idea before there were library pages to link to, but I would need to check with people here to see what they think.

I just checked with my team here. I don't think we would object to it pointing to the library page by default, but we also think there are some sites that will prefer the link to the external web site. I don't think it needs to be a OUS, though. Maybe a setting in config.tt2 or even just a comment in the tt2 file letting people know how to customize the page to link to the external URL?

Also, is there any chance we could change the default label from External web site to Library web site? I know we can customize the language, but I was thinking "Library web site" would be a more user friendly label to use out of the box.

Thanks Dan! I love the page and think patrons will find it very useful!

[Dan Scott (denials)]

Thanks for the feedback, Kathy!

I've gone ahead and a) changed the label to "Library web site", as you suggested and b) added an OUS "lib.prefer_external_url" to control the linking behaviour.

I believe the OUS approach is the best option for allowing per-library control of behaviour in an easily administered fashion.

Now I need to get some release notes together to describe the new functionality, the change in behaviour from 2.5 -> 2.6, and the new OUS that lets sites revert to the previous behaviour if so desired. Any other thoughts? Everything so far has led to very positive improvements; thanks to both Ben and Kathy!

[Dan Scott (denials)]

Merged current master into the branch, added a commit for the upgrade SQL script, and also added a release notes entry in a separate commit. Adding the pullrequest tag accordingly.

[Dan Wells (dbw2)]

I have rebased this branch and pushed it into master. Thanks, Dan! I opted not to squash any commits, as I find seeing the process to be of value historically, and it all seemed understandably linear to me (with no commits I'd consider "trivial").

Praises:
- I think exposing this library data in a public way is a very valuable addition.
- Making it structured data gives it some added value beyond simple exposure.

Concerns:
- The library "about" links added in 2.5 had the same behavior in both the results list (show more details) and the details page. This new feature only affects the details page, and can therefore lead to some confusing interface behavior. It should be easy to add the same logic to the results page, but it remains a TODO.
- This feature adds a large number of (frequently redundant) links to the page. In addition, I don't find it intuitive to predict what these links will do before I click them for the first time. I think a number of installations (mine included) will either not need these links, or will decide they detract more from the focus of the catalog than they add. Unless a feature is a "slam dunk", I am in favor of making it optional (despite the drawbacks).

Questions:
- Should we consider making some display changes to help clarify the links? For instance, perhaps something as simple as a 'title' attribute which says something like 'See library hours and contact information'? Or what about using small icons (with alt text) to identify either the external links, the 'info' links, or both? I think if we are consistent with applying such conventions, we could get a lot of usability with minimal disruption to the 'normal' flow of the catalog.

I pushed this branch since I felt that all of this could be addressed (or not, as needed) in an ongoing way. Thanks again, Dan!

[Dan Scott (denials)]

I have created bug # 1271600 with a pullrequest for making the copy table in search results behave consistently with the copy table in record details. Thanks for catching that, Dan! I'm going to move other comments into a -dev thread.