[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Using RDF for Change Tracking serialization?
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]