Can SOBR help publishing library holdings?

2. Dezember 2011 um 01:08 5 Kommentare

I just participated in the German conference Semantic Web in Bibliotheken which took place in Hamburg this week. This year there were two slots for lightning talks, but unfortunately participants did not catch on, so we only had four of them. Lightning talks are a good chance to present something unfinished that you need input for, so I presented the Simplified Ontology for Bibliographic Resources (SOBR) as “FRBR light”. You can find the current specification of SOBR at github, which means the specification is still evolving and I’d like to get more feedback.

SOBR was caused by a discussion on the Library Linked Data mailing list about the (disputed) disjointedness of FRBR classes. SOBR has a history in the Document Availability Information API (DAIA), which SOBR might be merged into. The use case of both is publishing information about holdings from library catalogs as Linked Open Data. The information most requested is probably connected to holdings: library users only ask “where is it?” and “how can I get it?”. In this questions, the little word “it” refers to a specific publication. In the answers, however, “it” usually refers to some holding or copy of this publication. Sometimes the holding contains more than the publication (for instance if you ask for an article in a book) and sometimes you get multiple holdings (for instance if you ask for a a large work that is split in multiple volumes). Sometimes there are multiple holdings with different content to choose from, because there are different editions, forms, translations etc. of the requested publication.

A long time ago, some librarians thought about similar questions and answers and came up with the Functional Requirements for Bibliographic Records (FRBR). I tried hard to accept FRBR (I even draw this ugly diagrams that people find when they look up FRBR in Wikipedia). But FRBR does not help me to publish existing library catalogs as Linked Open Data. In our catalog databases we have records that refer to editions, connected with records that refer to holdings (I’ll ignore the little exceptions and nasty special cases such as multiple holdings described by one look-like-a-holding-record). In addition there are some records that refer to series, works, and other types of abstract documents without direct holdings, which are connected to records that refer to editions.

Maybe we can simplify this to two entities: general documents (bibo:Document) and items (with frbr:Item) as special kind of documents. The current design of SOBR also contains a class for editions, but I am not sure whether this class is also needed. At least we need three properties to relate documents to items (daia:exemplar), to relate documents to editions (daia:edition?) and to relate documents to its parts (dcterms:hasPart). To avoid the need of blank nodes, I’d also define properties that relate documents to partial items (daia:extract = dcterms:hasPart + daia:exemplar) and to relate documents to partial editions (daia:editionPart?)

Feedback on SOBR is welcome, especially if you provide examples with existing URIs (or at least local identifiers to already existing data) instead of theoretical FRBR-like-made-up examples. The best way to find a good ontology for publishing library holdings is to actually publish data that describes library holdings! The following image is based on an example that connects a work from LibraryThing and from DBPedia with a partial edition from Worldcat, a full edition from German National Library, and a holding from Hamburg University:

@prefix bibo: <http://purl.org/ontology/bibo/> .
@prefix daia: <http://purl.org/ontology/daia/> .
@prefix frbr: <http://purl.org/vocab/frbr/core#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix dct: <http://purl.org/dc/terms/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

<http://www.librarything.com/work/70394> a bibo:Document ;
  owl:sameAs <http://dbpedia.org/resource/Living_My_Life> ;
  daia:edition <http://d-nb.info/1001703464> , [
    a bibo:Collection # , daia:Document
    ; dct:hasPart <http://www.worldcat.org/oclc/656754414>
  ]
    ;
  # daia:exemplar <http://d-nb.info/1001703464> ; ?
  daia:editionPart <http://www.worldcat.org/oclc/656754414> .

<http://d-nb.info/1001703464> a frbr:Item , bibo:Document ;
   daia:exemplar <http://uri.gbv.de/document/opac-de-18:epn:1220640794> .



image created with rdfdot

5 Kommentare »

RSS Feed für Kommentare zu diesem Artikel. TrackBack URI

  1. Jakob,

    I like where this is going. I’m going through the slide deck right now. Have you read much of Vuk Milicic’s “Fixing RDF” series (see http://milicicvuk.com/blog/2011/08/10/fixing-the-rdf-model/)?

    We definitely need to deal with blank nodes in our models.

    Kommentar by Tod Robbins — 2. Dezember 2011 #

  2. I would add another question in the row:
    Where is one (item)?
    Wich one (item) is available?
    How can I get one (item)?
    Isn’t it finally all about item as long as it is the print-world or the simulated print world?

    Kommentar by Stefan Farrenkopf — 6. Dezember 2011 #

  3. Hi Tod, Hi Stefan! I read some of Vuk Milicic’s articles, but in summary they are too confusing. I don’t want to remove blank nodes entirely but give a method to express data without having to express a blank node. This can be done with property chains.

    For availability, location and other information about items there is DAIA. The current state of RDF mapping of DAIA is show in this diagram. I’d also like to discuss details of DAIA. A current example is here (in DAIA/XML).

    Kommentar by jakob — 7. Dezember 2011 #

  4. Jakob, I keep thinking about this… My own preference is that there be a whole (which could be called a resource) that includes all of the relevant information about the resource and is not divided into work and edition. Work would then be a separate but related abstraction. A key thing is not to have a dependency between your Edition and Work, so that each is a complete “thing” even without the other. Work then has some redundant information (creator, subjects, title) with Edition, but is also the logical place to link reviews, critical essays, etc. (I think the term “Edition” has implications that you don’t intend, but it’s hard to come up with a single word that feels right.)

    For some reason I am fine with Item being a minimal concept with little information beyond identification; something that can be linked to a circulation event, a purchase event, a discard event. In fact, the library Item could be the same as any other item in a store or warehouse.

    Kommentar by Karen Coyle — 15. Dezember 2011 #

  5. [...] and consuming library loan information as linked open data” (see slides) and I talked about a Simplified Ontology for Bibliographic Resources (SOBR) which is mainly based on the DAIA data model. We are going to align both data models and I [...]

    Pingback by Linked local library data simplified « Jakoblog — Das Weblog von Jakob Voß — 10. Januar 2012 #

Hinterlasse einen Kommentar

XHTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Powered by WordPress with Theme based on Pool theme and Silk Icons.
Entries and comments feeds. Valid XHTML and CSS. ^Top^