Re: Future of GNOME: Semantics

[Anders Feder <lists anders feder dk>]

Mikkel,

Thanks for your reply. I knew I could count on you for criticism ;)

man, 16 06 2008 kl. 22:37 +0200, skrev Mikkel Kamstrup Erlandsen:
> This is the exact point of one of my later paragraphs in my earlier
> mail. Why do we need to store it in an RDF store? We have a working
> data model, you can describe it in RDF, but why does it need to be
> stored in it too. Sounds a bit like rubber stamping for the sake of
> rubber stamping.

Ok, I see what is happening here now. We need to distinguish between 'a
database specifically for RDF triples' and 'a SPARQL interface with
several storage backends'. What I meant with an RDF store was the
latter. Soprano is also an example of this sense.

The advantage of a shared SPARQL interface is that we can make complex
queries spanning several disparate databases such as "all e-mails from
contacts in the group 'Work' in Pidgin". We can't do this without
essentially reinventing RDF, and we can't do it with SQL either.

> I do however like the idea of "grafting it on" discussed in another
> branch of this thread.

We're making progress :)

> To say something constructive I think that a more iterative approach
> should be taken to this if you seriously intend to pursue this. Make
> small comprehensible chunks that apps can implement so they don't have
> to go the whole way in one go.

Sure, that's what I'm suggesting. As I stated in my initial post, it
reflected a personal proposal for a way out of the desktop metaphor in
the context of the recent posts of similar spirit on the future of
GNOME.

> You have a lot of big-picture visions (here and on LGO), these are
> good to have, but you will also need to go down into the specifics.

Mandatory remark: check ;)

> Define the dbus apis, ways to expose and exhange data. Concrete
> examples using this. Maybe some small Python examples (or what ever
> language suits you best) - while Python may not be what Gnome will
> (possibly) use in mainstream some working examples are much better at
> spurring feedback and more traction than arm waiving.

I'm already discussing the specifics with Sebastian Trüg and he sounds
very positive about trying to implement what we come up with in Soprano
(I didn't have to entice him with Python examples).

We've been exploring a few ideas (see e.g.
http://live.gnome.org/AndersFeder/SemanticSpace/BusTopology which
defines a D-Bus API - the idea itself is now abandoned), but ultimately
I can't (and shouldn't) pick the right solution for the whole community.

There's a paragraph on the GNOME Love page reading "... make sure to get
the opinion of the affected maintainers or the community because the
project in question could have become obsolete, invalid or yet
implemented with the passing of time."

I appreciate the merits of running code, but constructive dialogue among
the affected parties really has never hurt software development.

> So the bottom line is - you need to do a heck of a lot of heavy
> lifting and boring work for things to take off - and that over a very
> long period of time. This is my experience from Xesam atleast. Posting
> here is good, but don't expect ten people to join your band wagon just
> like that :-)

Michael Gratton has already proposed a next step for this project and
even volunteered to possibly help out with some of it, so I think this
path is quite productive. I really don't see what should keep people
from joining up if they find the idea worthwhile.

Best regards,

-- 
Anders Feder <lists anders feder dk>