Following Danny Ayers, I am currently chucking the GTD part of my head and the RDF part together to try and come up with some kind of RDF mapping for the GTD process. 
I’m thinking that Action, Project and Context each map to an owl:Class quite nicely. But after that, it gets more complex. The ‘Stuff’ which gets put into ‘in’ could be unrepresented, or it could just be any owl:Thing. Hmm. Mulling over must take place.
Because each action can be reliant on another action taking place. Each action may be in multiple contexts - for instance, “call Joe” may be both a ‘telephone’ context and an ‘internet’ context if you have a laptop with Skype. The same is true for actions-to-projects. Putting the coffee pot on may allow you to make a cup of coffee, but it also allows you to advance the ‘help co-worker’ project. So, actions can be assigned to multiple projects.
The bit that got me a bit ruffled was assigned actions. In ‘lists’ and an XML mindset, then it’s quite simple to just move an action from “next” to “waiting for”, but there doesn’t seem to be an easy way to solve this. Instead, what I’ve done in designing the RDF mapper is made it so that if an action has the attribute “assignedTo #x” (where #x is a foaf:Person). For ‘follow up’ actions, I’ve created a subclass called AssignedActionFollowup. The difference between an Action and an AAF is that you cannot assign an AAF to another person (otherwise, you’d need an AAF for the AAF).
For assignment, some rules-based magic will probably take place. Quite what, I haven’t really thought about.
I’ve also been thinking about contexts and have split them up in to three rough categories with fancy labels - ‘existential’, ‘locational’ and ‘operational’. An existential context is one which is dependent on a person’s temperament, physical or mental health (etc.). Quite a lot of people use ‘low energy’ or ‘high energy’ contexts to separate out tasks that require different levels of physical or mental energy or ‘zonedness’ or what not. We should be able to distinguish that kind of context from the others.
A locational context is a context which we could plot on a map, even if the label applied to it is not geographical. So, for instance, “work” is not a geographical location like “Drury Lane, London” is, but it is feasible that a person’s work could have an address location attached to it in a way that their state of mind can not be.
Of course, for locational contexts, I am using danbri’s Basic Geo (WGS84 lat/long) Vocabulary - each context can be mapped on to multiple geo:Point’s. Perhaps implementers will use geocoder.us and Free the Postcode services to map locations to geo:Point. I’m sure the JavaScripty Google and Yahoo! Map hackers will have the opportunity to have fun with GTD/RDF, so long as they can put their prejudices about RDF to one side (heh). One thing that would be very cool would be working out how to get the maximum number of things done with the least amount of travel (of course, we will need Free The Railway Maps for that to work…)
Finally, an operational context is one which certain functions can be carried out when it may not otherwise be possible to carry them out. For instance, ‘Internet’ is an ideal operational context since Internet access may be limited or non-existent when flying. Perhaps these days ‘low bandwidth’/’high bandwidth’ may be a more appropriate distinction, since downloading a large file may be something you put on your to-do list - but it requires an operational context of a high bandwidth Internet connection.
What is the purpose of splitting up these kinds of contexts? Well, there are certain services that could be used to determine presence, location or mood, and being able to tie a next action readout to those contexts may be useful. The location stuff we have already talked about.
For instance, if you posted “I am feeling tired” or something equivalent to Twitter, then perhaps a high-energy action could be substituted for a low energy one. Or perhaps if you are listening to music tagged a certain way, it could prioritise your interests another way.
For ‘presence’, we could have things like mobile phone signal or closeness to one’s landline. For certain ‘phone’ contexts, you could make them disappear when making a phone call is not possible. Our context markers should be able to talk to RFID chips, of course. That way we can map ‘to think about’ type tasks to taking a bath, or watching pro wrestling or hacking at 3am, or whatever it is that makes people think.
What does RDF buy us? Well, one thing it does brilliantly is multilingualism. If one is working in teams, then being able to have data in a format that supports multi-lingualism out-of-the-box is a good thing. The other is easy and spontaneous ‘chunkability’ (there is a posher word for it, but this will do). The idea that projects, actions, team members and contexts can be shared among group members through the use of HTTP and URI-based addressing is also a good thing.
Another thing I’d like people who are smarter than me to think about (and there are lots of you out there in SWIGland) is how this could fit together with the Web of Trust, something that danbri showed me at Hackday, but went way over my head (the Ruby didn’t help!). I’m sure that for enterprise level stuff (for the few enterprises who want to step outside the Outlook deadlock), encryption and signing are probably important.
All this stuff is just sitting in Protégé at the moment waiting for flashes of inspiration and those even rarer stretches of non-procrastination. Once I’ve got a bit further, I’ll put up an OWL/N3 file for public review.
Tags: semantic web, semweb, rdf, getting things done, gtd
Comments | TrackBack
