Graph Elements schema

Aaron J. Seigo aseigo at kde.org
Tue Feb 1 18:25:05 CET 2005


On Tuesday 01 February 2005 09:14, Aaron J. Seigo wrote:
> term searches are done on the content primarily and on the graph nodes
> secondarily,

this is a bit vague .. what i mean is that data in the content storage would 
be searched first for matches, with graph nodes being searched (and ranked) 
second, unless otherwise specified. one of the interesting challenges for the 
content storage is that it needs to deal with multiple data types. should it 
be able to handle arbritrary data types (making the implementation and use of 
it probably far more tricky) or should there be a defined set of data types?

the "defined set" could well be extended at run-time with plugins and 
additional db schemas, but perhaps a set like the following would be enough:

	text
	full text vector
	date
	numeric
	binary

as an example of how the graph itself could be (trivially) searched, here's an 
actual query for "difranco":
 
-------------
copula=# select l.title, l.location from locations l left join mesh m on l.id 
= m.location left join infons i on i.id = m.destination where i.key ~* 
'difranco';

-[ RECORD 1 ]--------------------------------------------------------------
title    | Ani DiFranco - Circle of Light.mp3
location | file:/home/music/Ani Difranco/Ani DiFranco - Circle of Light.mp3
-------------

note that "DiFranco" appearing in the title and location fields of the above 
returned result set is completely incidental and unimportant. what is 
important is that this location was linked to from an infon with a key 
containing "difranco".

this is a trivial example, and not particularly interesting in a real-world 
sense since it assumes that the infon and the location are directly 
connected. this will not always be the case.

and of course queries may be more complex than the simple one above. they may 
contain multiple search terms, or even multiple sets of complementary terms. 
an example of the latter might be something like "show music by ani 
difranco", which should then traverse from Audio -> Artist -> Ani DiFranco to 
a set of locations, or "show music by ani difranco from the 1990s".

but now we're starting to step into the areas of the query language, search 
widgets/api's, graph traversal and result sets.

-- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
-------------- 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/20050201/a1f353d2/attachment.pgp


More information about the Klink mailing list