[Nepomuk] Advances in my alternative query system and several questions

[Ignacio Serantes]

Hi!

As I explain in my presentation I'm working in an alternative system to
nepomuksearch protocol and dolphin's filter panel. My first try was last
weekend with basic success but my sparql builder lack of certain logic
problems, and code was a mess, so I rewritten yesterday from scratch.

I created a new class nsSparqlBuilder to build queries and I think that I
solved all previous logic problems with negations and when you mixtured
different ontologies. In current version supported query syntax is the next:

exact_string = "string" | 'string'
value = exact_string | number | string

term = [ + | - ] value [:ontology]
query = term [ [ and | or ] term ]...

but this is not the final syntax, dates, arithmetic operators (currently
only "!=" "==" and "=" are supported), for numbers and dates basically,
wildcards and parenthesis are not ready yet but probably will be next
weekend.

Here are some working samples extracted for my test cases:
"kim sa rang ha ji won"
"'kim sa rang' -'ha ji won'"
"música:hastag tomtom:hastag or 'son dam bi':hasTag música:hastag"
"guilty 9:rating"
"悪魔と契約し:name"
"'giruti akuma' or 'otoko':description"
"+'abe hiroshi' 'natsukawa yui'"

There is no dependencies between parser engine and query builder so, don't
worry, change query syntax is easy so there is no problem to implement a
syntax similar actual nepomukquery with some enhancements. I at least add
"and" to this version but you can write queries without using it :)

Because a lack of time I only written 15 test cases but some human testers
are welcome. You only need python 2.6 and kde python bindings installed.

While I coding some questions present to me so I ask you guys for help.

1) What would be the search engine behavior when you write a simple query
like this "music"?

Actually I use nsSparqlBuilder.ontologyFilters to determine what filters I
must add to the query. Currently nao:description, nao:identifier, nie:url
and nao:hasTag are supported but this method is manual so I wonder if there
is a better solution out there.

I add two methods, nsSparqlBuilder.AddOntologyFilter() and
nsSparqlBuilder.RemoveOntologyFilter() (not coded yet :)),
to dynamically change the behavior of the query builder but the best
solution would be an automatic method. Any suggestions?

2) There is a method to determine an ontology type?

Actually I store in nsSparqlBuilder.ontologyFilters the type because this
information is required to build filter clause and this is far to be a good
solution. Coerced all data as string has collateral problems with arithmetic
operators and a time penalty so I look for a better solution.

3) When I search for a term I must use relations to search for more items?
At what level I must stop the search?

For example, I search for "korea" (without any ontology) and in my database
there is files tagged with "korea" but there is tags or contacts with
"nao:isRelated" "korea" also. The case is more complex if you thing that
there are many relation kinds "nmm:actor", "nmm:writer", "nco:creator", etc.

Adding all this stuff will produce slow queries so I don't sure about the
better approach. There is even more work to do if you don't stop in first
level so you could finish with a pretty big and slow query.

On the other side, what is the better solution to determine what relations I
must use. I know that all are in documentation but I'm asking for a non
hardcoded solution.

4) What are the basic ontologies that must be implemented?

I currently support the next abbreviates: description, hasTag, rating or
numericRating, prefLabel, title, url or name and tag that are converted to
proper ontology. You even write completed ontologies names, so nao:url and
url are the same and there is no limitations in this case and you can add
any available ontology but, with the problem of point 2, probably this will
not work well with non string ontologies and more work is needed and doing
test are pending.

But the really big problem is with relation ontologies like nao:hasTag. In
this particular case query is "?x nao:hasTag ?y . ?y nao:identifier ?z .
FILTER(?z)", so you need a inner join and you do the real filter in
nao:identifier but this is not applicable to all relations. Some light about
this stuff are welcome.

Thank you for your help.

-- 
Cheers,
Ignacio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/nepomuk/attachments/20110227/7672a4c3/attachment.htm