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.
