Anything about Tenor? & creating a content system -> RDF
Frank Osterfeld
frank.osterfeld at gmx.de
Wed Aug 10 16:56:37 CEST 2005
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/klink/attachments/20050810/4f029108/attachment.pgp
More information about the Klink
mailing list