I agree that this is a modelling problem. It seems that all
criticisms of RDF can be answered with "well RDBMs have exactly the
same problems". :) And the database world has done a lot of
research into these problems.
Neither just a timestamp, or a timestamp range is always sufficient either. Sometimes you want to keep an audit trail of when each entity or statement is added and removed from the model, sometimes you want to model the range of time for which an entity existed in the real world, and sometimes you need to do both - which requires a bitemporal model with four timestamps.
Eg, a graph which describes the countries of the world and their capitals may need to model how countries and capitals change over time, but it may also need to keep a change history of how this information was represented in the graph at any point to allow for corrections, and to allow old states to be examined.
There is some info on Wikipedia here:
http://en.wikipedia.org/wiki/Temporal_database
In RDF you can often get away with splitting the resource into identity, and state, linking the identity resource to each state resource, and just attaching temporal properties to the state; and doing things in a coarse grained way, rather than using reification and time-stamping each triple.
Even once you have the modelling right, and have sorted out the whole 2-dimensional time thing, you probably need to figure out how to purge old states if too many of them are going to build up. This isn't going to be trivial if the resources are all part of a big interlinked graph.
@en
Neither just a timestamp, or a timestamp range is always sufficient either. Sometimes you want to keep an audit trail of when each entity or statement is added and removed from the model, sometimes you want to model the range of time for which an entity existed in the real world, and sometimes you need to do both - which requires a bitemporal model with four timestamps.
Eg, a graph which describes the countries of the world and their capitals may need to model how countries and capitals change over time, but it may also need to keep a change history of how this information was represented in the graph at any point to allow for corrections, and to allow old states to be examined.
There is some info on Wikipedia here:
http://en.wikipedia.org/wiki/Temporal_database
In RDF you can often get away with splitting the resource into identity, and state, linking the identity resource to each state resource, and just attaching temporal properties to the state; and doing things in a coarse grained way, rather than using reification and time-stamping each triple.
Even once you have the modelling right, and have sorted out the whole 2-dimensional time thing, you probably need to figure out how to purge old states if too many of them are going to build up. This isn't going to be trivial if the resources are all part of a big interlinked graph.
@en