Book scroll © Henk-Jan van der Klis

2009 is the year of the e-book, or perhaps better: of the e-book reader. This is an important distinction that I will explain below. E-books are becoming more popular because of the increasing availability of various cheap e-book readers.
But what is an e-book? Is it the same as a book? Some people say yes, some people say no. This question shouldn’t be so hard to answer, should it? We just have to define what a book is first. So, what is a book?

When people think of a book, they picture something like the archetypal book: printed, medium sized, hardcover, no illustrations on the front. The thing that you can actually hold in your hands and read.
But if they say: “This book was written by that author”, they don’t think that the author actually wrote that particular item they are holding in their hands. Now we already have two different meanings of the concept “book”: one is a tangible object, the other is the content that is made available in this tangible object by means of printed text.

Besides these conceptual levels, there are more ways by which books can be described, as shown by this incomplete list of examples:

Physical form: Historically there have been clay tablets, inscribed stones, handwritten scrolls, handwritten bound pages, printed pages. We also know different formats targeted at specific uses or audiences: audio books, braille books, pop up books.

Popup book © doegox

Content: A book can contain text only, or images only (for instance a children’s picture book, or a book of photographs), or a combination of both.

Units: A book can consist of one “story” ( for instance a novel), optionally subdivided in chapters, or be made up of several stories, or articles (like a text book about a certain subject). Chapters and stories can be written by the same or by several authors. A book can also contain two or more other books by the same author (“collected works”), etc.

Content type: A book can contain fiction, aimed at entertaining readers. Books can be purely administrative, like accounting books. There are religious books to be used in religious ceremonies (sometimes these are referred to as “THE book“). Some books are for studying and learning (“text books”, which may also contain images by the way). There are scientific books and instructional books (travel guides, cook books, manuals).

First, we need see how all this fits together before we can answer the question “Is an e-book a book?” or more precise: “In which sense is an e-book a book?“. Fortunately there is already a conceptual model for bibliographic entities and the relationships between them that describes this: FRBR (Functional Requirements for Bibliographic Records), published by IFLA. The IFLA Final Report (2009 version) says it all, but there are also a couple of short summaries: Barbara Tillet’s (LoC) “What is FRBR?”, Jenn Riley’s “FRBR” blog post, and there is William Denton‘s FRBR Blog for more information.
The FRBR model is targeted at libraries, maybe even at publishers and booksellers too.

I will not go into the FRBR “Group 2” (persons and corporate bodies) and “Group 3” (subjects) entities here, but focus on the “Group 1” entities.

The FRBR “Group 1 entities” consist of Work, Expression, Manifestation and Item (also referred to as WEMI). FRBR entities not only apply to books or textual works, but also to movies, theater plays, music, etc.

• Work - a distinct intellectual or artistic creation
• Expression - the intellectual or artistic realization of a work
• Manifestation - the physical embodiment of an expression of a work
• Item - a single exemplar (or copy) of a manifestation

FRBR Model © Library of Congress/Barbara Tillett

• A work (for instance a book) can have (“is realized through“) one or more expressions (for instance the original English text and the Dutch translation).
• Each expression can have (“is embodied in“) one or more manifestations (for instance a specific edition with an ISBN, or one of more works/expressions in a “collected works” edition).
• Each manifestation has (“is exemplified by“) one or more items, the things you can actually hold in your hands.
• A manifestation can also consist of several expressions, as in the “collected works” example.

Besides these hierarchical relationships between different entity types there are also recursive relationships between entities of the same type: hierarchical and other. Some examples:

• A work is part of another work (hierarchical), as in a series like Harry Potter
• A work is an adaptation of another work
• An expression is a sequel to another expression
• A manifestation is a facsimile of another manifestation

So far so good. The FRBR conceptual model describes (or aims to describe) real world things and relationships on an abstract level. The model can be implemented in actual systems (both computerised and manual!). In these systems you are free to refer to the conceptual model entities (“work”, “expression”, “manifestation”, “item”) by names that are actually used in daily life. This is what Rob Styles is trying to do when he talks about “stories” and “editions” in his recent blog post “Bringing FRBR Down to Earth…” I think. I will define the “story” concept in a  different way below.

