The OASIS group who are responsible for things like the Open Document Format (ODF) format are throwing around how to improve how change tracking information is to be contained in future versions of ODF. I've hacked some support for the "generic" change tracking proposal into Abiword in a git branch, and Ganesh Paramasivam has been working to make Calligra and KOffice support this too.
I thought a little bit of a look at how documents move between suites was in order. Obviously, these are really trivial changes. The larger use cases screem out for an automated system to test them, so that regressions can be caught and other office suites added over time if they choose to support this method of change tracking.
So, without further (or less) ado, the below video shows a document created in KOffice and bounced through a temporary file to abiword and inspected. Apologies for the delays in the first video, I've sorted that issue of frame dups out for future shows.
In the second video I make some changes in abiword and send those back to KOffice. In the process I found a few little issues which I've committed some updates to the abiword git repo to help with.
These videos where created with recordmydesktop, transcoded with mencode for 720 playback (mainly getting the video codec how vimeo wants to see it), and uploaded with ferriscp foo.avi vimeo://upload.
This scattered series of posts has been about the RDF support I'm working on for KOffice. The ODF document format lets you store RDF/XML data inside the document file, which in turn lets both a human reader and a computer know about things that comprise an office document. You can refer to a person, place, or time and have the computer know what you are saying without having to resort to heuristics.
Having RDF support in document formats means you can send somebody a single file containing exact information about real world events. The RDF can contain details which can be pulled up in the formatting of the text that you see. For example, for a given contact you might know his phone number, home page, normal business location, email address etc. You might only want to see a small fraction of this information at one place in a document, but perhaps for a header you want to know the postal address too. Stylesheets are what I'm working on right now to let that happen.
At the start of the video below, you can see James, Joyce and Mark. As I click on these contacts, the RDF docker tells me information about them. As you can see, there is more information known to KOffice than is shown in the document (first & last name). However, for Mark, we also know where he is and that is shown in the RDF docker.
James is mentioned in the second paragraph, and the document is talking about giving him a call to verify something. Instead of hunting down his phone number, you can set a semantic stylesheet for that particular reference to him in the document to include is phone number inline in the document text. The added advantage here is that if you edit his phone number via the RDF docker, all the places in the document text that cite the phone number are updated for you. KOffice knows that those digits are James' phone number, so it can modify them for you.
Later on we again cite the event itself, just saying its "next weekend", which isn't an ideal description of when a specific event is happening. Luckily, we have cited the RDF event, so it shows up in the RDF docker and the stylesheets are available to reformat the text. In this case I want to see the summary and when it starts.
I'm working on adding user specified stylesheets now too, as the Format menu shows in the video. When you create a user stylesheet it is also saved in RDF, so the stylesheets you make become part of the document itself. They will be available when some other KOffice user loads the document.
The File/Document Information widget has a new RDF section which lets you see and directly edit the RDF triples if that's your thing, the semantic tab shows you all the higher level things that KOffice has seen in the document, like poeple, places, and events, and finally the stylesheets page lets you nominate how you want things formatted by default. For example, you might want to see a persons name and phone number so setting that to the default lets you then drag and drop some contacts from kaddressbook into the document and you will see the phone number as part of the document text.
Of course, you can drag and drop items from the RDF docker into kaddressbook and korganizer. These pieces of information should be able to be moved into and out of an ODF file using KOffice without thinking about it. You want to add Fred to the text, pick him up from your kaddressbook and drop him into the RDF docker. Your default contact stylesheet is then used to insert some text into the document at the current cursor location showing you the Fred contact. Quick and simple... Lets make RDF something everybody uses but nobody needs to learn about (unless they want to).
As mentioned in a previous post, ODF documents can contain one or more RDF/XML files. These files allow you to unambiguously encode information for both computer and human consumption. So you can describe a person in a way that tells you their phone number and also lets the computer know that these digits are a specific person's home phone number. Common data formats like vcard and ical have some encodings in RDF and soon a KOffice near you will understand these pieces of data from ODF files.
KOffice currently understands some of the FOAF vocabulary (storing contact data), and the rdfical format (for events). There are a few ways to encode longitude and latitude in RDF. The current patch supports two of them, with optional linking to rdfical. This is one of the major strengths of RDF, you can say who, where and when and also link these things together so an event carries not only a time but its location information too.
The below video shows the new RDF docker in aciton. As you click on text that has associated RDF, the docker shows you the interesting information. Frodo and Sam are assoicated with both traditional contact data and a location. The items in the RDF docker let you import them into your system (into kaddressbook or korganizer) or export them to well known desktop formats like vcard and ical. Editing locations is done with Marble and there is only a minimal set of information for contacts and events currently. Note that mid way through when I edit an event, timezones are respected. If the RDF describes an event as being in Tokyo, that timezone offset from your current localtime is respected.
Towards the end of the video I show that contacts can be simply drag and dropped between koffice and kaddressbook. This also works for events to/from Evolution but I had some issues with korganizer for events. D&D makes KOffice and ODF quite a convenient format for transmitting semantic information to colleagues in a single, self describing file.
I've been hacking on the development branch of KOffice to add RDF support. Thanks to KO GmbH for this chance! This means that while a document can posit a linear progression of characters and words like normal, the software can start to understand a bit of what you are talking about too.
The ODF document specification allows RDF to be included in the document zip file either inline in the main content.xml file, or using manifest.rdf and other RDF/XML files in the zip. The RDF is free to refer to XML elements in the content.xml, so you can add metadata to names, places, times etc so that a computer can work out unambiguously what you are talking about. This makes an ODF file a very powerful container format for transmitting meaning to people.
At it's heart, RDF represents all information in triples. Bob knows Alice, etc. See lwn.net or other sources if you want to know more about RDF. But you don't have to know it to use it with KOffice ;)
Below you can see that I've hacked the "Document Information" window to let you see the raw RDF if you want to know exactly what is going on:
If on the other hand, you are not a developer and/or don't really care about triples or RDF, there is the Semantic view. Right now I only have support for Contact information which is drawn from the FOAF RDF vocabulary. If the later doesn't mean anything to you, its just a way to describe people and their relationships using RDF. As you can see, you don't have to care about RDF here, you just see people. Right clicking on a person lets you do things like import them into your contacts database, or, in the future, other things like email them or phone them.
While it is nice to be able to have contact information extracted from the document, it is much nicer to have KOffice know exactly where that information relates in the document. For this I have a new Docker for RDF as seen in the below video. First you see that the addressbook is empty. Then I start moving the cursor around in the document. Notice that the docker picks up when the cursor is on the name of a person that has RDF metadata. You see more information about Frodo, and then I import Sam. The contact entry in the addressbook created for the import brings his phone number in too, which was part of the RDF but not explicitly shown in the document.
I hope to add support for other things like times, locations, and relationships. This way you can send somebody a document describing a meeting and they can import the time into their smart phone directly from the document... can we make retyping such information a vague memory like punch cards?
