Convenient Querying in libnepomuk

It has been a while since I blogged and a lot has happened. Not only did we have the second Nepomuk workshop on the “Open Social Semantic Desktop” which I did not report on yet, there is also a lot of stuff going on for KDE 4.4. And since I like blogging about technical stuff so much I will start with that. So here goes:

Queries in KDE 4.4 will be so much simpler (for the developer that is) since we now have the Nepomuk Query API!

Do you remember the days when you tried to write your own SPARQL queries and code looked like this:

Nepomuk::Tag myTag = getOurFancyTag();
QString query
   = QString("select distinct ?r where { ?r %1 %2 . }")
     .arg( Soprano::Node::resourceToN3(Soprano::Vocabulary::NAO::hasTag()) )
     .arg( Soprano::Node::resourceToN3(myTag.resourceUri()) );

Well, using the query API this looks a lot nicer:

Nepomuk::Query::ResourceTerm tagTerm(myTag);
Nepomuk::Query::ComparisonTerm term(Soprano::Vocabulary::NAO::hasTag(), tagTerm);
Nepomuk::Query::Query query(term);
QString queryString = query.toSparqlString();

As you can see you do not need to know any SPARQL anymore. But it gets better. The Query class is integrated with the Nepomuk Query Service via the QueryServiceClient class. This allows to simply let the query service do the querying and receive result change updates – in other words use live searches:

Nepomuk::Query::QueryServiceClient client;
connect(&client, SIGNAL(newEntries(QList<Nepomuk::Query::Result>)),
            this, SLOT(slotNewEntries(QList<Nepomuk::Query::Result>)));

And now just handle the incoming results.

Maybe even nicer is the integration with KIO, i.e. the possibility to list search results as a virtual folder:

KDirModel* model = getFancyDirModel();
Nepomuk::Query::Query query = buildFancyQuery();
KUrl searchUrl = query.toSearchUrl();
model->dirLister()->open( searchUrl );

As you can see it is really simple to list results via KIO (BTW: this is what Dolphin does).

For more examples check the Nepomuk Query API documentation.

13 thoughts on “Convenient Querying in libnepomuk

  1. Sorry for the late API review, but please consider these comments, or reassure me.

    I think there’s a bad smell around N::QueryServiceClient::newEntries() and N::QSC::entriesRemoved():

    * the language is asymmetric – why not entriesAdded()?

    * both signals refer to entries, although the types are different. I guess a resource that was in the query results that has been removed can only be referred to by its URL, hence the list of URLs, but the newEntries are Results – so why not newResults() and resourcesRemoved()? Or for a more KIO like API, just results()?

    • i think renaming of signal and method should be no problem, hope you have some tool with refactor->rename in use in kde.

      if not , welcome 1990

    • Hm, I agree that the signals’ names are not perfect. But calling it “resultsAdded” would be wrong IMHO since the results are not really added but found.

      As for the parameter: we could reuse Result and simply state in the docs for the signal that the score should always be ignored.

  2. Pingback: What We Did Last Summer (And the Rest of 2009) – A Look Back Onto the Nepomuk Development Year With an Obscenely Long Title « Trueg's Blog

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s