Using RDF for Change Tracking serialization?

[monkeyiq <monkeyiq@gmail.com>]

Hi,

  Since I know of a few office applications which support RDF, I thought
of perhaps considering leveraging it for change tracking. Apologies if
this has been thought of and dismissed in the past. As far as I know,
OpenOffice, Calligra/KOffice, and abiword all have support for at least
preserving RDF across load/save cycles.

As an aside, since I have been involved in making some of that happen,
the challenges I see when making an implementation support RDF in ODT
are the following:

(1) handling RDF/XML to internal model transition (handling the RDF
    file itself), when xml:id values change in the document 
(2) updating references from the RDF to those nodes,
(3) handling copy and paste, again due to the xml:id needing to be
    unique and when that happens references from the RDF to the pasted
    document content have to be added.

  Anyway back to the point. As there is some implementation support for
RDF I was considering how one might serialize change tracking into RDF
instead of inline in content.xml. I've kept things very simple in this
email, if there is interest I'm happy to expand and explore using other
constructs with RDF too.

Consider this example from the GCT (a fragment generated with abiword),
the "text" of a four word paragraph undergoes a number of style changes
which are represented using ac:changeXXX attributes;

<text:p text:style-name="Normal" 
  delta:insertion-type="insert-with-content" 
  delta:insertion-change-idref="1">This is the 
<text:span text:style-name="T1" delta:insertion-change-idref="4" 
 delta:insertion-type="insert-around-content"
 ac:change1="2,insert,text:style-name," 
 ac:change2="3,modify,text:style-name,T2" 
 ac:change3="4,modify,text:style-name,T4">text</text:span> 
here.</text:p>

Considering only the ac:change attributes, in RDF one might instead see
the change tracking coalesced into an xml:id.

<text:p text:style-name="Normal" 
  delta:insertion-type="insert-with-content" 
  delta:insertion-change-idref="1">This is the 
<text:span xml:id="f009" text:style-name="T1"
delta:insertion-change-idref="4" 
      delta:insertion-type="insert-around-content">text</text:span> 
here.</text:p>

The ac:changes are then serialized as RDF. It might also be advantageous
to split the attribute value into its constituents. Without the
formalities of namespaces and in a more abstract triple format this
might lead to something like:

bnodeA revision  2
bnodeA type      insert
bnodeA attribute text:style-name
bnodeB revision  3
bnodeB type      modify
bnodeB attribute text:style-name
bnodeB oldvalue  T2
bnodeB revision  4
bnodeB type      modify
bnodeB attribute text:style-name
bnodeB oldvalue  T4

Of course this would need to also link bnodeA,B,C subjects back to the
xml:id of f009 in the core document.

There are many advantages that I see do exploring RDF for this purpose;

(1) The change tracking information can have annotations and digital
    signatures applied. It would be quite simple for bnodeA to also
    include a signature for the subgraph ( bnodeA ? ? - bnodeA
    signature ? ), ie all RDF with a subject of bnodeA, sans any
    existing digital signature on the odd change it exists to avoid
    ambiguity.

(2) implementations which do not support change tracking have a
    simpler and smaller document to load.

(3) queries can be run on the change tracking information using SPARQL

(4) The RDF affords applications a scratch space to associate any
    other semantics with changes that might be desired. Since the
    association can be to other RDF it should be resilient to
    implementations which do not know of the additional custom RDF.

One major downside to this approach is that it requires an
implementation to get its hands dirty with some RDF support in order to
support change tracking. There is also the issue that an application not
supporting RDF might break the xml:id links from the RDF to the
document. Though if the change tracking specification does not use RDF
and application which doesn't support change tracking is used to load an
ODF file it too will probably not save the ct information if/when the
document is saved.