Re: Future of GNOME: Semantics

["Mikkel Kamstrup Erlandsen" <mikkel kamstrup gmail com>]

2008/6/16 Anders Feder <lists anders feder dk>:
> Mikkel,
>
> Thanks for your reply.
>
> man, 16 06 2008 kl. 00:52 +0200, skrev Mikkel Kamstrup Erlandsen:
>> To actually understand and use RDF and ontologies "correctly" you need
>> a lot of experience. There's a whole world of new terminology to
>> surmount before you can even begin to grasp what people talk about. I
>> know because I've tried to scale that wall myself (note _tried_ I
>> often feel that I've somehow failed). Triples and relations are just
>> scratching the surface of an iceberg.
>
> I would opt to use a metaphor that does not make people think of the
> sinking of Titanic and say that triples are the 'tip of the pyramid':
> elegantly simple structures with a solid, mathematical foundation.
>
> If the lower portion of the pyramid is made available as platform
> components, application developers would only need to worry about the
> tip of the pyramid.
>
>> Then just starting to include RDF here and there does not come for
>> free even though there are competent libs out there. It will take a
>> massive amount of work because most of the Gnome stack is not written
>> in a way as to take such things into account.
>
> I am not as experienced a GNOME developer as you are, but I beg to
> differ. Data structures equivalent to the triple are used throughout
> GNOME. Take the GConf database for instance: key (predicate) value
> (object) pairs organized in directories (subject).
>
> Namespace the subject and predicate properly and you have RDF.

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.

I do however like the idea of "grafting it on" discussed in another
branch of this thread. Apps should be free to store their data how
they like. The argument for storing it in a real triple store is
probably that we can launch SPARQL queries at it. To me that is
equivalent of requiring everyone to store their data in a sql-database
so we can throw SQL at it (except that SPARQL is the new hype
(compared to SQL)). There are tonnes of reasons why this is not a good
idea, I shall not elaborate on it here (that other people are thinking
this too is evident from the fact that no single app I know of expose
an SQL interface).


>> Also we do have lots of integration in our stack (we could use more,
>> granted) and I actually think that it has worked relatively well so
>> far. And we can certainly get very very far without ever looking at
>> RDF and I sometimes find myself questioning what it really gives to
>> put the RDF rubber stamp on our tools. I mean the data models can
>> always be modelled by RDF no matter how we try to escape it, so in
>> some way it will always be a ghost in the machine. Is there are real
>> need to make this explicit? I have not seen any proof of this in the
>> wild.
>
> There's RDF and there's the Semantic Web. It will be an advantage to
> rely on ontologies already in use on the Semantic Web where possible, so
> we don't have to map back and forth too much at a later point.
>
> It will also be an advantage if developers rely on native RDF storage
> where applicable so we don't have to implement backends later on.
>
>> On a more humanistic note; there is some level of "technology scare"
>> of RDF amongst some developers. It might not be entirely justified,
>> and I don't think that it does anyone any good, but that is how it is.
>> Suddenly high-profiling it in a project where would very much like to
>> attract new devs might be dangerous. That doesn't mean we can't use it
>> though.
>
> I'n not sure how high-profile it would have to be. Maybe something
> similar to the Human Interface Guidelines with a few support libraries
> and services.
>
>> In conclusion I would like to make it clear that I don't have anything
>> against RDF or semantic technologies, I just have this great feeling
>> that once people get hooked on them every problem starts to look like
>> a semantic nail :-)
>
> That is perhaps not entirely untrue, but on the other hand, I don't
> think non-semantic nails are inherently better at all. It would have to
> be determined on a case-by-case basis. But such an evalution can only be
> made if the semantic alternative does in fact exist - hence these posts.

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.

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.
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.

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 :-)

Cheers,
Mikkel