[prev in list] [next in list] [prev in thread] [next in thread] 

List:       klink
Subject:    Re: Anything about Tenor? & creating a content system -> RDF
From:       Frank Osterfeld <frank.osterfeld () gmx ! de>
Date:       2005-08-10 14:56:37
Message-ID: 200508101656.41772.frank.osterfeld () gmx ! de
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Wednesday 10 August 2005 14:21, Kévin Ottens wrote:


> Ok, it's all over the place... does it means that's the best tool for our
> task? That's far from being sure, it really depends the type of
> relationships will be used.
>
> > Fact is: before you now begin to discuss on a graph  serialization
> > format and its query language and so on, you lose time that you would
> > otherwise write code. Its really a waste of time to discuss graph
> > programming interfaces while I teach hundreds of students how to use
> > existing APIs.

It would be good to develop a set of use cases where Tenor will be used, with 
examples including

a) What kind of information/relationships will be stored
b) how they could be represented in the graph in terms of nodes, links etc.
c) How retrieval is supposed to work

There were different ideas, from more high-level approaches, like linking 
related resources (documents, websites, email addresses...), to a lower 
level, creating nodes for single words from the fulltext of a document.

To me as an application developer (and I follow Tenor development, unlike the 
vast majority of KDE devels who don't) it's still unclear how I am supposed 
to use Tenor to store information, and which ways Tenor will offer me to 
retrieve useful information I can use in my app (preferably high-level 
methods that every KDE developer can use without studying graph algorithms or 
IR). 
Until there is some more clarity on this, I can't decide how we should 
integrate KAT and Tenor or whether we should use RDF or not etc. pp.

If Tenor ends up being an RDF clone (without the upper SW layers using 
semantics though), we are faster reusing RDF stores like Redland and 
languages like SPARQL for querying. The current model described in Scott's 
paper isn't that different from RDF and could be mapped easily I think. The 
Tenor API could hide nasty RDF details such as reification. 
On the other hand, if the tenor graph stores relationships that are 
fundamentally different from what you usually have in the RDF world, it 
doesn't make that much sense to do a complex mapping to RDF and back.

In short: IMHO it's hard to discuss any design decisions without more concrete 
use cases. 

Regards,

Frank

[Attachment #5 (application/pgp-signature)]

_______________________________________________
Klink mailing list
Klink@kde.org
https://mail.kde.org/mailman/listinfo/klink


[prev in list] [next in list] [prev in thread] [next in thread]