Linked local library data simplified

10. Januar 2012 um 14:53 2 Kommentare

A few days ago Lukas Koster wrote an article about local library linked data. He argues that bibliographic data from libraries data as linked data is not “the most interesting type of data that libraries can provide”. Instead “library data that is really unique and interesting is administrative information about holdings and circulation”. So libraries “should focus on holdings and circulation data, and for the rest link to available bibliographic metadata as much as possible.” I fully agree with this statements but not with the exact method how do accomplish the publication of local library data.

Among other project, Koster points to LibraryCloud to aggregate and deliver library metadata, but it looks like they reinvent yet more wheels in form of their own APIS and formats for search and for bibliographic description. Maybe I am wrong about this project, as they just started to collect holding and circulation data.

At the recent Semantic Web in Bibliotheken conference, Magnus Pfeffer gave a presentation about “Publishing 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 hope that the next libraries will first look at these existing solutions instead of inventing yet another data format or ontology. Koster’s proposal, however, looks like such another solution: he argues that “we need an extra explicit level to link physical Items owned by the library or online subscriptions of the library to the appropriate shared network level” and suggests to introduce a “holding” level. So there would be five levels of description:

  • Work
  • Expression
  • Manifestation
  • Holding
  • Item

Apart from the fact that at least one of Work, Expression, Manifestation is dispensable, I disagree with a Holding level above the Item. My current model consists of at most three levels of documents:

  • document as abstract work (frbr:Work, schema:CreativeWork…)
  • bibliographic document (frbr:Manifestation, sobr:Edition…)
  • item as concrete single copy (frbr:Item…)

The term “level” is misleading because these classes are not disjoint. I depicted their relationship in a simple Venn diagram:

For local library data, we are interested in single items, which are copies of general documents or editions. Where do Koster’s “holding” entities fit into this model? He writes “a specific Holding in this way would indicate that a specific library has one or more copies (Items) of a specific edition of a work (Manifestation), or offers access to an online digital article by way of a subscription.” The core concepts as I read them are:

  • “one or more copies (Items)” = frbr:Item
  • “specific edition of a work (Manifestation)” = sobr:Edition or frbr:Manifestation
  • “has one [...] or offer access to” = ???

Instead of creating another entity for holdings, you can express the ability “to have one or offer access to” by DAIA Services. The class daia:Service can be used for an unspecified service and more specific subclasses such as loan, presentation, and openaccess can be used if more is known. Here is a real example with all “levels”:

    a bibo:Book ;
    daia:edition <urn:nbn:de:eki:GBV128382600> ;
        <> .

<urn:nbn:de:eki:GBV128382600> a bibo:Book ;
        <> .

    a bibo:Book, daia:Item ;
    daia:heldBy <> ;
        daia:availableFor [
            a daia:Service ;
            daia:providedBy <>
        ] .

I have only made up the RDF property daia:edition from the SOBR proposal because FRBR relations are too strict. If you know a better relation to directly relate an abstract work to a concrete edition, please let me know.

image created with rdfdot

2 Kommentare »

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

  1. Hi Jakob, thanks for this reaction on my post. I understand that you have a problem with an extra level or entity in the Bibliographic or FRBR model. My short reply is: so what?
    Looking more closely at your and my reasoning I think we are discussing on different levels. ;-)
    Even more, I think we are in complete agreement.

    My extra Holding entity is on the conceptual level. Given the separation of the shared global generic descriptions of bibliographic material (whether there are three or two entities there) and the local holding information, there has to be a link between these two. I call this ‘Holding’, which can be considered a linking entity between two other entities in a conceptual model (like in an Entity Relationship Diagram). The Holding entity has extra value since we can have more than one item of a work/edition in a specific library.
    I was trying to demonstrate that the FRBR model does not cater for this. In fact, as far as I’m concerned, we should split FRBR into a shared global model (with one, two or three entities, or whatever is best) and a local holdings model.

    When implementing a conceptual model, especially in the relational database world (which is my original background) it is not uncustomary that entities on a conceptual level disappear as such and are embedded as links in a table, especially in the case of these pure intermediate entities, consisting only of external IDs (‘Foreign keys’) without any extra information of its own.
    This is exactly what you show in your valid examples, as far as I can see.

    My ‘Holding’ entity could also have been uniquely identified by the URI (or Primary key in ERD terms) of the Library plus the URI of the Manifestation (or Edition or Work or whatever thing we use in the shared global environment). I was just following the rule of thumb that everything should have its own URI, maybe somewhat too enthusiastically.

    Anyway, in this case the link from an Item to the conceptual Holding, implemented in a relational database table would contain the IDs of the Library and the Manifestation/Edition, instead of the ID of the separate Holding record (which in turn would only contain the two IDs of the Library and the Manifestation/Edition).
    Which is exactly what you do with the DAIA/SOBR model Item entity.

    This is perfectly OK for physical local library items, but what about digital online stuff? I guess you would have something like this: ID of Article online + ID of Library. No ID of Item/Exemplar, because there isn’t any. But we do need availability and access conditions here, as you state in your Request for comments: final specification of DAIA post. How would you call this?

    Kommentar by Lukas Koster — 11. Januar 2012 #

  2. Slotocash Casino…

    Linked local library data simplified « Jakoblog — Das Weblog von Jakob Voß…

    Trackback by Slotocash Casino — 25. Dezember 2016 #

Entschuldige, das Kommentarformular ist zurzeit geschlossen.

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