Archiv der Kategorie: Software-Entwicklung

Linked-Data-Praxis: Daten bereitstellen und verwerten

In Ausgabe 02/2013 der Zeitschrift java aktuell wurde ein Praxisartikel von mir zum Thema Linked Data veröffentlicht:

Ein Artikel in der letzten Ausgabe hat in die Grundlagen von Linked Data eingeführt und gezeigt, wie daraus ein Web aus Daten entstehen kann. Linked Data ist jedoch keine bloße Theorie: Mit wenigen Zeilen Code kann eine Anwendung Teil dieses Daten-Webs werden. Der Beitrag zeigt, wie man Linked Data veröffentlichen und in seinen Anwendungen verwerten kann.

Im Artikel wird ein Hotel-Service beschrieben, der Hotel-Informationen als Linked Data verfügbar macht. Eine weitere Anwendung konsumiert diese Daten um die Bewertung der Hotels zu ermöglichen. Der beschriebene Hotel-Service ist unter http://hotels.datenwissen.de/ online. Die Hotel-Bewertung ist über http://hotel-rating.datenwissen.de/ möglich. Beide Anwendungen sind Open Source und auf github verfügbar (Hotel-Service, Bewertungsplattform).

Den Artikel könnt ihr hier als PDF herunterladen.

Alle meine Artikel sind ab sofort auch hier verfügbar.

groovyrdf vereinfacht WebID-Publizierung

In Version 0.2.1 vereinfacht groovyrdf nun auch die Veröffentlichung von RSA-Public-Keys. Dazu muss einfach die Methode ‚publicKey‘ innerhalb der den Key besitzenden Resource aufgerufen werden. In folgendem Beispiel bekommt Alice einen Public Key zugewiesen:

RdfData rdfData = rdfBuilder {
  "http://example.com/resource/alice" {
    publicKey (
      '#alicePublicKey',
      label: 'Public Key of Alice',
      modulus: '2cbf8fff963dea33ee7d4f007ae',
      exponent: 65537
    )
  }
}

Der obige Code erzeugt RDF gemäß der aktuellen WebID-Spezifikation:


<http://example.com/resource/alice>
 <http://www.w3.org/ns/auth/cert#key>
 <#alicePublicKey>.

<#alicePublicKey>
 a <http://www.w3.org/ns/auth/cert#RSAPublicKey>;
 <http://www.w3.org/2000/01/rdf-schema#label>
   "Public Key of Alice";
 <http://www.w3.org/ns/auth/cert#exponent>
   65537;
 <http://www.w3.org/ns/auth/cert#modulus>
   "2cbf8fff963dea33ee7d4f007ae"^^<http://www.w3.org/2001/XMLSchema#hexBinary> .

groovyrdf steht hier zum Download bereit. Ein ausführlicher User-Guide ist hier verfügbar.

groovyrdf 0.2 veröffentlicht

Es ist mittlerweile schon über 1 Jahr her, dass ich mit groovyrdf eine Bibliothek zur einfachen Erzeugung von RDF-Daten mit Groovy veröffentlicht habe. Nun ist endlich das 2. Release da, und es bringt interessante Neuerungen mit sich.

Neben dem Erzeugen von RDF ist mit Version 0.2 auch das elegante Auslesen und Verarbeiten von Daten möglich. Mittels RdfLoader unterstützt groovyrdf das Laden von Linked Data Ressourcen inklusive Content-Negotiation. Die Daten können anschließend ausgelesen und weiter verarbeitet werden:

  // Namespace-Deklaration
  def foaf = new RdfNamespace ('http://xmlns.com/foaf/0.1/')

  // Laden einer Ressource mittels RdfLoader
  RdfLoader rdfLoader = new JenaRdfLoader()
  RdfResource person = rdfLoader.loadResource(
    'http://me.desone.org/person/aveltens#me'
  )

  println person(foaf.name) // Gibt 'Angelo Veltens' aus

Der Loader kümmert sich selbstständig um Content-Negotation und das Parsen des zurückgelieferten Formats. Solange RDF geliefert wird, kann es uns egal sein, ob dies vom Server in TURTLE, RDF/XML oder N3 ausgedrückt wird. Alle gängigen RDF-Syntaxen werden unterstützt. Der Zugriff auf die Eigenschaften der geladenen Resouce ist anschließend einfach über resource(predicateUri) möglich. Näheres erklärt der User Guide. Version 0.2 steht hier zum Download bereit und den Sourcecode gibt es nach wie vor bei GitHub.

[important]Wenn ihr groovyrdf nutzt, oder auch einfach nur kurz ausprobiert, freue ich mich über euer Feedback![/important]

WebID-Authentifizierung mit Node.js

Ein Leser des letzten Artikels hatte Schwierigkeiten, die Signatur von foafssl.org mit Hilfe von Node.js zu überprüfen. Es war etwas tricky, aber ich habe es inzwischen hinbekommen und möchte die Lösung niemandem vorenthalten:

