Links Sammeln und Verteilen mit BEACON

12. Juni 2012 um 12:45 9 Kommentare

Seit ich Ende letzten Jahres auf der Semantic Web in Bibliotheken (SWIB11) einen Vortrag zur Linkaggregation mit BEACON gehalten haben (hier der Mitschnitt) hat sich einiges getan.

Das BEACON-Format wurde ursprünglich Anfang 2010 von Mathias Schindler als ad-hoc Lösung vorgeschlagen, um über Identifier der Gemeinsame Normdatei (GND) zwischen Wikipedia-Artikeln und passenden Webseiten in Personenlexika und Bibliothekskatalogen zu verlinken. Beispielsweise findet sich Literatur zu Tina Modotti im Katalog der Bayerischen Staatsbibliothek (BSB) unter folgender URL:

http://opacplus.bsb-muenchen.de/search?pnd=11858295X

Die URI des GND-Eintrags von Modotti ist:

http://d-nb.info/gnd/11858295X

Sofern die Links einheitlich aufgebaut sind, reicht für die Verknüpfung in einer BEACON-Datei die GND-Nummer 11858295X aus. Zusätzlich kann beispielsweise die Anzahl der Treffer im BSB-Katalog (momentan acht) angegeben werden. Hier ein Beispiel für eine BEACON-Datei:

#FORMAT: BEACON
#PREFIX: http://d-nb.info/gnd/
#TARGET: http://opacplus.bsb-muenchen.de/search?pnd={ID}
#DESCRIPTION: Links auf Literatur zu Personen im Katalog der BSB
#MESSAGE: {annotation} Einträge im BSB-Katalog

11858295X|8

Diese einfache Form der Weitergabe von Links hat sich inzwischen durchgesetzt und es sind zahlreiche BEACON-Dateien verfügbar. Wie bei ad-hoc Standards üblich, haben sich allerdings unterschiedliche Interpretationen und Erweiterungen von BEACON entwickelt. Wir sind deshalb dabei, BEACON endgültig exakt zu spezifizieren, um es schließlich als Internet-Standard (RFC) zu verabschieden. Die Entwicklung kann auf github verfolgt werden, wobei der aktuelle Stand hier (HTML) bzw. hier (TXT) einsehbar ist.

Im wesentlichen muss zum Verständnis von BEACON zwischen zwei Ebenen unterschieden werden: Ein BEACON Link Dump ist eine Menge von einheitlich aufgebautem Links, die ggf. mit einigen Metadaten angereichert ist. In welchem Format die Links gespeichert werden, ist davon unabhängig. Jeder Link besteht aus genau vier Teilen:

  • Einer Quelle (link source), beispielsweise der URL
    http://d-nb.info/gnd/11858295X
  • Einem Ziel (link target), beispielsweise der URL
    http://opacplus.bsb-muenchen.de/search?pnd=11858295X
  • Einem Beziehungstyp (link relation type), beispielsweise der URI
    http://www.w3.org/2000/01/rdf-schema#seeAlso
  • Einer Anmerkung (link annotation), beispielsweise der Zeichenkette
    8 Einträge im BSB-Katalog.

Der Beziehungstyp ist für alle Links in einem BEACON Link Dump gleich. Quelle, Ziel und Anmerkung können bei der Speicherung abgekürzt werden. Die Form zur Speicherung und Weitergabe (Serialisierung) ist die Zweite Ebene von BEACON. Neben dem ursprünglichen BEACON-Text-Format gibt es ein einfaches BEACON-XML-Format. Das oben angegebene Beispiel könnte in BEACON-XML folgendermaßen ausgedrückt werden:

<?xml version="1.0" encoding="UTF-8"?>
<beacon xmlns="http://purl.org/net/beacon"
       prefix="http://d-nb.info/gnd/"
       target="http://opacplus.bsb-muenchen.de/search?pnd="
  description="Links auf Literatur zu Personen im Katalog der BSB"
      message="{annotation} Einträge im BSB-Katalog">
   <link source="11858295X" annotation="8" />
</beacon>

Daneben können Links aus BEACON auch nach RDF übersetzt werden, was für die Anwendung als Linked Open Data von Bedeutung ist. Der Link in RDF/Turtle-Syntax (hier ohne Anmerkung) wäre bswp.:

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
<http://d-nb.info/gnd/11858295X>
rdfs:seeAlso 
<http://opacplus.bsb-muenchen.de/search?pnd=11858295X> .

Zum Ausdrücken der Anmerkung eines Links ist das Meta-Feld „qualifier“ vorgeschlagen, so dass sich BEACON Dumps auch vollständig in RDF übertragen lassen. In jedem Fall ist BEACON nicht auf GND-Nummern beschränkt und Quelle und Ziel müssen nicht zwangsläufig eine gemeinsame ID verwenden. So stellt beispielsweise lobid.org ein Mapping zwischen Lobid-URIs und Wikipedia-Artikeln bereit. Die dabei verwendete Form von BEACON weicht noch etwas vom endgültigen BEACON-Standard ab. Auch aus diesem Grund benötigen wir zum Aktuellen Entwurf des BEACON-Spezifkation noch Feedback und Korrekturleser.

