OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-collab message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [office-collab] Change Tracking on the RDF itself: Someinitial thoughts...


Hi,
  I got in contact with Sebastian Trüg of KDE/Nepomuk fame regarding change tracking RDF. He was wondering why I didn't use the fourth "context" node which is available in many implementations [1].

[1] http://en.wikipedia.org/wiki/Resource_Description_Framework#Statement_reification_and_context

  My initial thoughts were that even if the context node is available, perhaps an application might want to use the context node itself instead of surrendering it for change tracking. However, it might be considered just a level of indirection as they say. For example, if an application wanted to store:
 ?subj ?pred ?object ?mycontext

then instead the model might do:
  ?subj ?pred ?object ?ctctx1
  ?ctctx1 <uri:context> ?mycontext

This could be done by the model without the API user even knowing it. This would allow ?ctctx1 to track all sorts of wonderful information like the delta:change-id which introduced the triple, and the one what deleted it. In this light an update of a triple is just a retract/assert (delete/insert) of a triple.

So the example from the other day, using contexts becomes:
$ cat buildctctx.sh
#!/bin/bash

rm -f ctctxtest*db

rdfproc -c ctctxtest -- add "bnode1" "http://www.w3.org/2003/01/geo/wgs84_pos#lat"  "51.47026" "uri:cn1"
rdfproc -c ctctxtest -- add "bnode1" "http://www.w3.org/2003/01/geo/wgs84_pos#long" "-2.59466" "uri:cn2"

rdfproc -c ctctxtest -- add "uri:gollum" "http://xmlns.com/foaf/0.1/name"  "Gollum"         "uri:cn3"
rdfproc -c ctctxtest -- add "uri:gollum" "http://xmlns.com/foaf/0.1/phone" "tel:11 1322342" "uri:cn4"
rdfproc -c ctctxtest -- add "uri:gollum" "http://xmlns.com/foaf/0.1/homepage" "http://en.wikipedia.org/wiki/gollum" "uri:cn5"

rdfproc -c ctctxtest -- add "uri:cn1" "uri:delta-change-id"  "1^^xsd:integer"
rdfproc -c ctctxtest -- add "uri:cn2" "uri:delta-change-id"  "1^^xsd:integer"
rdfproc -c ctctxtest -- add "uri:cn3" "uri:delta-change-id"  "1^^xsd:integer"
rdfproc -c ctctxtest -- add "uri:cn4" "uri:delta-change-id"  "1^^xsd:integer"
rdfproc -c ctctxtest -- add "uri:cn5" "uri:delta-change-id"  "1^^xsd:integer"

# update Gollum's phone number
rdfproc -c ctctxtest -- add "uri:gollum" "http://xmlns.com/foaf/0.1/phone" "tel:11 6665534" "uri:cn6"
rdfproc -c ctctxtest -- add "uri:cn6" "uri:delta-change-id"  "2^^xsd:integer"
rdfproc -c ctctxtest -- add "uri:cn6" "uri:update"           "uri:cn4"
rdfproc -c ctctxtest -- add "uri:cn4" "uri:succeddedby"      "uri:cn6"
rdfproc -c ctctxtest -- add "uri:cn4" "uri:deleted-change-id"  "2^^xsd:integer"

# remove his home page.
rdfproc -c ctctxtest -- add "uri:cn5" "uri:deleted-change-id"  "3^^xsd:integer"

# update Gollum's phone number
rdfproc -c ctctxtest -- add "uri:gollum" "http://xmlns.com/foaf/0.1/phone" "tel:11 3232 6665534" "uri:cn8"
rdfproc -c ctctxtest -- add "uri:cn8" "uri:delta-change-id"  "4^^xsd:integer"
rdfproc -c ctctxtest -- add "uri:cn8" "uri:update"           "uri:cn6"
rdfproc -c ctctxtest -- add "uri:cn6" "uri:succeddedby"      "uri:cn8"
rdfproc -c ctctxtest -- add "uri:cn6" "uri:deleted-change-id"  "4^^xsd:integer"

rdfproc -c ctctxtest -- add "uri:cn6" "uri:succeddedby"      "uri:cn8"

And the SPARQL to get the triples for document at change-id "3" would be as follows. Note that the same caveat applies in the FILTER() where what we really want is to order change-id by their dc:date instead of the numeric value of their change-id. It might be useful to consider forcing implementations to choose values for change-id such that the numeric or string comparison respected the dc:date order of the change-transaction.

The query could very likely be made more efficient, its just something that works for demonstration purposes^TM. The query starts by expanding to quads. Then the graph context node is itself used in the model as a subject to find when the triple was introduced and optionally when it was deleted. A triple must be introduced before the change-id given and not retracted again before that change-id. This assumes that if a triple is updated it is deleted and inserted again, so the updated version will have a different context node and thus it will match the query but the old, deleted triple will not.

$ cat ./ctctxcurrent.sparql 
#!/bin/bash
rdfproc -c ctctxtest query - - '
prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
select ?graph ?s ?p ?o ?gver
where {
  graph ?graph {
     ?s ?p ?o . 
  } 
  . ?graph <uri:delta-change-id> ?gver 
  . OPTIONAL { ?graph <uri:deleted-change-id> ?delid }
    FILTER   ( ?gver <= "3^^xsd:integer" && ( !bound(?delid) || ?delid >= "3^^xsd:integer"  ))
}
'

And execution is as follows. Note that the phone number shown is from a triple which is retracted at a later time, specifically at "uri:delta-change-id"  "4" the number will become tel:11 3232 6665534. It is also not his initial phone number for change-id="1". This of course generalizes from phone numbers to any other semantics the RDF/XML wants to express which might vary as the document does.
$ ./ctctxcurrent.sparql 
rdfproc: Query returned bindings results:
result: [graph=<uri:cn1>, s=<bnode1>, p=<http://www.w3.org/2003/01/geo/wgs84_pos#lat>, o="51.47026", gver="1^^xsd:integer"]
result: [graph=<uri:cn2>, s=<bnode1>, p=<http://www.w3.org/2003/01/geo/wgs84_pos#long>, o="-2.59466", gver="1^^xsd:integer"]
result: [graph=<uri:cn3>, s=<uri:gollum>, p=<http://xmlns.com/foaf/0.1/name>, o="Gollum", gver="1^^xsd:integer"]
result: [graph=<uri:cn5>, s=<uri:gollum>, p=<http://xmlns.com/foaf/0.1/homepage>, o=<http://en.wikipedia.org/wiki/gollum>, gver="1^^xsd:integer"]
result: [graph=<uri:cn6>, s=<uri:gollum>, p=<http://xmlns.com/foaf/0.1/phone>, o="tel:11 6665534", gver="2^^xsd:integer"]
rdfproc: Query returned 5 results

I'll send through an ODF file example shortly.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]