Re: Future of GNOME: Semantics

["John Carr" <john carr unrouted co uk>]

On Sat, Jun 14, 2008 at 9:11 PM, Anders Feder <lists anders feder dk> wrote:

Olav,

Thanks for your reply. I figured that people had read enough shiny use
cases, so I tried to keep those to a minimum, but sure.

Let's say you use Evolution's address book to manage all your contacts
and you just bought a new smartphone which only supports a proprietary
address book format. You want to move your contacts to the new phone -
what do you do? Conduit has knowledge of which format is used by the
phone, but has no way to convert the data.

This made me smile. I've just written the transport stuff needed for syncing Windows Mobile 5/6 with Conduit, but I need to convert AirSync XML to VCard and back before i'm finished. 

 

Today, chances are that you will have to do something like exporting the
Evolution address book to the .vcf (vCard) format and then searching for
and downloading an application which is able to convert from .vcf to the
proprietary format and then finally move over the converted file to the
phone. Most likely, coming up with the steps involved in this task is
either too complex or too boring for many users.

I agree that writing things to convert to and from vCard, iCal and others is the boring part of Conduit :-D If you can solve this problem for me I will buy you beer.

 

Now let's say that Evolution store its address book in the NEPOMUK
Contact Ontology (NCO) format in a central RDF repository and your new
phone support the Friend-of-a-Friend (FOAF) format. You do a query for
your Evolution contacts in Conduit and request them to be moved to the
phone. Conduit (or a lower level component) detects that the source and
destination formats differ, automatically search the Web for a matching
ontology alignment, map the NCO contacts into FOAF and move them to the
phone.

RDF can automate many such processes, but a few components would be
required (or at least be very handy) at the system level such as a
central RDF repository and an ontology mapping service.

One problem that you've skipped over is how Conduit learned to speak to the device in the first place. In this case i've written glue to link SynCE and Conduit, i would surely ship an AirSync ontology with Conduit, or get one shipped with SynCE, rather than depend on internet access to dynamically look one up?

I think this might be nice for the formats and conversions problem, but it doesn't do anything for the transport problem. A generic dbus interface that we could badger applications to implement, or implement our selves via addins, would mean applications like Conduit could benefit without transport glue needing writing specifically for it. That combined with your solution for format conversion would be awesome.

John