Development/Tutorials/Metadata/Nepomuk/AdvancedQueries - Revision history

Vishesh: /* Full text queries before KDE 4.4 */ Remove it - totally useless

2012-08-24T08:16:52Z

‎Full text queries before KDE 4.4: Remove it - totally useless

Dvratil: XMLSchema::xmlNamespace() -> XMLSchema::xsdNamespace()

2012-02-11T12:25:04Z

XMLSchema::xmlNamespace() -> XMLSchema::xsdNamespace()

Neverendingo: Text replace - "`" to ""`


2011-06-29T21:01:04Z
Text replace - "<code cppqt="cppqt">" to "<syntaxhighlight lang="cpp-qt">"

				
				
				
				
			
			← Older revision
			Revision as of 21:01, 29 June 2011
			
Line 169:
Line 169:
  We convert the object literal into a string and match it to a regular expression ignoring case. This works but may be slow. Using the Soprano lucene full text index we perform this query as follows:     We convert the object literal into a string and match it to a regular expression ignoring case. This works but may be slow. Using the Soprano lucene full text index we perform this query as follows:  
    
− <code cppqt="cppqt"> + <syntaxhighlight lang="cpp-qt">
  Soprano::QueryResultIterator it =   Soprano::QueryResultIterator it =
      model->executeQuery( "nepomuk",       model->executeQuery( "nepomuk",
Line 189:
Line 189:
  Of course it is possible to use the full range of the [http://lucene.apache.org/java/docs/queryparsersyntax.html Lucene Query Language]. Another simple example would be to only match a certain property:     Of course it is possible to use the full range of the [http://lucene.apache.org/java/docs/queryparsersyntax.html Lucene Query Language]. Another simple example would be to only match a certain property:  
    
− <code cppqt="cppqt"> + <syntaxhighlight lang="cpp-qt">
  QString query =   QString query =
       Soprano::Vocabulary::RDFS::label().toString()        Soprano::Vocabulary::RDFS::label().toString()



Neverendingo: Text replace - "" to ""

2011-06-29T20:44:56Z
Text replace - "<code>" to "<syntaxhighlight lang="text">"

				
				
				
				
			
			← Older revision
			Revision as of 20:44, 29 June 2011
			
Line 134:
Line 134:
  This allows to combine graph queries with full text queries in a nice way:   This allows to combine graph queries with full text queries in a nice way:
    
− <code> + <syntaxhighlight lang="text">
  select ?r where { ?r nao:prefLabel ?label .   select ?r where { ?r nao:prefLabel ?label .
                     ?label bif:contains 'nepomuk' . }                      ?label bif:contains 'nepomuk' . }
Line 143:
Line 143:
  Of course wildcards are supported, too. However, be aware that when using wildcards the expression itself needs to be enclosed in quotes as follows:   Of course wildcards are supported, too. However, be aware that when using wildcards the expression itself needs to be enclosed in quotes as follows:
    
− <code> + <syntaxhighlight lang="text">
  select ?r where { ?r nao:prefLabel ?label .   select ?r where { ?r nao:prefLabel ?label .
                     ?label bif:contains "'nepomuk*'" . }                      ?label bif:contains "'nepomuk*'" . }
Line 161:
Line 161:
  Let us assume that we want to search resources that are related to some literal object that matches the value "nepomuk". In SPARQL this would mean to query for:     Let us assume that we want to search resources that are related to some literal object that matches the value "nepomuk". In SPARQL this would mean to query for:  
    
− <code> + <syntaxhighlight lang="text">
  select ?r where { ?r ?p ?o .   select ?r where { ?r ?p ?o .
                     FILTER REGEX(STR(?o),'nepomuk', 'i') .                        FILTER REGEX(STR(?o),'nepomuk', 'i') .  



Neverendingo: Text replace - "" to ""
2011-06-29T20:42:51Z
Text replace - "</code>" to "</syntaxhighlight>"

				
				
				
				
			
			← Older revision
			Revision as of 20:42, 29 June 2011
			
Line 19:
Line 19:
  <syntaxhighlight lang="cpp-qt">   <syntaxhighlight lang="cpp-qt">
  Soprano::Model* model = Nepomuk::ResourceManager::instance()->mainModel();   Soprano::Model* model = Nepomuk::ResourceManager::instance()->mainModel();
− </code> + </syntaxhighlight>
    
  ===Query Basics===   ===Query Basics===
Line 34:
Line 34:
      Soprano::BindingSet allBindings = *it;       Soprano::BindingSet allBindings = *it;
  }   }
− </code> + </syntaxhighlight>
    
    
Line 61:
Line 61:
      myResourceList << Nepomuk::Resource( it.binding( "r" ).uri() );       myResourceList << Nepomuk::Resource( it.binding( "r" ).uri() );
  }   }
− </code> + </syntaxhighlight>
    
  We begin by constructing the SPARQL query string. It is a simple query and if you know SQL it should be easy to understand. Basically we select resources that match the patterns in the ''where'' statement. In this case the resource needs to have the ''hasTag'' property with object ''myTag''. As we can see, Soprano already provides a set of standard URIs as static instances in the [http://api.kde.org/kdesupport-api/kdesupport-apidocs/soprano/html/namespaceSoprano_1_1Vocabulary.html Soprano::Vocabulary] namespace. And since we have the Nepomuk resource object for the tag we can simply use its unique URI to directly access the tagged resources.   We begin by constructing the SPARQL query string. It is a simple query and if you know SQL it should be easy to understand. Basically we select resources that match the patterns in the ''where'' statement. In this case the resource needs to have the ''hasTag'' property with object ''myTag''. As we can see, Soprano already provides a set of standard URIs as static instances in the [http://api.kde.org/kdesupport-api/kdesupport-apidocs/soprano/html/namespaceSoprano_1_1Vocabulary.html Soprano::Vocabulary] namespace. And since we have the Nepomuk resource object for the tag we can simply use its unique URI to directly access the tagged resources.
Line 79:
Line 79:
        .arg( Soprano::Node::resourceToN3(Soprano::Vocabulary::RDFS::label()) )         .arg( Soprano::Node::resourceToN3(Soprano::Vocabulary::RDFS::label()) )
        .arg( Soprano::Node(myTagLabel).toN3() );         .arg( Soprano::Node(myTagLabel).toN3() );
− </code> + </syntaxhighlight>
    
  This already looks a lot more confusing as the previous example but that is mainly due to the QString argument paramters. Let's clean it up w bit by using SPARQL prefix declarations:   This already looks a lot more confusing as the previous example but that is mainly due to the QString argument paramters. Let's clean it up w bit by using SPARQL prefix declarations:
Line 95:
Line 95:
        .arg( Soprano::Node::resourceToN3(Soprano::Vocabulary::XMLSchema::xlsNamespace()) )         .arg( Soprano::Node::resourceToN3(Soprano::Vocabulary::XMLSchema::xlsNamespace()) )
        .arg( myTagLabel );         .arg( myTagLabel );
− </code> + </syntaxhighlight>
    
  Both queries are the same and it is up to the query writer to decide which version he or she prefers. We are just presenting both versions here for demonstration purposes.   Both queries are the same and it is up to the query writer to decide which version he or she prefers. We are just presenting both versions here for demonstration purposes.
Line 119:
Line 119:
        .arg( myTag.resourceUri().toString() )         .arg( myTag.resourceUri().toString() )
        .arg( Soprano::Node::literalToN3( firstOfJanuary ) );         .arg( Soprano::Node::literalToN3( firstOfJanuary ) );
− </code> + </syntaxhighlight>
    
  This query contains three new concepts:   This query contains three new concepts:
Line 137:
Line 137:
  select ?r where { ?r nao:prefLabel ?label .   select ?r where { ?r nao:prefLabel ?label .
                     ?label bif:contains 'nepomuk' . }                      ?label bif:contains 'nepomuk' . }
− </code> + </syntaxhighlight>
    
  The query above will find any resources that contain ''nepomuk'' in their label.   The query above will find any resources that contain ''nepomuk'' in their label.
Line 146:
Line 146:
  select ?r where { ?r nao:prefLabel ?label .   select ?r where { ?r nao:prefLabel ?label .
                     ?label bif:contains "'nepomuk*'" . }                      ?label bif:contains "'nepomuk*'" . }
− </code> + </syntaxhighlight>
    
  For most simple queries (simple queries do not use any back-referencing for example) the [[../NepomukQuery|Nepomuk desktop query API]] should be sufficient.   For most simple queries (simple queries do not use any back-referencing for example) the [[../NepomukQuery|Nepomuk desktop query API]] should be sufficient.
Line 165:
Line 165:
                     FILTER REGEX(STR(?o),'nepomuk', 'i') .                        FILTER REGEX(STR(?o),'nepomuk', 'i') .  
                     FILTER isLiteral(?o) . }                      FILTER isLiteral(?o) . }
− </code>   + </syntaxhighlight>  
    
  We convert the object literal into a string and match it to a regular expression ignoring case. This works but may be slow. Using the Soprano lucene full text index we perform this query as follows:     We convert the object literal into a string and match it to a regular expression ignoring case. This works but may be slow. Using the Soprano lucene full text index we perform this query as follows:  
Line 178:
Line 178:
      double score = it.binding( "score" ).literal().toDouble();       double score = it.binding( "score" ).literal().toDouble();
  }   }
− </code>   + </syntaxhighlight>  
    
  Here we make use of the fact that Soprano allows to add new [http://api.kde.org/kdesupport-api/kdesupport-apidocs/soprano/html/namespaceSoprano_1_1Query.http user defined query languages]. Also we use the fixed mapping from CLucene query results to Soprano query bindings as defined in [http://api.kde.org/kdesupport-api/kdesupport-apidocs/soprano/html/classSoprano_1_1Index_1_1IndexFilterModel.html Soprano::Index::IndexFilterModel]:     Here we make use of the fact that Soprano allows to add new [http://api.kde.org/kdesupport-api/kdesupport-apidocs/soprano/html/namespaceSoprano_1_1Query.http user defined query languages]. Also we use the fixed mapping from CLucene query results to Soprano query bindings as defined in [http://api.kde.org/kdesupport-api/kdesupport-apidocs/soprano/html/classSoprano_1_1Index_1_1IndexFilterModel.html Soprano::Index::IndexFilterModel]:  
Line 197:
Line 197:
                           Soprano::Query::QueryLanguageUser,                            Soprano::Query::QueryLanguageUser,
                           "lucene" );                            "lucene" );
− </code> + </syntaxhighlight>



Neverendingo: Text replace - "" to ""

2011-06-29T20:29:39Z
Text replace - "<code cppqt>" to "<syntaxhighlight lang="cpp-qt">"

				
				
				
				
			
			← Older revision
			Revision as of 20:29, 29 June 2011
			
Line 17:
Line 17:
  Nepomuk uses one main [http://soprano.sourceforge.net/apidox/stable/classSoprano_1_1Model.html Soprano model] which is accessed through the [http://api.kde.org/4.x-api/kdelibs-apidocs/nepomuk/html/classNepomuk_1_1ResourceManager.html ResourceManager]:   Nepomuk uses one main [http://soprano.sourceforge.net/apidox/stable/classSoprano_1_1Model.html Soprano model] which is accessed through the [http://api.kde.org/4.x-api/kdelibs-apidocs/nepomuk/html/classNepomuk_1_1ResourceManager.html ResourceManager]:
    
− <code cppqt> + <syntaxhighlight lang="cpp-qt">
  Soprano::Model* model = Nepomuk::ResourceManager::instance()->mainModel();   Soprano::Model* model = Nepomuk::ResourceManager::instance()->mainModel();
  </code>   </code>
Line 25:
Line 25:
  Basically performing a query with Nepomuk/Soprano always looks as follows (More details on using the iterator in the [http://api.kde.org/kdesupport-api/kdesupport-apidocs/soprano/html/classSoprano_1_1QueryResultIterator.html Soprano API documentation].):   Basically performing a query with Nepomuk/Soprano always looks as follows (More details on using the iterator in the [http://api.kde.org/kdesupport-api/kdesupport-apidocs/soprano/html/classSoprano_1_1QueryResultIterator.html Soprano API documentation].):
    
− <code cppqt> + <syntaxhighlight lang="cpp-qt">
  QString query = getFancyQueryString();   QString query = getFancyQueryString();
  Soprano::QueryResultIterator it   Soprano::QueryResultIterator it
Line 41:
Line 41:
  Let us have a look at how a query can be constructed. As an example we will query for all resources that are tagged with a certain tag. Let's imagine that we have a reference to this tag stored in ''myTag''. (Please ignore the fact that Nepomuk::Tag::tagOf essentially returns the same information. After all, we are here to learn how it works.)   Let us have a look at how a query can be constructed. As an example we will query for all resources that are tagged with a certain tag. Let's imagine that we have a reference to this tag stored in ''myTag''. (Please ignore the fact that Nepomuk::Tag::tagOf essentially returns the same information. After all, we are here to learn how it works.)
    
− <code cppqt> + <syntaxhighlight lang="cpp-qt">
  #include <Soprano/Model>   #include <Soprano/Model>
  #include <Soprano/QueryResultIterator>   #include <Soprano/QueryResultIterator>
Line 69:
Line 69:
  Also no problem with SPARQL:   Also no problem with SPARQL:
    
− <code cppqt> + <syntaxhighlight lang="cpp-qt">
  QString myTagLabel = getFancytagLabel();   QString myTagLabel = getFancytagLabel();
    
Line 83:
Line 83:
  This already looks a lot more confusing as the previous example but that is mainly due to the QString argument paramters. Let's clean it up w bit by using SPARQL prefix declarations:   This already looks a lot more confusing as the previous example but that is mainly due to the QString argument paramters. Let's clean it up w bit by using SPARQL prefix declarations:
    
− <code cppqt> + <syntaxhighlight lang="cpp-qt">
  QString query   QString query
      = QString("PREFIX nao: %1 "       = QString("PREFIX nao: %1 "
Line 105:
Line 105:
  In [[../RDFIntroduction|Introduction to RDF and Ontologies]] we briefly learned about ''named graphs'' or ''context'' which make up the fourth part of each statement in Nepomuk. We can now use this information to filter our results based on creation dates. Imagine for example that we want to retrieve all resources tagged before the first of January 2008. We do this by introducing some more complex SPARQL syntax. For simplicity we go back to our first example of matching the tag URI directly to keep the query from getting too unreadable. But of course both can be combined. (Keep in mind that we only use the prefix syntax here for readability. In actual code it may be better to directly add the URIs from [http://api.kde.org/kdesupport-api/kdesupport-apidocs/soprano/html/namespaceSoprano_1_1Vocabulary.html Soprano::Vocabulary] to prevent typing errors in property and class names.)   In [[../RDFIntroduction|Introduction to RDF and Ontologies]] we briefly learned about ''named graphs'' or ''context'' which make up the fourth part of each statement in Nepomuk. We can now use this information to filter our results based on creation dates. Imagine for example that we want to retrieve all resources tagged before the first of January 2008. We do this by introducing some more complex SPARQL syntax. For simplicity we go back to our first example of matching the tag URI directly to keep the query from getting too unreadable. But of course both can be combined. (Keep in mind that we only use the prefix syntax here for readability. In actual code it may be better to directly add the URIs from [http://api.kde.org/kdesupport-api/kdesupport-apidocs/soprano/html/namespaceSoprano_1_1Vocabulary.html Soprano::Vocabulary] to prevent typing errors in property and class names.)
    
− <code cppqt> + <syntaxhighlight lang="cpp-qt">
  QDateTime firstOfJanuary = getFirstOfJanuary();   QDateTime firstOfJanuary = getFirstOfJanuary();
    



Trueg: /* Advanced Sparql Queries in Nepomuk */
2011-06-02T16:54:57Z
‎Advanced Sparql Queries in Nepomuk

				
				
				
				
			
			← Older revision
			Revision as of 16:54, 2 June 2011
			
Line 9:
Line 9:
  ==Advanced Sparql Queries in Nepomuk==   ==Advanced Sparql Queries in Nepomuk==
    
− In [[../NepomukServer|Nepomuk Server]] we learned how to access the Nepomuk Server to get a [http://api.kde.org/kdesupport-api/kdesupport-apidocs/soprano/html/classSoprano_1_1Model.html Soprano::Model] instance. We will now take a look at how to perform queries against the Nepomuk data repository. + We will now take a look at how to perform queries against the Nepomuk data repository.
    
  {{Note|The queries presented here a pretty low-level. Only use this approach if the [[../NepomukQuery|Nepomuk Query API]] does not fulfill your needs.}}   {{Note|The queries presented here a pretty low-level. Only use this approach if the [[../NepomukQuery|Nepomuk Query API]] does not fulfill your needs.}}
  + 
  + ===The Main Model===
  + 
  + Nepomuk uses one main [http://soprano.sourceforge.net/apidox/stable/classSoprano_1_1Model.html Soprano model] which is accessed through the [http://api.kde.org/4.x-api/kdelibs-apidocs/nepomuk/html/classNepomuk_1_1ResourceManager.html ResourceManager]:
  + 
  + <code cppqt>
  + Soprano::Model* model = Nepomuk::ResourceManager::instance()->mainModel();
  + </code>
    
  ===Query Basics===   ===Query Basics===



Trueg at 13:02, 19 November 2010
2010-11-19T13:02:20Z


				
				
				
				
			
			← Older revision
			Revision as of 13:02, 19 November 2010
			
Line 11:
Line 11:
  In [[../NepomukServer|Nepomuk Server]] we learned how to access the Nepomuk Server to get a [http://api.kde.org/kdesupport-api/kdesupport-apidocs/soprano/html/classSoprano_1_1Model.html Soprano::Model] instance. We will now take a look at how to perform queries against the Nepomuk data repository.   In [[../NepomukServer|Nepomuk Server]] we learned how to access the Nepomuk Server to get a [http://api.kde.org/kdesupport-api/kdesupport-apidocs/soprano/html/classSoprano_1_1Model.html Soprano::Model] instance. We will now take a look at how to perform queries against the Nepomuk data repository.
    
− {{Note|The queries presented here a pretty low-level. Soon Nepomuk will provide a wrapper class that makes every-day queries much simpler.}} + {{Note|The queries presented here a pretty low-level. Only use this approach if the [[../NepomukQuery|Nepomuk Query API]] does not fulfill your needs.}}
    
  ===Query Basics===   ===Query Basics===



Trueg: /* Full text queries */
2009-11-20T10:13:45Z
‎Full text queries

				
				
				
				
			
			← Older revision
			Revision as of 10:13, 20 November 2009
			
Line 120:
Line 120:
    
    
− ===Full text queries=== + === Full text queries ===
    
− While SPARQL in theory supports full text queries through the [http://www.w3.org/TR/rdf-sparql-query/#funcex-regex ''REGEX FILTER''] keywords the storage backends do not have their own real full text index. Thus, a full text search using SPARQL FILTER may become very slow if there are many statements to filter. + With KDE 4.4 Nepomuk depends on [http://soprano.sourceforge.net/apidox/trunk/soprano_backend_virtuoso.html Virtuoso] for data storage. Virtuoso brings a lot of nice [http://docs.openlinksw.com/virtuoso/rdfsparql.html#sparqlextensions extensions to SPARQL]. Most importantly the full text search which is used through the artificial ''bif:contains'' property.  
    
− That is why in Soprano we have the [http://clucene.sourceforge.net/ CLucene] based [http://api.kde.org/kdesupport-api/kdesupport-apidocs/soprano/html/namespaceSoprano_1_1Index.html full text index model]. It is stacked on top of the actual storage model within the Nepomuk Server and provides a full text index on all literal object nodes in the repository. Since Soprano does not have a fancy query API yet (using plain strings as queries does not count as ''fancy'') full text queries have still to be performed separately. This may be inconvenient but will hopefully be solved in Soprano 3. + This allows to combine graph queries with full text queries in a nice way:
    
− So for now we have to learn a second way to query the repository: using the [http://lucene.apache.org/java/docs/queryparsersyntax.html Lucene Query Language]. But that is much easier in most cases. + <code>
  + select ?r where { ?r nao:prefLabel ?label .
  +                   ?label bif:contains 'nepomuk' . }
  + </code>
  +  
  + The query above will find any resources that contain ''nepomuk'' in their label.
    
− Let us assume that we want to search resources that are related to some literal object that matches the value "nepomuk". In SPARQL this would mean to query for: + Of course wildcards are supported, too. However, be aware that when using wildcards the expression itself needs to be enclosed in quotes as follows:
  +  
  + <code>
  + select ?r where { ?r nao:prefLabel ?label .
  +                   ?label bif:contains "'nepomuk*'" . }
  + </code>
  +  
  + For most simple queries (simple queries do not use any back-referencing for example) the [[../NepomukQuery|Nepomuk desktop query API]] should be sufficient.
  +  
  +  
  + === Full text queries before KDE 4.4  ===
  +  
  + While SPARQL in theory supports full text queries through the [http://www.w3.org/TR/rdf-sparql-query/#funcex-regex ''REGEX FILTER''] keywords the storage backends do not have their own real full text index. Thus, a full text search using SPARQL FILTER may become very slow if there are many statements to filter. 
  +  
  + That is why in Soprano we have the [http://clucene.sourceforge.net/ CLucene] based [http://api.kde.org/kdesupport-api/kdesupport-apidocs/soprano/html/namespaceSoprano_1_1Index.html full text index model]. It is stacked on top of the actual storage model within the Nepomuk Server and provides a full text index on all literal object nodes in the repository. Since Soprano does not have a fancy query API yet (using plain strings as queries does not count as ''fancy'') full text queries have still to be performed separately. This may be inconvenient but will hopefully be solved in Soprano 3. 
  +  
  + So for now we have to learn a second way to query the repository: using the [http://lucene.apache.org/java/docs/queryparsersyntax.html Lucene Query Language]. But that is much easier in most cases. 
  +  
  + Let us assume that we want to search resources that are related to some literal object that matches the value "nepomuk". In SPARQL this would mean to query for:  
    
  <code>   <code>
Line 134:
Line 157:
                     FILTER REGEX(STR(?o),'nepomuk', 'i') .                        FILTER REGEX(STR(?o),'nepomuk', 'i') .  
                     FILTER isLiteral(?o) . }                      FILTER isLiteral(?o) . }
− </code> + </code>  
    
− We convert the object literal into a string and match it to a regular expression ignoring case. This works but may be slow. Using the Soprano lucene full text index we perform this query as follows: + We convert the object literal into a string and match it to a regular expression ignoring case. This works but may be slow. Using the Soprano lucene full text index we perform this query as follows:  
    
− <code cppqt> + <code cppqt="cppqt">
  Soprano::QueryResultIterator it =   Soprano::QueryResultIterator it =
      model->executeQuery( "nepomuk",       model->executeQuery( "nepomuk",
Line 147:
Line 170:
      double score = it.binding( "score" ).literal().toDouble();       double score = it.binding( "score" ).literal().toDouble();
  }   }
− </code> + </code>  
    
− Here we make use of the fact that Soprano allows to add new [http://api.kde.org/kdesupport-api/kdesupport-apidocs/soprano/html/namespaceSoprano_1_1Query.http user defined query languages]. Also we use the fixed mapping from CLucene query results to Soprano query bindings as defined in  [http://api.kde.org/kdesupport-api/kdesupport-apidocs/soprano/html/classSoprano_1_1Index_1_1IndexFilterModel.html Soprano::Index::IndexFilterModel]: + Here we make use of the fact that Soprano allows to add new [http://api.kde.org/kdesupport-api/kdesupport-apidocs/soprano/html/namespaceSoprano_1_1Query.http user defined query languages]. Also we use the fixed mapping from CLucene query results to Soprano query bindings as defined in [http://api.kde.org/kdesupport-api/kdesupport-apidocs/soprano/html/classSoprano_1_1Index_1_1IndexFilterModel.html Soprano::Index::IndexFilterModel]:  
    
− * Binding ''resource'' always gives the matched resource. + *Binding ''resource'' always gives the matched resource.  
− * Binding ''score'' always gives the lucene score (between 0 and 1). + *Binding ''score'' always gives the lucene score (between 0 and 1).
    
− These results can now be reused to perform further SPARQL queries. + These results can now be reused to perform further SPARQL queries.  
    
− Of course it is possible to use the full range of the [http://lucene.apache.org/java/docs/queryparsersyntax.html Lucene Query Language]. Another simple example would be to only match a certain property: + Of course it is possible to use the full range of the [http://lucene.apache.org/java/docs/queryparsersyntax.html Lucene Query Language]. Another simple example would be to only match a certain property:  
    
− <code cppqt> + <code cppqt="cppqt">
  QString query =   QString query =
       Soprano::Vocabulary::RDFS::label().toString()        Soprano::Vocabulary::RDFS::label().toString()



Grundleborg: Fix a couple of errors in code samples
2009-11-07T17:33:45Z
Fix a couple of errors in code samples

				
				
				
				
			
			← Older revision
			Revision as of 17:33, 7 November 2009
			
Line 43:
Line 43:
    
  QString query   QString query
−     = QString("select distinct ?r where { "?r %1 %2 . "}") +     = QString("select distinct ?r where { ?r %1 %2 . }")
        .arg( Soprano::Node::resourceToN3(Soprano::Vocabulary::NAO::hasTag()) )         .arg( Soprano::Node::resourceToN3(Soprano::Vocabulary::NAO::hasTag()) )
        .arg( Soprano::Node::resourceToN3(myTag.resourceUri()) );         .arg( Soprano::Node::resourceToN3(myTag.resourceUri()) );
Line 51:
Line 51:
                             Soprano::Query::QueryLanguageSparql );                              Soprano::Query::QueryLanguageSparql );
  while( it.next() ) {   while( it.next() ) {
−     myResourceList << Nepomuk::Resource( it.binding( "r" ) ); +     myResourceList << Nepomuk::Resource( it.binding( "r" ).uri() );
  }   }
  </code>   </code>

@@ Line 93: / Line 93: @@
       .arg( Soprano::Node::resourceToN3(Soprano::Vocabulary::NAO::naoNamespace()) )
       .arg( Soprano::Node::resourceToN3(Soprano::Vocabulary::RDFS::rdfsNamespace()) )
-      .arg( Soprano::Node::resourceToN3(Soprano::Vocabulary::XMLSchema::xlsNamespace()) )
+      .arg( Soprano::Node::resourceToN3(Soprano::Vocabulary::XMLSchema::xsdNamespace()) )
       .arg( myTagLabel );
 </syntaxhighlight>

← Older revision		Revision as of 08:16, 24 August 2012
Line 149:		Line 149:

	For most simple queries (simple queries do not use any back-referencing for example) the [[../NepomukQuery\|Nepomuk desktop query API]] should be sufficient.		For most simple queries (simple queries do not use any back-referencing for example) the [[../NepomukQuery\|Nepomuk desktop query API]] should be sufficient.
−
−
−	~~=== Full text queries before KDE 4.4 ===~~
−
−	While SPARQL in theory supports full text queries through the [http://www.w3.org/TR/rdf-sparql-query/#funcex-regex ''REGEX FILTER''] keywords the storage backends do not have their own real full text index. Thus, a full text search using SPARQL FILTER may become very slow if there are many statements to filter.
−
−	That is why in Soprano we have the [http://clucene.sourceforge.net/ CLucene] based [http://api.kde.org/kdesupport-api/kdesupport-apidocs/soprano/html/namespaceSoprano_1_1Index.html full text index model]. It is stacked on top of the actual storage model within the Nepomuk Server and provides a full text index on all literal object nodes in the repository. Since Soprano does not have a fancy query API yet (using plain strings as queries does not count as ''fancy'') full text queries have still to be performed separately. This may be inconvenient but will hopefully be solved in Soprano 3.
−
−	~~So for now we have to learn a second way to query the repository: using the [http://lucene.apache.org/java/docs/queryparsersyntax.html Lucene Query Language]. But that is much easier in most cases.~~
−
−	~~Let us assume that we want to search resources that are related to some literal object that matches the value "nepomuk". In SPARQL this would mean to query for:~~
−
−	~~<syntaxhighlight lang="text">~~
−	~~select ?r where { ?r ?p ?o .~~
−	~~FILTER REGEX(STR(?o),'nepomuk', 'i') .~~
−	~~FILTER isLiteral(?o) . }~~
−	~~</syntaxhighlight>~~
−
−	~~We convert the object literal into a string and match it to a regular expression ignoring case. This works but may be slow. Using the Soprano lucene full text index we perform this query as follows:~~
−
−	~~<syntaxhighlight lang="cpp-qt">~~
−	~~Soprano::QueryResultIterator it =~~
−	~~model->executeQuery( "nepomuk",~~
−	~~Soprano::Query::QueryLanguageUser,~~
−	~~"lucene" );~~
−	~~while( it.next() ) {~~
−	~~QUrl resource = it.binding( "resource" ).uri();~~
−	~~double score = it.binding( "score" ).literal().toDouble();~~
−	}
−	~~</syntaxhighlight>~~
−
−	Here we make use of the fact that Soprano allows to add new [http://api.kde.org/kdesupport-api/kdesupport-apidocs/soprano/html/namespaceSoprano_1_1Query.http user defined query languages]. Also we use the fixed mapping from CLucene query results to Soprano query bindings as defined in [http://api.kde.org/kdesupport-api/kdesupport-apidocs/soprano/html/classSoprano_1_1Index_1_1IndexFilterModel.html Soprano::Index::IndexFilterModel]:
−
−	*Binding ''resource'' always gives the matched resource.
−	*Binding ''score'' always gives the lucene score (between 0 and 1).
−
−	~~These results can now be reused to perform further SPARQL queries.~~
−
−	Of course it is possible to use the full range of the [http://lucene.apache.org/java/docs/queryparsersyntax.html Lucene Query Language]. Another simple example would be to only match a certain property:
−
−	~~<syntaxhighlight lang="cpp-qt">~~
−	~~QString query =~~
−	~~Soprano::Vocabulary::RDFS::label().toString()~~
−	~~+ ':' + "nepomuk";~~
−	~~Soprano::QueryResultIterator it =~~
−	~~model->executeQuery( query,~~
−	~~Soprano::Query::QueryLanguageUser,~~
−	~~"lucene" );~~
−	~~</syntaxhighlight>~~