Anything about Tenor? & creating a content system -> RDF

[Scott Wheeler]

On Wednesday 10 August 2005 10:44, you wrote:
> There are C implementations of RDF apis - most of them on SF. redland,
> raptor, threestore, ....

For all of the talk of duplicated effort, I've spent the last several hours 
looking around at the various RDF based tools that you've mentioned, the ones 
on Freshmeat and the ones mentioned in my RDF book and so far none of them 
meet our needs.  There's a wealth of things in Java or scripting languages, 
but very little in C / C++.  (Nothing in C++ that I've seen, actually.)

So, there are three that I've seen so far (all C):

*) rdfDB -- BDB based, which isn't suitable for our work since we need a 
"real" database for various reasons already covered on this list this week.

*) 3store -- seems to be the little brother of Redland in some ways with a 
focus on knowledge management.  Only has a MySQL backend, which we can't use 
for licensing reasons (we'll need to be able to link to the client libraries 
from kdelibs, which requires them to be LGPL or less restrictive).  The API 
is also completely undocumented.

*) Redland was the one that I stumbled across from the mention in my RDF book 
(Practical RDF, from O'Reilly).  Raptor seems to just be a part of Redland.  
The API documentation is certainly lacking, but does exist.  The API looks 
generally sane though, but there are parts of it that I don't understand 
immediately.  Offers several storage backends, none of which are suitable for 
us.

Really we need a Postgres backend.  There are other databases that could 
suffice, but they're more obscure.

===============================================================================
But moving on...
===============================================================================

I'd like to try to at least explain a little about how we think and some 
things that will be helpful in our dialog here:

*) Most of us aren't academics; papers are ok, but don't substitute for plain 
explanations.

*) RDF seems complicated to us.  That won't change.  People inside the 
community may view it as simple, but everyone that I've talked to about RDF 
that's an outsider to the semantic web community thinks that RDF is overly 
convoluted.  That means that it's working uphill.

*) Which implies that it needs to have some very tangible benefits for us to 
consider it.  Those don't for example include w3c buy-in, academic acceptance 
or cool-toys-that-someone-wrote-using-it.  We need very concrete cases where 
it will be of benefit to a KDE subsystem.  So far those haven't been 
forthcoming.

===============================================================================
But I think there may be room for compromise...
===============================================================================

What I'd like to suggest is something of a compromise from our perspective.  
You're obviously very convinced about RDF.  That's fine.  We aren't.  So how 
do we move on?

Looking at the RDF APIs available Redland seems to be the best (well, only 
really) candidate.  If we were to come up with an API that we need an 
implementation for (the one that I've been doing using Postgres and the Qt 
SQL API) in the next couple of weeks I think it would be very helpful if 
there were a Redland-based implementation of that backend to compare with.  
But most likely we're not going to write that.

But I believe at the moment Frank is working for you as a slave laborer, err, 
student intern.  If we were to give you an API to implement using Redland 
would you consider putting him (or anyone else, but he'd be a natural 
candidate) on that for a few days to do the backend?  Then we'd be able to 
compare side-by-side with a native Postgres backend in terms of performance 
and complexity.  (Note this would be nothing huge -- maybe 500-ish lines of 
code.)

I should note, just to prevent conflict later on, that there's a very 
significant chance (i.e. most likely, honestly) that we wouldn't end up using 
that later on, but it would at least give us a chance to give RDF a fair 
shot.

For us to consider using that for the real API we'd also need a Postgres 
backend, which all things being ideal would also be provided by you guys, but 
just for testing that's probably not necessary.

I'll be on the road starting tomorrow for about 10 days, but I think a few 
days after that I could get such an API ready for you guys if you're up for 
such.

===============================================================================
An implementation note...
===============================================================================

You know since we've discussed this before that part of Tenor's design and one 
of the main points at which it differs from most ontology based systems is 
that properties -- i.e. predicates -- are to be able to be created in an ad 
hoc fashion.  Relationships are largely contextual and semantics are domain 
specific.

Explicit semantics may be desired by certain uses of the framework, but that 
would be done either by domain specific conventions (i.e. KMail developers 
and KOrganizer developers agree on the semantics for a certain type of 
information in the graph), but those would not be required by the framework.

It may even get to the point that code generation based on a schema format, 
similar to what we do with configuration files in some cases using our 
KConfigXT framework.  (Essentially a schema can be provided and code 
generated based on it, but the KConfig framework doesn't know or care about 
that.)  These would *not* be RDF schemas because they're way too ugly to 
force on KDE application developers, but I don't know enough about RDF 
schemas to say that transformation to that format would be impossible.

But those schemas are a point for later consideration -- not something that's 
going to happen in the next few weeks.

So, long mail -- but hopefully with a few things to chew on...

Cheers,

-Scott

P.S. Could you consider configuring your email client to prefix quoted text 
with "> " -- your mails are really hard to read for us since it's hard to 
tell at a glance what's quoted and what's not.

-- 
There are 10 types of people in the world: Those who understand binary, and 
those who don't.