Linked local library data simplified

10. Januar 2012 um 14:53 1 Kommentar

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“:


<http://dbpedia.org/resource/Tractatus_Logico-Philosophicus>
    a bibo:Book ;
    daia:edition <urn:nbn:de:eki:GBV128382600> ;
    daia:exemplar
        <http://uri.gbv.de/document/opac-de-23:epn:266449999> .

<urn:nbn:de:eki:GBV128382600> a bibo:Book ;
    daia:exemplar
        <http://uri.gbv.de/document/opac-de-23:epn:266449999> .

<http://uri.gbv.de/document/opac-de-23:epn:266449999>
    a bibo:Book, daia:Item ;
    daia:heldBy <http://uri.gbv.de/organization/isil/DE-23> ;
        daia:availableFor [
            a daia:Service ;
            daia:providedBy <http://uri.gbv.de/organization/isil/DE-23>
        ] .

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

Europeana-Daten teilweise als Linked Data

21. Juni 2011 um 13:09 1 Kommentar

Wie auf public-lld angekündigt, bietet Europeana seit gestern einige Daten, die von verschiedenen europäischen Kultureinrichtungen aggregiert werden, als Linked Open Data an. Der Testzugang mit Beschreibung ist unter data.europeana.eu, während im Europeana-Blog noch nichts dazu steht. Und so kommt man an die Daten: Es gibt sowohl zeinen großen Datenbankdump (etwa 1GB gepackt, 185 Millione Tripel) als auch kleinere Teile zum Herunterladen. Um die URIs einzelner Datensätze herauszubekommen, ist noch etwas Handarbeit notwendig:

  1. Suche im Europeana-Portal
  2. Einschränken des Suchergebnis auf „Free Access“
  3. Auswahl eines Datensatz
  4. Entfernen der HTTP-Query-Parameter und der Dateiendung .html von der URL, z.B. http://europeana.eu/portal/record/09428/DB8CA8BB4FABF5AE7F1B93FD6672D30A6B94B343
  5. Ersetze http://europeana.eu/portal/record/ durch http://data.europeana.eu/item/, also zum Beispiel http://data.europeana.eu/item/09428/DB8CA8BB4FABF5AE7F1B93FD6672D30A6B94B343

Dummerweise ist damit noch nicht sicher gestellt, dass über diese URI auch RDF-Daten abgerufen werden können, da bislang nur einige Institutionen am Europeana-LOD-Pilot teilnehmen. Auch bei anderen Beispielen aus meiner Suche bekomme ich eher eine Fehlermeldung. Die in der Dokumentation angegebenen Beispiele funktionieren aber. Also gibt es erstmal keine Verknüpfung zum Normdatensatz von Livia Drusilla. Beim Ausprobieren ist mir aufgefallen, dass die Europeana-Server etwas lahm sind und dass es mir unmöglich war, sinnvoll etwas zu finden, da die meisten Objekte als „Image“ gekennzeichnet sind, statt als „Gemälde“, „Statue“, „Münze“ etc. Für praktische Linked-Data-Anwendungen wäre es hilfreich, die Suche auf Objekte einzuschränken zu können, deren Daten als Linked Data verfügbar sind.

Alles in Allem ist der Pilot ein guter Schritt in die richtige Richtung, aber noch etwas wackelig. Da es sich explizit um einen Beta-Test handelt, sollte man jedoch nicht allzu kritisch sein, sondern erstmal mit den Daten herumspielen oder abwarten was noch kommt.

Query parts in Linked Data URIs considered harmful

29. Mai 2011 um 01:40 Keine Kommentare

The generic syntax of URI (and of IRI with slightly different definition of the elements) is:

<scheme name> : <hierarchical part> [ ? <query> ] [ # <fragment> ]

RDF is based on „URI references“ which have a different syntax, but all practical RDF data should follow the generic URI syntax. This is also implied by the Linked Data Principles which encourage you to use HTTP URIs. Furthermore it is a good advice not to include fragments in your URIs if you care about coexistence of the Web and the Semantic Web. Yes, there is RDF data with fragment parts and the so called Hash URIs are even given as one design pattern, but you can avoid a lot of trouble if you use URIs without them. By the way, fragment identifiers are also used a lot in JavaScript-based web applications that spoil the whole concept of REST as described in this recent in-depth article on Hash URIs.

I would even go further and say that well-designed URIs for Linked Data should also forgo the query part. A clean URI to be used as identifier in Linked Data should stick to this limited generic syntax:

http: <hierarchical part>

I do not argue to disallow URIs with query part, but I wonder how much they are really used and needed for resources other than Web resources. Especially URIs for non-information resources, should not have a query part. Most web applications will not distinguish between these two:

http://example.org?foo=1&bar=2
http://example.org?bar=2&foo=1

These are different URIs but equivalent URLs. Choosing URIs that are not equivalent to other URIs in common non-RDF applications is a good advice, isn’t it? If you choose a cleaner URI like http://example.org/foobar you could use additional query parts to refer to different representations (information resources) and services around the resource that is referenced by the base URI.