Grundsätzlich funktioniert die Überprüfung der Signatur bei Node.js mit verifier.verify(object, signature, [signature_format]). Als 1. Parameter gebt ihr den (PEM encodierten) Public Key an, als zweites die Signatur und als letztes das Format ‚base64‘.

Allerdings ist die übermittelte Signatur nicht Base64, sondern Base64-URL encodiert! Ihr müsst also in der Signatur zunächst alle ‚_‘ durch ‚/‘ und alle ‚-‚ durch ‚+‘ ersetzen. Bevor ihr die Signatur an die verify-Function übergebt, müsst ihr aber außerdem noch ‚==‘ hinten anfügen. Die korrekte Signatur ergibt sich also wie folgt:

var signature = signatureBase64Url.replace(/\_/g, '/').replace(/-/g, '+') + '=='

Ein funktionierendes, online ausführbares Code-Beispiel habe ich auf der Plattform jsapp.us hinterlegt.

Content-Negotiation mit Grails

Content-Negotiation, zu Deutsch Inhaltsvereinbarung, ermöglicht es dem Webserver unterschiedliche Repräsentationen einer Resource an den Client auszuliefern und ist damit eine wichtige Funktion im Web of Data. Nehmen wir zum Beispiel an, die folgende URI identifiziert die Stadt Berlin:

http://example.com/city/berlin

Web-Browser fordern für gewöhnlich HTML-Dokumente an und sollen daher beim Abruf dieser URI eine schön aufbereitete Webseite mit Informationen über Berlin und ggf. ein paar Bilder ausgeliefert bekommen. Gleichzeitig sollen jedoch auch RDF-Daten über Berlin im Web of Data verfügbar gemacht werden.

In bin ein großer Freund des Grails Web-Frameworks, welches ich sowohl beruflich als auch privat nutze. Mit Grails wird – neben so ziemlich allem was Web-Entwicklung angeht – auch die Content-Negotiation zum Kinderspiel. Ich möchte das an dem bereits angesprochenen Beispiel praktisch verdeutlichen. (Ich gebe allerdings keine Einführung in Grails selbst, dazu verweise ich auf die hervorragende Dokumentation)

Nehmen wir an es gibt eine Domainklasse City, welche in verschiedenen Repräsentationen durch den CityController ausgeliefert werden soll.

Wir legen folgendes Mapping in UrlMappings.groovy an:

static mappings = {
  "/city/$name"(resource: "city")
}

Dadurch werden die Requests an URLs der Form /city/name RESTful gemappt und an den CityController weitergeleitet. D.h. GET-Requests gehen automatisch an die show-Action des Controllers POST an save u.s.w. (Details siehe Grails-Dokumentation). Außerdem wird der Part hinter /city/ als Parameter „name“ in die Action hineingegeben.

Mithilfe des withFormat-Ausdrucks kann der Controller auf verschiedene Anfrageformate unterschiedlich reagieren:

class CityController {
  def rdfRenderer

  def show = {
    def city = City.findByName(params.name)
    withFormat {
      html { return [cityInstance: city] }
      json { render city as JSON }
      rdf { rdfRenderer.render(city) }
    }
  }
}

Der rdfRenderer ist ein fiktives Beispiel. Sowas wird leider nicht von Grails mitgeliefert. RDF lässt sich aber sehr leicht mit groovyrdf generieren. Die Codeblöcke werden bei Anfragen nach den entsprechenden Formaten ausgeführt. html und json liefert Grails von Haus aus mit, was rdf bedeutet muss man jedoch kurz selbst in der Config.groovy bekannt geben:

grails.mime.types = [
  html: ['text/html','application/xhtml+xml'], // bereits vorkonfiguriert
  json: ['application/json','text/json'], // bereits vorkonfiguriert
  // [...]
  rdf: 'application/rdf+xml' // selbst ergänzt
]

Das wars im Prinzip schon, leider gibts in Grails derzeit noch einen kleinen Bug: Grails liest für die Content-Negotiation nicht wie üblich den HTTP-Accept-Header aus, sondern den Content-Type. Der Content-Type gibt eigentlich das Format der Daten an, welche man hinsendet und nicht der Daten welche man anfordert. Das lässt sich aber leicht über eine einfache Konfiguration beheben. Dazu in der Config.groovy folgende Einstellung setzen:

grails.mime.use.accept.header = true

Das wars auch schon! Abhängig vom gesetzten Accept-Header reagiert unser Controller nun anders auf den Request und kann entsprechend eine GSP rendern um eine HTML-Seite auszuliefern, JSON-Daten ausgeben oder aber RDF! Und sogar folgende URIs sind gültig:

http://example.com/city/berlin.html - Liefert immer die HTML-Seite
http://example.com/city/berlin.json - Liefert immer JSON-Daten
http://example.com/city/berlin.rdf - Liefert immer RDF-Daten

Wir haben also mit http://example.com/city/berlin eine eindeutige URI, welche die Resource Berlin identifiziert und zum anfragenden Client passende Daten ausliefert. Zudem haben wir für jede der Repräsentationen eine URI mit der entsprechenden „Dateiendung“. Das ist genau das, was wir im Web of Data brauchen 🙂