Until now, catalogers and library systems have been targeted at describing the thing they have in their hands (or better the items that make up the library’s collection).  In FRBR terms this means that catalogs describe manifestations and items, not works and expressions (or implicitly at best). In short, a bottom up approach. This is understandable, because in the past there was nothing else to go by than the explicit manifestation information available on the physical item (author, title, ISBN, edition, publisher, etc.) .
Of course, MARC21 provides some options to describe relationships with expressions and works and other manifestations, like the 250 – Edition Statement, the 490 – Series Statement and the 76X-78X – Linking Entries-General Information. But these fields can only be used if the information is known to the cataloger.
Also, in traditional catalogs, works that are distinct expressions in one manifestation (like articles, chapters, stories, poems) are not described separately, because of the same reason: you only catalog the item you have before you. In the ideal world, or better in the new digital world, the unit to be cataloged or described should always be the work, which we may call “story”. In other words: we should catalog units of content (“stories”) instead of, or supplementary to, physical items.
Current library practice is that we catalog books and journals in the catalog and offer article descriptions through subscribed article metadata databases separately.

So, back to the e-book. Where does that fit in? An e-book could be considered nothing more than a manifestation and/or an item belonging to a certain work/expression, because an e-book can be everything a printed book is. As such it is equivalent to a braille or audio book. Some libraries treat e-books as something different, as works/expressions as such. They catalog e-books separately, just like all other items/manifestations are treated as separate works. There are even separate e-book overviews.

E-book reader © alfi

But there is more to it than that. The big difference with books until now is that an e-book is not inseparably linked to the physical carrier. A printed book can only be read if the reader has a physical copy (a FRBR item) consisting of bound paper pages containing the text printed on them with ink. The same applies to handwritten texts, scrolls, clay tablets, etc.
Even more so, the physical form, together with economical conditions and possibilities for distribution, often determines the actual manifestation of a book and a journal. A book (or volume) can only contain a certain number of pages in order to be manageable. There is also a cost consideration in the size and distribution of the items.

What we call an e-book is actually only a digital, abstract manifestation of a work/expression. In order to be able to read it you have to download it in a specific format (PDF, epub, etc.) onto a physical carrier (USB-stick, computer disk, etc.), and then you need a physical reading device with dedicated software (dedicated e-book readers like Kindle, a computer, a mobile phone, etc.).
Libraries do not have e-books as items, only as manifestations. These e-book manifestations can be available on an online server somewhere in whatever form, and can be made into an item on-the-fly, using a specific format on-the-fly, choosing a physical carrier on-the-fly. What’s more, the content of e-books can also be selected out of several works/expressions on-the-fly, this way creating manifestations or even expressions on demand.

Now, is the FRBR conceptual model suited for describing e-books? If we treat e-books as manifestations without items (like we handle e-journals in our catalogs), how do we proceed? The FRBR Manifestation item among others has these attributes:

© PhOtOnQuAnTiQuE

Some time after I wrote “UMR – Unified Metadata Resources“, I came across Chris Keene’s post “Linked data & RDF : draft notes for comment“, “just a list of links and notes” about Linked Data, RDF and the Semantic Web, put together to start collecting information about “a topic that will greatly impact on the Library / Information management world“.

While reading this post and working my way through the links on that page, I started realising that Linked Data is exactly what I tried to describe as One single web page as the single identifier of every book, author or subject. I did mention Semantic Web, URI’s and RDF, but the term “Linked Data” as a separate protocol had escaped me.

The concept of Linked Data was described by Tim Berners Lee, the inventor of the World Wide Web. Whereas the World Wide Web links documents (pages, files, images), which are basically resources about things, (“Information Resources” in Semantic Web terms), Linked Data (or the Semantic Web) links raw data and real life things (“Non-Information Resources”).

There are several definitions of Linked Data on the web, but here is my attempt to give a simple definition of it (loosely based on the definition in Structured Dynamics’ Linked Data FAQ):

I will try to illustrate the different aspects using some examples from the library world. The article is rather long, because of the nature of the subject, then again the individual sections are a bit short. But I do supply a lot of links for further reading.

Data is relationships
The important thing is that “data is relationships“, as Tim Berners Lee says in his recent presentation for TED.
Before going into relationships between things, I have to point out the important distinction between abstract concepts and real life things, which are “manifestations” of the concepts. In Object modeling these are called “classes” (abstract concepts, types of things) and “objects” (real life things, or “instances” of “classes“).

Examples:

• the class book can have the instances/objects “Cloud Atlas“, “Moby Dick“, etc.
• the class person can have the instances/objects “David Mitchell“, “Herman Melville“, etc.

