My Linked Data publishing ‘platform’

Among the goals I had in mind for Companjen.name were to publish (parts of) my family tree so that others can benefit from it (without being bound to specific collaborative genealogy websites), and to play around with linked data (i.e. having a webspace to publish my own ‘minted’ URIs with data). I believe the second goal has been completed (and that the first can be achieved using the second).

Linked Data

Linked Data is based on using Uniform Resource Identifiers (URIs) for online and offline resources, that are dereferenceable via HTTP, so that at least useful information (i.e. metadata) about the resource is returned, if the resource itself cannot be returned. The machine-readable data format of choice is RDF, which should be serialized as RDF/XML (because all RDF parsers must be able to read that) and any other serialization I wish. For human agents it may be nice to have a data representation in HTML.

URI design

Because every URI is an identifier, we want to make sure they don’t break. I want the URIs I use to identify resources to be recognizable as such, and they need to be in my domain. Therefore I chose to have all URIs that may be used in my Linked Data to start with “http://companjen.name/id/”. (Resources can have many identifiers, so I can easily add another one to resources that already have URIs.)

What comes after the namespace prefix can take many forms; I haven’t decided yet. I do think it is nice to reserve filetype extensions for the associated data representations, i.e. “.html” for HTML, “.rdf” for RDF/XML and “.ttl” for Turtle documents.

How it works

My hosting provider allows me to use PHP, .htaccess files and MySQL, all of which I used to create the “platform”. It is composed of the PHP Content Negotiation library from ptlis.net, the PHP RDF library ARC2, two custom PHP scripts and a .htaccess file.

Since all URIs that I want to use have the same path “/id/”, but I don’t want to keep HTML, RDF/XML and Turtle files of every resource, I wrote some RewriteRules (helped by looking at Neil Crosby’s beginner’s guide) in the .htaccess file in the document root to redirect the request to a content negotiating PHP script. That script lets the Content Negotiation library determine the best content type based on the Accept header in the HTTP request and sends the user to the URI appended with .rdf, .ttl or .html via HTTP 303 See Other.

The HTTP client will then look up the new URI. Since the requested path will still contain “/id/”, mod_rewrite will catch the request, but another rule points to a PHP script that queries the ARC triplestore and puts it in the requested format (RDF/XML and Turtle are created by ARC itself, HTML is created by filling a template).

What you get when you look up something in the /id/ space, is the result of a simple “DESCRIBE <URI>” request to the triplestore, which is somewhat limited: it will only return triples with <URI> as subject. This gives some context (one of the principles of Linked Data), but it may be very interesting to know in what triples the resource is used as object or property (if applicable).

Future work

Apart from making the results more interesting by returning triples that have the URI in the property or object part, there is more to do to mature the platform.

First and foremost: fill the triplestore. There are things that I’d like to publish myself, instead of giving them away to commercial parties from whom I can only access them through controlled APIs. I already mentioned my family tree, but another example is concerts I visit. Let Last.fm, Songkick, Resident Advisor get that info from my triplestore, so that I only have to create the info once and keep control over it. Or maybe the concert venue will find my data on Sindice and display my review on the concert’s page. Oh, the possibilities of the Semantic Web…

As more data will become available in the triplestore, it makes sense to describe the different datasets using the Vocabulary of Interlinked Datasets (VoID) and put a link to the VoID document at the .well-known location. My family tree will be a nameable dataset, for example, with links to DBpedia, perhaps GeoNames and perhaps eventually online birth, marriage and death records.

The current HTML template is a table with columns Subject, Property and Object. A templating engine that has templates for different resource types would be a nice start, so that e.g. a person in my family tree will be displayed with a photo and birth and death dates like genealogy websites usually do (e.g. ” for marriage). Maybe there are browsers/editors for linked data family trees already, but looking for them is also future work.

Now to ‘mint’ a URI for myself: http://companjen.name/id/BC. Look it up if you like!

UT-evenementen mét tijdzone :)

Nadat ik erachter was gekomen dat mijn problemen met de evenementenkalender van de Universiteit Twente, die ik via Google Calendar op mijn Androidtelefoon wilde hebben, niet werden veroorzaakt door de software van de UT, maar door Google Calendar, heb ik eerst gehoopt dat Google voor een oplossing zou zorgen. Maar dat is niet waarschijnlijk; het probleem bestaat al jaren. Met een hack lijkt het nu wel gelukt. Continue reading “UT-evenementen mét tijdzone :)”

Evenementenkalender UT gedebugd

De Universiteit Twente biedt een iCalendar-bestand aan met de evenementen uit de evenementenkalender. Dat is handig voor mensen die niet verschillende websites willen afstruinen op zoek naar iets om hun tijd aan te besteden, of hun afspraken willen afstemmen op UT-evenementen. Maar ondanks beloftes om mijn klachten over de kalender door te spelen aan de leverancier, lijkt er weinig te zijn veranderd.

