Aug 10 2009
Representing Time in RDF Part 6
I found these documents useful while researching this topic. I include them here because they could make a useful list of background reading for modelling time with RDF.
-
Refactoring BIO with Einstein Part 1: First Steps — my first post that touches on modelling of time in genealogy. At this point I was attempting to model it simply using an event model, i.e. a sequence of things that happen to people and places.
-
Refactoring BIO with Einstein Part 2: Conditions — this is the post in which I first introduced Conditions (i.e. Approach 1). The post uses almost exactly the same example as Scenario 1.
-
Refactoring Bio With Einstein Part 3: Temporal Invariants — in the third part of the series I explored those properties of a person that are timeless, or “temporally invariant”.
-
Refactoring BIO with Einstein Part 4: Employment and Families — in this post I continue the theme of part 2 and demonstrate how employment periods could be described using conditions and events that mark transitions between conditions.
-
Temporal Scope for RDF Triples — in this blog post Jeni Tennison describes her attempts to model time for the London Gazette data she is working with. She describes the reified approach (Approach 3) as unacceptable because most triple stores do not deal with reified data (i.e. don’t allow you to query it in its un-reified form). She describes two acceptable approaches which are N-ary relationships (Approach 4) and named graphs (Approach 2) with a preference for the latter. Some useful comments point to other examples of these approaches.
-
RDF and the Time Dimension Part 1 — in this post the author explains succinctly where the problem lies although the example used is flawed because it contains hidden context (i.e. “August is a summer month…” is not true in general and needs the context “…for those in the Northern Hemisphere”, which can be modelled in RDF). The post also settles on named graphs as a solution but claims they cannot be used for continuous dimensions such as time (missing the solution of using something like OWL-Time to represent intervals and relative timings).
-
RDF and the Time Dimension Part 2 — in this follow-up post the author proposes reifying statements and adding a new predicate to relate the reified statement to the context. (A hybrid of Approach 3 and Approach 4?). A second and preferred solution using named graphs is also presented. The author also demonstrates how to obtain a snapshot of all triples that held true at a specific time under both approaches (a “snapshot”).
-
OWL Time — an ontology of time concepts
-
Property Reification Vocabulary — a proposal for mapping between reified properties and classes that represent the reifications (i.e. between Approach 3 and Approach 4)
This post is part 6 of a series about representing time in RDF. Other posts in this series: part 1, part 2, part 3, part 4, part 5
5 Responses to “Representing Time in RDF Part 6”
[...] modelling time with RDF [...]
If you take the universality of RDF seriously, then I think you start any modeling task by stipulating that there is no need to go meta. No named graphs, no reification. Whatever it is you’re trying to add (temporal context, belief context, geographic context, etc.), begin with the assumption that it can be expressed in normal RDF, and the constraint, at least initially, that it must. The point of this becomes obvious the moment you need to add a second context to a case that already has one. If you’ve gone meta to handle the first one, you’re out of options for the second. E.g., what if, having modeled marriages with starts and ends, you now need to add the fact that people may become legally married and unmarried in different jurisdictions at different times?
Thus, it seems to me, not only are n-ary relations the clear choice, but it’s sort of an RDF moral imperative to consider no other options. Relax and love the structure. Marriage? Easy:
@prefix…
@keyword a .
_:m1 a Marriage ;
spouse maria , jim ;
start 2006-04-07 ;
end 2009-03-23 .
Jurisdictions? Marriages that haven’t ended yet? Still easy:
_:lm1 a LegalMarriage ;
spouse maria , jim ;
start 2006-04-07 ;
end 2009-03-23 ;
jurisdiction cayman_islands .
_:lm2 a LegalMarriage ;
spouse maria , jim ;
start 2006-05-04 ;
jurisdiction usa ;
current true .
I think the critical error in that Erewhon post about the impossibility of modeling dimensions in RDF is thinking that any graph that states “August is a summer month if you are in the northern hemisphere” must state “August is a summer month”. This is nonsense. The former can be said like this:
august season [
name "Summer" ;
hemisphere north .
] .
which clearly does not include or imply the unqualified statement
august season “Summer” .
Glenn, i think you are spot on with your comment
Ian, thanks for the comprehensive review. I’m also of the opinion that N-ary relations are the best bet. I’ve been playing around with alternative N-ary approaches involving intermediate nodes, but I think your approach of converting a time-dependent property into a “mypropertyInContext” node is the best compromise.
The downside of course is a proliferation of new classes. Perhaps ontologies should explicitly declare these classes where they are likely to be widely used. A naming convention could be useful – and your approach of appending “InContext” to the property name seems as good as any.
A great series of posts, Ian, and very interesting. The N-ary relations approach seems the most natural to me, and, as you say, enables you to specify contexts based not only on time, but on other properties like location.