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
_______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