Mijn eerste klacht ging over de rare tijden van evenementen. Sommige evenementen duurden niet langer dan een flits (opening van het academisch jaar van het ITC liep van 14:33 tot 14:33, bijvoorbeeld), andere evenementen die als dagevenementen waren ingepland liepen van 2 uur ‘s nachts tot 2 uur ‘s nachts de dag erop.

Maar is Google Calendar om nog onbekende reden gestopt met het importeren van evenementen uit het iCalendar-bestand. Herhaaldelijk unsubscriben en subscriben werkt niet, maar misschien ligt het niet aan Google.

Kijkend naar de inhoud van het iCalendar-bestand, valt het volgende op:

  • het bevat geen tijdzone-informatie voor de gehele kalender
  • evenementen zijn aangegeven in de lokale tijd (start- en eindtijd bevatten geen indicatie van tijdzone)
  • verschillende evenementen duren ook echt niet: een voorstelling van Andermans Veren Live! op 28 september duurt van 000000 tot 000000 (lees: 28-9-2011 0:00 tot 28-9-2011 0:00)

Deze iCalendar Validator geeft in al eerste instantie aan dat er iets serieus mis is: in één van de evenementbeschrijvingen zitten regelovergangen zonder spatie of tab aan het begin van de nieuwe regel (dit wordt aangemerkt als serieuze fout, die slechts door zeer weinig applicaties wordt genegeerd) en lege regels worden misschien niet door alle applicaties ondersteund (dit is slechts een waarschuwing; binnen evenementen ziet het er wel wat gek uit, maar het zal door veel applicaties wel geaccepteerd worden).

Als ik het bestand handmatig heb aangepast en upload voor controle, springen er andere errors en een nieuwe waarschuwing naar voren. De waarschuwing is voor de regel die aangeeft welke iCalendar-versie het bestand gebruikt die niet de tweede regel van het bestand is. De errors zijn voor het niet-escapen van komma’s en puntkomma’s in de evenementbeschrijvingen, al vermoed ik dat Google daar geen moeite mee heeft.

Nadat ik alle fouten uit het bestand heb gehaald, geeft de Validator “100 out of 100”, dus Google Calendar zou het nu toch moeten kunnen snappen. Importeren dus!

In een nieuwe agenda worden inderdaad vrijwel probeemloos de evenementen geladen – 1 van de 55 wordt genegeerd, misschien omdat het al voorbij was, misschien met een andere (mij onbekende) reden.

Alles wat er nu nog vreemd uitziet, komt mijns inziens voort uit problemen met invoer aan de kant van de redactie of met interpretatie (ofwel door het CMS, ofwel door Google Calendar), namelijk:

  • evenementen zonder tijdsduur duren standaard een uur (Google)
  • evenementen zonder tijd beginnen om twaalf uur ‘s nachts (gebrekkige invoer: een High Tech High Tea of P-uitreiking hebben zeker wel een bekende start- en eindtijd, maar die is ook op de website niet aangegeven)
  • meerdaagse dagevenementen worden niet aangegeven met datumwaarden (een datum, zonder tijdaanduiding zoals 20110928), maar met datum-tijdwaarden (combinatie van datum en tijd, zoals 20110928T000000). Daardoor komen meerdaagse evenementen altijd een dag te kort, zoals bijvoorbeeld het Techniek-meidenkamp dat volgens de website tot en met 30 september duurt, maar volgens ‘mijn’ nieuwe agenda tot 30 september (klokslag middernacht) duurt.
  • geen enkel evenement heeft informatie over de locatie ervan.

Het is dus te makkelijk om klachten alleen door te geven aan de leverancier, want de softwareleverancier zit waarschijnlijk niet evenementen in te tikken.

Via Twitter heb ik de webredactie al eens gewezen op een mooi voorbeeld van een iCalendar: die van de Vrijhof. De Validator geeft dat bestand een score van 48 van de 100 punten, want komma’s en puntkomma’s zijn niet voorafgegaan door een backslash, de versieregel staat niet op regel 2 en de regeleindes zijn niet in Windowsformaat gecodeerd. Maar er zit wel volledige tijdzone-informatie in, tijden kloppen, locaties kloppen en de beschrijving van het evenement is geen slappe samenvatting, maar het hele verhaal – al hoeft dat van mij weer niet zó uitgebreid.

Kortom: dit ligt niet alleen bij de leverancier van het CMS, maar ook bij de redactie die informatie preciezer moet invoeren en als het even kan ook meer informatie invoert. Ik kijk alvast in mijn agenda.

Update 28-9 16:11u De webredactie en de leverancier zitten niet stil, laten ze via Twitter weten: https://twitter.com/#!/UTwente/status/119047175052341249 De e-mail bevestigt dat ook, dus dat komt wel goed.