[Tracker] datatype management in TrackerSparqlBuilder

[Roberto -MadBob- Guido <bob4mail gmail com>]

Little time ago
( http://mail.gnome.org/archives/tracker-list/2009-November/msg00090.html ) someone already moved some 
observation about limitations in TrackerSparqlBuilder, and I'd like to revamp discussion and understand how 
this interface to Tracker may be improved.

At the actual stage queries are built token by token, with specific
functions to append strings, numbers, dates and other datatypes
depending on the predicate. This is quite tedious since for each
statement a different (a priori known) function must be called, and the
task may be impossible to achieve if the query is dinamically built by
some external configuration (so: developer doesn't know which predicates
will be required, so no which datatype is the correct one to be used).


In my opinion the optimal solution will be:

1) init the client with a map of the used ontologies, such it happens in
libtracker-data/tracker-data-manager.c

2) permit to build queries with a function as

void tracker_sparql_builder_statement (TrackerSparqlBuilder *self,
                                       const char *subject,
                                       const char *predicate,
                                       const char *object);

able to guess type for "predicate" and append "object" in the required
format for that datatype (of course "predicate" must be a valid one, not
a variable).


Two main problems emerges to provide this solution:
1) libtracker-common has to be linked to libtracker-data, and/or
TrackerTurtleReader (used to parse ontologies and populate a
tracker_ontology structure) is moved in libtracker-common as already
TrackerTurtleWriter is.
2) the client needs to know where to found ontologies currently in use
by Tracker.


I consider the alternative solution already implemented in libqttracker
(import into the code a rappresentation of ontologies, generated at
compile time) a problem when Tracker and libqttracker versions are not
perfectly aligned, and/or when an instance of Tracker is customized with
alternative ontologies not included in libqttracker when compiled.


Someone has suggestions about this?

-- 
Roberto -MadBob- Guido
http://claimid.com/madbob