In the Semantic Web/RDF model the concept of triples is used to describe a relationship between two things: subject – predicate – object, meaning: a thing has a relation to another thing, in the broadest sense:

• a book (subject) is written by (predicate) a person (object)

You can also reverse this relationship:

• a person (subject) is the author of (predicate) a book (object)

Triple

The person in question is only an author because of his or her relationship to the book. The same person can also be a mother of three children, an employee of a library, and a speaker at a conference.
Moreover, and this is important: there can be more than one relationship between the same two classes or types of things. A book (subject) can also be about (predicate) a person (object). In this case the person is a “subject” of the book, that can be described by a “keyword”, “subject heading”, or whatever term is used. A special case would be a book, written by someone about himself (an autobiography).

The problem with most legacy systems, and library catalogues as an example of these, is that a record for let’s say a book contains one or more fields for the author (or at best a link to an entry in an authority file or thesaurus), and separately one or more fields for subjects. This way it is not possible to see books written by an author and books about the same author in one view, without using all kinds of workarounds, link resolvers or mash-ups.
Using two different relationships that link to the same thing would provide for an actual view or representation of the real world situation.

Another important option of Linked Data/RDF: a certain thing can have as a property a link to a concept (or “class”) , describing the nature of the thing: “object Cloud Atlas” has type “book“; “object David Mitchell” has type “person“; “object Cloud Atlas” is written by “object David Mitchell“.

And of course, the property/relationship/predicate can also link to a concept describing the nature of the link.

Anywhere on the web

ERD

So far so good. But you may argue that this relationship theory is not very new. Absolutely right, but up until now this data-relationship concept has mainly been used with a view to the inside, focused on the area of the specific information system in question, because of the nature and the limitations of the available technology and infrastructure.

The “triple” model is of course exactly the same as the long standing methodology of Entity Relationship Diagrams (ERD), with which relationships between entities (=”classes“) are described. An ERD is typically used to generate a database that contains data in a specific information system. But ERD’s could just as well be used to describe Linked Data on the web.

Information systems, such as library catalogs, have been, and still are, for the greatest part closed containers of data, or “silos” without connections between them, as Tim Berners Lee also mentions in his TED presentation.

Lots of these silo systems are accessible with web interfaces, but this does not mean that items in these closed systems with dedicated web front ends can be linked to items in other databases or web pages. Of course these systems can have API‘s that allow system developers to create scripts to get related information from other systems and incorporate that external information in the search results of the calling system. This is what is being done in web 2.0 with so-called mash-ups.
But in this situation you need developers who know how to make scripts using specific scripting languages for all the different proprietary API’s that are being supported for all the individual systems.
If Linked Data was a global standard and all open and closed systems and websites supported RDF, then all these links would be available automatically to RDF enabled browser and client software, using SPARQL, the RDF Query Language.

• Linked Data/RDF can be regarded as a universal API.

The good thing about Linked Data is, that it is possible to use Linked Data mechanisms to link to legacy data in silo databases. You just need to provide an RDF wrapper for the legacy system, like has been done with the Library of Congress Subject Headings.

Some examples of available tools for exposing legacy data as RDF:

• Triplify – a web applications plugin that converts relational database structures into RDF triples
• D2R Server – a tool for publishing relational databases on the Semantic Web
• wp-RDFa – a wordpress plugin that adds some RDF information about Author and Title to WordPress blog posts

Of course, RDF that is generated like this will very probably only expose objects to link TO, not links to RDF objects external to the system.

Also, Linked Data can be used within legacy systems, for mixing legacy and RDF data, open and closed access data, etc. In this case we have RDF triples that have a subject URI from one data source and an object URI from another data source. In a situation with interlinked systems it would for instance be possible to see that the author of a specific book (data from a library catalog) is also speaking at a specific conference (data from a conference website). Objects linked together on the web using RDF triples are also known as an “RDF graph”. With RDF-aware client software it is possible to navigate through all the links to retrieve additional information about an object.

Linked Data

URI’s
URI’s (“Uniform Resource Identifiers”) are necessary for uniquely identifying and linking to resources on the web. A URI is basically a string that identifies a thing or resource on the web. All “Information Resources”, or WWW pages, documents, etc. have a URI, which is commonly known as a URL (Uniform Resource Locator).

