In a previous exercise, you marked
up holdings in a catalog page with the
schema.org vocabulary using RDFa
attributes. However, when you identified the library that holds a given
copy of a resource, you only used a text string--and as there are many
library branches named "Main Branch" or "Central Library" in the world,
general consumers of your structured data such as search engines may
not be able to determine basic information such as where your library
is located, and fail to connect potential patrons with your library's
resources. In this exercise, you will mark up library web pages with
address information, contact information, and opening hours, then link
your catalog pages to the library web pages to complete the relationship
between your resources and your library.
When you search for a library on different search engines, you will
probably get different and conflicting sets of information about the
library. The results often depend on where the information is pulled
from, which in turn depends on relationships that the search engines
have with various data providers. For example, comparing searching
for my home library J.N. Desmarais Library:
Google returns a rich result complete with contact information and
hours of operation because we maintain a Google+ page for the
library;
Bing returns a slightly enhanced result with just location,
phone number, and web site because the data comes from Foursquare;
OpenStreetMap currently returns nothing because points of interest
must be manually entered--but could offer rich data such as hours
of operation.
DuckDuckGo offers basic search results, but could offer richer
results if our library was registered on Yelp.
This is a sad state of affairs, and while our library certainly could
work harder on outreach and search engine optimization, we are hardly
alone.
Having to maintain information such as address, contact information,
and hours of operation in multiple places is inefficient and
error-prone. Rather than pushing information to multiple sites, it
makes much more sense to allow interested sites to pull the information
from one authoritative source. OCLC has positioned
themselves to provide this information to the various commercial
companies, but the simplest possible method would be for libraries to
simply mark up their own library home pages (where that information
almost certainly already exists for the benefit of human readers) with
the relevant schema.org structured data so that the machines can
benefit as well.
Audience:Intermediate
Prerequisites:To
complete this codelab, you should already be familiar with HTML, RDFa,
and schema.org. The previous
exercise offers a practical introduction to those concepts.
Identifying the Library entity
The core information that many users want to find when they look for a
business online include locations, operating hours, contact
information, and branch relationships. For libraries, schema.org models
this information in the Organization->LocalBusiness->Library hierarchy.
In this exercise, you will take a simple library web page and
identify some of the core information in it using the
Library type and its properties.
View the library page source HTML
Open step1/centennial_branch.html
in a text editor. You should see something like the following HTML source for
the web page:
Note: In a pinch, you can use the browser development tools to
view and edit the source of the web page (CTRL-Shift-i in
Chrome or Firefox, in the Elements or Inspector tab
respectively).
Declare the core type of the page as Library
Edit the <body> element to include your @vocab
declaration for the schema.org vocabulary, add a @typeof value of
Library, and set a
@resource value. Check the results with one or more of the
structured data testing tools.
Mark the basic name, image, and description properties
As most schema.org types inherit from Thing, some of the core
properties are name,
image, and description.
These properties are often used to generate rich snippets (short
summaries displayed in search results).
Declare the appropriate name, image, and
description properties for this library.
Identifying the address for the branch helps consuming applications provide
a geographic context for their users. For example, the application could
order search results based on proximity to the searcher's own geolocation.
The Organization
type from which Library inherits includes a address property for this
purpose. address expects a PostalAddress
entity for its value, which includes the following properties:
addressCountry
The country for the address, in
either plain text or ISO 3166-1 alpha2
format.
Operating hours are one of the most frequently consulted pieces of
information for any organization. The schema.org vocabulary provides
two different ways of marking up operating hours. In this exercise,
you will use the much more structured openingHoursSpecification
(which was derived from the GoodRelations vocabulary)
instead of the similarly named but less structured openingHours.
The openingHoursSpecification property expects a OpeningHoursSpecification
type, which is composed of the following properties:
closes
The time at which the business closes, in
hh:mm:ss[Z|(+|-)hh:mm] format.
dayOfWeek
Use the following values:
Day
Value
Monday
http://purl.org/goodrelations/v1#Monday
Tuesday
http://purl.org/goodrelations/v1#Tuesday
Wednesday
http://purl.org/goodrelations/v1#Wednesday
Thursday
http://purl.org/goodrelations/v1#Thursday
Friday
http://purl.org/goodrelations/v1#Friday
Saturday
http://purl.org/goodrelations/v1#Saturday
Sunday
http://purl.org/goodrelations/v1#Sunday
Public holidays
http://purl.org/goodrelations/v1#PublicHolidays
opens
The time at which the business opens, in
hh:mm:ss[Z|(+|-)hh:mm] format.
validFrom
The point in time when the opening hours data becomes valid.
validThrough
The point in time when the opening hours data will no longer be valid.
Given this information, mark up the operating hours for this branch.
Library patrons frequently want to find an email address or telephone
number to contact their library. The
contactPoint
property from Organization expects a
ContactPoint
type, which bundles together contact properties such as
email and
telephone.
Use a ContactPoint entity to define the telephone
property for your branch. Note: although it is not required by
schema.org, providing a machine-readable telephone number via a
content attribute is recommended by
Google and therefore probably a good idea.
In this exercise, you learned how to express locations, operating hours,
and contact information for a library branch.
Linking holdings to a library entity
When you marked up holdings in your catalog page in the previous exercise,
you simply used the name of the library as the value of the
seller property. However, the seller property
expects an Organization, not a text value. Now that you
have marked up your library branch web page as a Library
entity, you can link your holdings directly to the entity in your
library branch web page. This provides much more contextual information
about that holding (such as location, hours of operation, and contact
information) to consumers of your linked data.
Edit step1/rdfa_book.html to link the
"Centennial Hills YPL" holdings to the Library entity in your
library branch web page.
