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

[Malte Kiesel]

Scott Wheeler wrote:

[Reinforcements! Leo and Malte here ;-)]

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

If your needs are what we suspect (C++, GPL compatible license, very 
fast, Postgres backend) then finding a proper RDF store implementation 
gets difficult, true.

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

We'll try to work on that (in terms of writing better Wikipedia articles 
on the corresponding topics or something ;-).

However, just keep in mind that in practice, RDF is a data format to 
store objects (= nodes/resources) and their properties (more or less 
key-value-pairs where the value may also reference another object). All 
these things are identified by a URI and use XML datatypes. That's about 
all to know about RDF.

The semantic web thing is mostly on the RDF Schema part. However, RDFS 
again is really nothing more obscure than C++ classes/interfaces. It's 
about definina a schema, defining what classes are subclasses of what 
other classes and what classes may have what properties (the objects or 
instances of these classes are then formulated in RDF).

I'd like to stress that you can of course choose to use RDF without any 
schemas (RDFS).

Well, not the right place to explain RDF(S) here so I'll stop. It's not 
really about data representation formats here anyways.

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

The main benefits probably are that the data gathered by your components 
stays compatible to other projects. It's mainly a data format thing so 
probably import/export functions should suffice.

> 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

We don't really care what backend gets used as long as the actual data 
can be somehow translated to/from RDF. So we'd like to see the API and 
comment. No commitments concerning a performance shootout though, sorry ;-).

Concerning use cases, in the document you mentioned in 
<200508101933.15169.wheeler at kde.org> I only find one use case ("User 
downloads a mail..."). Two if we include the notes idea. This really 
should become more clear. Perhaps it'd be a good idea to work on this on 
IRC or something.

Regards
Malte Kiesel and Leo Sauermann
-- 
Malte Kiesel
DFKI GmbH
http://www.dfki.uni-kl.de/~kiesel/