RDF’s goldfish memory and documentation of vocabularies

a goldfish
After a rather interesting day of discussion at HP Labs on Friday it occured to me that RDF has a memory like a goldfish. Everything asserted in RDF is asserted now, there’s no future, no past to RDF, only the present. I’m not explaining this very well. I mean that if I was an RDF datasource, I wouldn’t know anything about the past or the future. hmm, ‘if I were an RDF datasource’…maybe I’ve been doing this a bit too long 😉


Anyway, this means that change is tricky to represent, for example, vocabularies changing over time. Interesting because one of the themes of the day was that RDF can help in explaining what people actually meant when they wrote, say, an XML schema, or iCalendar. Ploughing through the iCalendar RFC 2445 to translate it to RDF was so hard because the written descriptions were ambiguous. One of the issues is the lack of documentation about the reasons decisions were made. This is part of the documentation of a vocabulary (and of course a very good reason for an open process, where the decisions can be tracked somewhere, e.g. on a mailing list). I’m trying to document RDF ical, by summaraising the available public information in one place.
RDF cannot of itself provide dated tracking information of this kind; though I think Topicmaps can. Applications can provide this information of course, either through modelling (for example using events as first class objects, as Dan et al designed in the Harmony project) or outside the RDF model, via tracking the source or provenance, as scutters have to do.

One thought on “RDF’s goldfish memory and documentation of vocabularies

  1. Dan Brickley

    An RDF API (to a vanilla graph or to a context-tagged database) might be a good candidate for adding a transaction log mechanism, so you could roll back to any prior state. Whether that was practical would depend on dataset size, frequency of updates and other issues.
    I mean, say you’re an RDF store and you’re told:
    [2003-01-08] ASSERT s=_:danbri p=foaf:age o=”30″ src=msgid:etcetc
    [2003-01-10] RETRACT s=_:danbri p=foaf:age o=”30″ src=msgid:etcetc
    [2003-01-10] ASSERT s=_:danbri p=foaf:age o=”31″ src=msgid:etcetc
    …you could take this log and recreate the database state at any point in time, perhaps using a different database, or using filters based on the src of the assertions and retractions.
    Random aside: the retraction might not be needed if your database new that foaf:age was an owl:FunctionalProperty and it decided to believe what it was being told about someone’s age.

Comments are closed.