Keyword search is the method of choice for end users to access information on the current web. Several attempts have been made to provide keyword search access to resources described on the semantic web as well as existing web documents enriched with semantic annotations. We will refer to both these approaches as semantic search. The systems that provide some form of semantic search show great variation. Our aim is to give an overview of the different notions of semantic search. In particular we are interested in the role of explicit semantics in the search process.

Within this survey we define keyword search as the process in which a user can submit one or more search terms in free text, with optional control structures, and the system returns a set of result items, which can be organized in various ways. The systems are analyzed in four different stages of the search process, input, processing, feedback and the search results. For each stage we consider the functionality that the system provides and how this is made available through the graphical user interface.

We try to give a complete overview of the different notions of keyword search that have been applied to semantic web data. We believe that in pursuing this, it is not necessary to analyze all systems that support a form of semantic search. Instead it suffices to thoroughly analyze the best representative for a particular type of semantic search. In total we considered xx systems which are all listed in the system overview. A thorough analysis is performed on 15 applications. Additionally we included a couple of systems that do not support keyword search (yet), but for which there is some clear added value for adding this.

Prerequisites

Several applications support operations to create semantic web data to search on, such as, named entity extraction, annotation, crawling and indexing. This lays outside the scope of this survey.

Many applications allow the user to view a specific resource and its direct metadata values, a local view. Some also allow browsing the semantic graph by making the metadata values hyperlinks. This is an useful technique to explore the RDF graph (see also browsers such as tabulator and Disco). This functionality lays outside the scope of this survey. Unless additional features are presented in the local view we do not mention this functionality.

• Name and URL
• Purpose: intended use of the system.
  • Search engine
  • Information management
  • (Faceted) Browser
  • Portal: gives access to multiple collections from a single entry point
• Users: intended users of the system.
  • End users (by domain expertise)
  • developers
  • software agents
• Scope: data to which the system provides access.
  • web
  • semantic web
  • RDF data collections
  • ontologies
  • thesauri
  • other...
• Store/Index: techniques used for literal indexing and storage of semantic web data.
  • Store: sesame, jena, swi-prolog etc.
  • Index: Lucene, application specific etc.

Search Input

Functionality

• Search term: the input that can be given as a search argument.
  • Keyword(s)
  • URI(s)
• Structure: control operators that are supported in the search term.
  • boolean operators
  • special purpose operators
  • regular expressions
• Value selection: Input by direct selection of search terms.

interface

• Text entry in the GUI?
  • text entry box
  • facet (value list)
• Additional interface components.
  • target type selection
  • literal match type (prefix, substring)

Processing

Functionality

• Literal matching: comparison of the search term to the literal index.
  • Single keyword: prefix, substring
  • Interpretation of multiple keywords
• Retrieval: how are the search results determined
  • direct matching document/URI
  • query extension
  • graph search

Interface

• Presentation of processing information.
  • processing time
  • number of results
  • loading message

User Feedback

Functionality

• Type: kind of feedback that is supported.
  • disambiguation: clarify intended meaning
  • refinement: constrain/extend the current result set
  • exploration: find new (related) resources
• Source: on what is the feedback given.
  • search input
  • search results

Interface

• How does the system allow a user to provide feedback.
  • Select from discrete list of values
  • New or extended search in text-entry box

Search Results

Functionality

• Result Item: Nature of a single search result
  • resource (document, image, concept)
  • set of triples
• Organization:
  • ranking
  • clustering

interface

• What is included in the presentation of a single search result?
  • Resource (document,image etc.)
  • selected metadata
  • Fresnel
  • template

Semantic Search

What do we consider as semantic search. [This can also explain why certain systems are chosen and others are not. Why do we not consider SeRQL or SPARQL query language or natural language based interfaces. I am not sure yet. The underspecified input of keyword search has something to do with it. In NL the focus is on the interpretation of the expression. Once the interpretation is made it is clear how the database should be queried. To answer an underspecified query it is uncertain what and how much should be retrieved from the database. The SPARQL describe construct is a similar notion of vagueness. It is exactly the part that is underspecified in the SPARQL spec.]

I think we should focus on systems in which the goal is to find instances. The target group typically are end users. This excludes systems, such as swoogle, swangler and ontoSearch, where the target type is a sementic web document, an ontology or resources used in an ontology, a class or predicate. The target group for these systems are developers and knowledge engineers.

General remarks about analysis of systems

Choose focus on certain aspects. There could be much more semantics done in the background, integration, smushing, extraction etc. We only look at the semantics used in the actual search process.

General remarks about the use of semantics

1. use metadata to extend literal match.
2. disambiguation of input, refinement of input and complex query patterns.
3. complex paths to find related resources.

In the first there is some consensus. Properties to use are synonyms, sameAs, narrower. Can be done on the fly or the additional terms can be added to the index offline. This Increases the recall, simply because the number of available "meaningful" terms is increased. On how to do disambiguation there is also some agreement. rdf:type and the property between the value and the search result are typically used. Facets are very well suited for refinement and to construct complex (union/intersection) queries. The third is the most exciting one and here we see various solutions. Rules: Ontogator/MuseumFinland uses logical rules, Squiggle predefined paths, Tap Semantic search predefined properties for each class. User controlled: KIM complex search query form, /facet has cross relations. Graph search: e-Culture weighted graph algorithm.

Can we describe the need for complex paths? Which additional results can we find with this? We can make a link to relation search here. If the focus is not the item itself but the relation between two or more items the complex paths are itself search targets. \cite{Seth Work}.

I think we can distinguish two types of complex paths. The first serves for query extension in order to find more results. The second allows the system to suggest related concepts, which allows further exploration.

1. Complex path is introduced by modeling decisions. In other words the value could have been modeled as a direct value. The use of blank nodes introduces this complexity. Another example would be the complex annotation in the multimedia ontology. Dealing with this type of complex paths is not a semantic issue. If the system is aware of which complex paths to use or if some mapping exists at the data level the issue of relevance does apply. .. the value is now a direct value of the item.
2. Complex path in which the occurrence of one or more concepts is crucial to the relation between the items. In other words the relation exist by virtue of an additional concept. In this case the system has to decide which concepts and relations are relevant. Many factors play a role here.

Interpretation of the input in advance (SemSearch) or presentation techniques that allow refinement and browsing on and from the result set. In SemSearch it is also issue iii). that is problematic. This case the problem is approached from the other side. What are the possible combinations of search terms can according to the data.

Search Results

In the presentation of the results almost all applications use a hand configured template form. FRESNEL \cite{fresnel05} could easily be applied for this purpose. Most applications support some sort of local view on an individual search result. Often this also allows some form of browsing. This connects to browsers such as Tabulator and Disco. Ranking of results is an open issue, added value of semantics is not clear. Clustering is often applied, added value of semantics in the form of meaningful explanations of the clusters.

User feedback

Disambiguation, refinement and suggestion of related items

Related Work

A Categorization Scheme for Semantic Web Search Engine, 2006. Kyumars Sheykh Esmaili, Hassan Abolhassani. Ontology search engines (meta search, crawler based) and semantic search engines (context based, evolutionary, semantic association). The systems that they cover seems to be very complete. The categorization is straightforward. I guess this means we can leave such a categorization out of our paper and just refer to this one. More room to focus on the role of semantics.

Evaluation

Fields experimenting with semantic web tools in a virtual organization, 2003. Victor Iosif, Peter Mika et. al. How do we test SW tools? Design considerations for Semantic Web Field Experiments. Description of an experimental setup with SW applications QuizRDF (search), spectacle (browse) and traditional free text search of EnerSearch.