Jeni's Musings

Hi Jeni,

While you could see a school that changed its name as a new entity I wouldn't go for your first proposal. It just makes things too complicated: to be consistent we would have to adopt this approach to *every* URI we use, we would have to communicate to people why we use this mass of URIs (and see the current discussions on the semweb and LOD mailing lists how our URI usage is too complicated already, apparently) and it would just make data integration very hard because you never know which URI to use. And in some areas data changes very often so you end up with loads of URIs. This just can't be the solution, it has to be a lot simpler.

You talk about the risks of an aggregator merging the data. I don't see this risk. Every aggregator has to assume that documents change all the time so whenever it retrieves data from a resource it knows it accessed before then it can either replace its current data or store the new data under a different graph URI that reflects the time and all other circumstances of access. If it does the latter then yes, you have to be careful when querying the store of that aggregator.

A more efficient alternative to always reloading the whole document is the Talis Changeset Protocol: http://n2.talis.com/wiki/Changeset_Protocol - I think this needs to see wider adoption. Although I would probably replace the reification they rely on with two named graphs, one holding all the triples being added and one holding all the triples being removed.
Apart from graphs which contain the changesets you can also have one main graph which reflects the current state of all of the data with all changesets applied (and you can do that both on the publisher and on the aggregator side).

Regards,
Simon