With Linked Data we are looking at identifying “Non-information Resources” or “real world objects” (people, concepts, things, even imaginary things), not web pages that contain information about these real world objects. But it is a little more complicated than that. In order to honour the requirement that a thing and its relations can be interpreted and used by humans and software, we need at least 3 different representations of one resource (see: How to publish Linked Data on the web):

• Resource identifier URI (identifies the real world object, the concept, as such)
• RDF document URI (a document readable for semantic web applications, containing the real world object’s RDF data and relationships with other objects)
• HTML document URI (a document readable for humans, with information about the real world object)

Redirection

For instance, there could be a Resource Identifier URI for a book called “Cloud Atlas“. The web resource at that URI can redirect an RDF enabled browser to the RDF document URI, which contains RDF data describing the book and its properties and relationships. A normal HTML web browser would be redirected to the HTML document URI, for instance a web page about the book at the publisher’s website.

There are several methods of redirecting browsers and application to the required representation of the resource. See Cool URIs for the Semantic Web for technical details.

There are also RDF enabled browsers that transform RDF into web pages readable by humans, like the FireFox addon “Tabulator“, or the web based Disco and Marbles browsers, both hosted at the Free University Berlin.

RDF, vocabularies, ontologies
RDF or Resource Description Framework, is, like the name suggests, just a framework. It uses XML (or a simpler non-XML method N3) to describe resources by means of relationships. RDF can be implemented in vocabularies or ontologies, which are sets of RDF classes describing objects and relationships for a given field.
Basically, anybody can create an RDF vocabulary by publishing an RDF document defining the classes and properties of the vocabulary, at a URI on the web. The vocabulary can then be used in a resource by referring to the namespace (the URI) and the classes in that RDF document.

A nice and useful feature of RDF is that more than one vocabularies can be mixed and used in one resource.
Also, a vocabulary itself can reference other vocabularies and thereby inherit well established classes and properties from other RDF documents.
Another very useful feature of RDF is that objects can be linked to similar object resources describing the same real world thing. This way confusion about which object we are talking about, can be avoided.

A couple of existing and well used RDF vocabularies/ontologies:

• RDF – the base RDF vocabulary
• RDFS (for RDF Schema)
• DC (for Dublin Core)
• FOAF (for FOAF- Friend of a Friend) – online identities and social networks
• SKOS (for SKOS – Simple Knowledge Organisation System) – thesauri, classification schemes, subject heading systems and taxonomies
• OWL (for OWL -Ontology Web Language)

(By the way,  the links in the first column (to the RDF files themselves) may act as an illustration of the redirection mechanism described before. Some of them may link to either the RDF file with the vocabulary definition itself, or to a page about the vocabulary, depending on the type of browser you use: rdf-aware or not.)

A special case is:

• RDFa – a sort of microformat without a vocabulary of its own, which relies on other vocabularies for turning XHTML page attributes into RDF

Example
A shortened example for “Cloud Atlas” by David Mitchell from the RDF BookMashup at the Free University Berlin, which uses a number of different vocabularies:

A partial view on this RDF file with the Marbles browser:

RDF browser view

See also the same example in the Disco RDF browser.

Library implementations
It seems obvious that Linked Data can be very useful in providing a generic infrastructure for linking data, metadata and objects, available in numerous types of data stores, in the online library world. With such a networked online data structure, it would be fairly easy to create all kinds of discovery interfaces for bibliographic data and objects. Moreover, it would also be possible to link to non-bibliographic data that might interest the users of these interfaces.

A brief and incomplete list of some library related Linked Data projects, some of which already mentioned above:

• RDF BookMashup – Integration of Web 2.0 data sources like Amazon, Google or Yahoo into the Semantic Web.
• Library of Congress Authorities – Exposing LoC Autorities and Vocabularies to the web using URI’s
• DBPedia – Exposing structured data from WikiPedia to the web
• LIBRIS – Linked Data interface to Swedish LIBRIS Union catalog
• Scriblio+Wordpress+Triplify – “A social, semantic OPAC Union Catalogue”

And what about MARC, AACR2 and RDA? Is there a role for them in the Linked Data environment? RDA is supposed to be the successor of AACR2 as a content standard that can be used with MARC, but also with other encoding standards like MODS or Dublin Core.
The RDA Entity Relationship Diagram, that incorporates FRBR as well, can of course easily be implemented as an RDF vocabulary, that could be used to create a universal Linked Data library network. It really does not matter what kind of internal data format the connected systems use.