Semantic Query Interface for the Contenthub (was Re: Updates to LMF/Stanbol integration)

[Rupert Westenthaler <ru...@gmail.com>]

Hi Anil, all

Created also an own thread for this topic …

Currently my focus is not (yet) on the implementation, but much more on how features like

* Entity substitution (replacing "Paris" in a query with the entity "http://dbpedia.org/resource/Paris")
* Entity Facets (adding facets for Entities used  or substituted in the Users query)
* Semantic Facets (adding Facets and possible special UI elements) based on the type of Entities used in the Query or the type Instances selected by query)

I clearly agree that the

* Entityhub could be used to implement Entity substitution and Entity Facets 
* Ontologies managed by the Ontonet component could be used to provide Semantic Facets

and that the current implementations of the Contenthub provides already a lot of functionality related to that. However I think before we start to implement we need first a more clear picture how all such features could help End-Users to interact with the Knowledge-Space we want to manage in the Contenthub.


So if people could share Ideas, existing Examples of cool search interfaces … it would be really helpful!


Some links to existing resources of the IKS project:

* For the first Community Meeting of the IKS project I created an presentation on semantic search [1]. I think some of the concepts presented by this presentation are still highly relevant.
* The UserStories[2] 
    * "S01" mentions "Entity Facets"
    * "S04" could be supported by "Entity substitution" but goes much further than that
    * "S20" suggest query and result contextualization based on user specific profiles. Maybe a feature we might also want to consider when defining the API
    * "S27" includes "Entity substitution" and "Semantic Facets"

Sebastian/Jakob maybe you could also provide a short overview about related resources/demos based on the work on the LMF


best
Rupert

[1] http://www.interactive-knowledge.org/sites/www.interactive-knowledge.org/files/iks_semantic_search_20090528_rw.pdf
[2] http://wiki.iks-project.eu/index.php/User-stories


On 28.10.2011, at 10:07, Ali Anil SINACI wrote:

> 
> 
>>>> * The Semantic Search Inteface: The Contenthub currently defines it's own query API (supports keyword based search as well as "field ->   value" like constraints, supports facets). The LMF directly exposes the RESTful API of the semantic Solr index. I strongly prefer the approach of the LMF, because the two points already described above.
>>> We think that we do not have to make a selection here. We can keep a simple wrap-up on the Solr interface (contenthub's own query API) while providing the Solr RESTful API as is. IMO a wrap-up on Solr interface would be beneficial. On the other hand, in this interface we try to make use of an ontology to be used in OntologyResourceSearchEngine. This might help to figure out new keywords based on the subsumption hierarchy inside the ontology. However, I think this may lead to performance issues and may not be useful at all. We can decide on this later.
>> You forgot to mention one additional advantage for using the Solr RESTful API: If we do that one could create the Semantic Index and than copy it over to some other SolrServer without the need to run Stanbol directly on the production infrastructure.
>> 
>> In general I would suggest to first focus the discussion on the unique features we would like to provide with the Semantic Search component. I already included three features I would like to have in my first Mail (Query preprocessing, Entity Facets, Semantic Facets). As you now mention the OntologyResourceSearchEngine is very relevant in relation to such features.
>> However adding such features must not necessarily mean to create an own query language. One could also try to add such features directly to Solr by implementing some Solr extensions.
>> 
> 
> Let me briefly comment in your suggestions about the semantic search.
> 
>>>>  But I am also the opinion that a semantic search interface should at least provide the following three additional features:
>>>>     1. Query preprocessing: e.g. substitute  "Paris" in the query with "http://dbpedia.org/resource/Paris";
>>>>     2. Entity Facets: if a keyword matches a Entity (e.g. "Paris" ->   "dbpedia:Paris", "dbpedia:Paris_Texas", "dbpedia:Paris_Hilton") than provide a Facet to the user over such possible nnnnnnnnmatches;
> 
> As far as we understand, first and second features will be handled by querying the Entityhub with the query keyword (Paris) i.e the first entity obtained from the Entityhub will help us to recognize its type and the other entities will be served as facet values of Paris facet.
> 
>>>>     3. Semantic Facets: if a user uses an instance of an ontology type (e.g. a Place, Person, Organization) in a query, that provide facets over semantic relations for such types (e.g. fiends for persons, products/services for Organizations, nearby Points-Of-Interests for Places, Participants for Events, …). To implement features like that we need components that provide query preprocessing capabilities based on data available in the Entityhub, Ontonet … . To me it seams that the contenthub/search/engines/ontologyresource component provides already some functionality related to this so this might be a good starting point.
> 
> Currently, we are trying to integrate an exploration mechanism like you said above. It is also based on DBPedia ontology.  OntologyResourceEngine can be used for this purpose for the user registered ontologies. Current implementation of this engine only computes closures by exploiting the hierarchy in the ontology. RDFPath Programs can also be an option at this point. With an RDF Path Program user may specify the relations to be used in the exploration process. But I think this means the user decides beforehand which fields should be presented to him as exploration fields. I think this is open to discussion.
> 
>> best
>> Rupert
>> 
> 
> Regards,
> Anil.