incubator-stanbol-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rupert Westenthaler <>
Subject Semantic Query Interface for the Contenthub (was Re: Updates to LMF/Stanbol integration)
Date Fri, 28 Oct 2011 09:11:14 GMT
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 "")
* 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



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 "";
>>>>     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.

View raw message