The faceted search paradigm is widely used in web applications, and there are various tools available for implementing it on the server side. In contrast, this paper presents an HTML based component tool on the client side that can be plugged on virtually any public SPARQL endpoint on the web, using only SPARQL API for data retrieval. To test and demonstrate the idea and the tool, application of the tool in a large in-use semantic portal is presented.
Faceted search [
Faceted search can be implemented with popular server-side solutions, such as Solr1, Sphinx2, and ElasticSearch3. However there is a lack of light-weight client-side faceted search tools or components that search data directly from a SPARQL endpoint. Such a tool would be very useful, because it could be used on virtually any open SPARQL endpoint on the web without any need for server side programming and access rights. This paper presents a web component for implementing faceted search applications in a browser, based only on a standard SPARQL API.
Design Requirements The requirements for our tool, SPARQL Faceter, are
based on our earlier experience on tediously implementing server side faceted
search over and over again in di erent applications, as well as on the generic
requirements of the search paradigm [
In short, the goal was to create a tool that would be easy to use out-ofthe-box, and require minimal con guration, yet provide enough con guration options to be useful in di erent contexts.
Design AngularJS5 was chosen as the implementation framework for our tool. SPARQL Faceter is developed as open source with source code available on GitHub.
SPARQL Faceter consists of two distinct components. One is the main Semantic Faceted Search component6, which contains the basic functionalities of
the tool, and is dependent on the second component: an AngularJS service for querying SPARQL endpoints with paging and object mapping7.
The Semantic Faceted Search component is comprised of di erent services, and most importantly, the facet selector directive. This directive is the main component of the tool, and provides the user interface for using the faceted search.
The facet selector directive is independent of any results the facet selections might imply: it's role is to keep track of what values are selected in what facets, and to display available selections to the user including the number of results each selection implies. The tool communicates the facet selections to whatever application is using it by calling a callback function whenever the selections change. Thus, SPARQL Faceter places no restrictions on what can be done with the user's selections. The tool does, however, provide services for integrating the facet selections to SPARQL queries, handling SPARQL results, and updating the URL based on current selections.
The Semantic Faceted Search component works by building a single SPARQL query for the facets it controls, and updating the query each time the user makes a selection. This has the advantage of keeping the states of the facets synchronized at all times. The downside is that with very many facets querying can become slow, and the user experience may su er as the facets are unusable while their states are being queried. In order to make it feasible to have many facets available, facets can be enabled and disabled: only enabled facets are included in the query. Whether or not a facet is initially enabled is con gurable. The tool shows a spinner on the components when querying for data, to convey to the user that the information in the elements is being updated.
For enabled facets, the tool shows all possible values for the facets' property, and the amount of instances that the selection results in. The amount of results is calculated based on all the current selections in all of the facets. Values that would lead to no results are omitted. In addition to the list of possible values, there is also a text input for searching the facet values.
The tool also supports hierarchical facets, in which selecting a category upper in the hierarchy also shows results for all the categories that are below it in the hierarchy. The hierarchy speci cation is not limited to using a prede ned property or vocabulary, but is based on con guring a property path that captures the hierarchy, and giving the top categories explicitly. The facet element displays a two-level hierarchy of the categories. For categories below the current category level, the hierarchy is attened and all the sub categories are listed below the upper category. The category level is initially on the topmost categories, and selecting a value changes category level to the level of the selected value.
The proposed way to use the facet selections, as returned by the tool, is to build another SPARQL query for retrieving the results according to the user's selections. By using the tool's services, the results can then be mapped into JavaScript objects with pagination and client-side caching of the received results. 7 https://github.com/SemanticComputing/angular-paging-sparql-service Installation and Con guration At its simplest, the only con guration options needed by SPARQL Faceter are the URL of a SPARQL endpoint, a callback function to be called with the facet selections when they change, the RDF class URI of the resources which are the target of the search, and the facet con gurations. A basic facet can be con gured with just the URI of the property and a name for the facet to be displayed to the user. The callback function de nes what happens when the facet selections are updated, which typically is to update a results display according to user selections.
Other types of facets require some additional con guration options, but the amount of con guration needed for any facet type has been kept to a minimum. The other facet types include a keyword search facet, a time-span facet, and a hierarchical facet. More details about the con guration is given in the repository of the Semantic Faceted Search component.
As for the results, the user of the tool is expected to build a query for retrieving results based on the facet selections. This makes the tool extremely exible to di erent data models, but requires that the user of the tool is familiar with SPARQL syntax. 3
We tested and evaluated SPARQL Faceter on the WarSampo portal [
Fig. 1 shows a screenshot of the faceted search of death records using SPARQL Faceter. The application interface contains 12 facets and a table-like view of the results. The facets include a keyword search facet for the persons' names, a timespan facet for the time of death and a hierarchical military rank facet, and 9 basic facets of the annotated properties of the death records. The source code of the application is available online11.
A dataset this large provides a benchmark for the performance of the SPARQL Faceter, as SPARQL queries and also data handling on the client-side could take long enough to deteriorate the user experience. Quite much e ort had to be put on optimizing the SPARQL queries for speed, while also making sure that no
unnecessary processing of the results happens on the client-side. Normally when searching and browsing the dataset, results are displayed in a few seconds after the user makes a selection. With some selections that result in a large result set, and if additionally many facets are enabled, the user may have to wait more than ten seconds to see the results and updated facets. Most of the time goes to waiting for results from the SPARQL endpoint.
Use case 2: Photographs Perspective The WarSampo photographs perspective12 uses the application to create a faceted search interface for wartime photographs. The dataset consists of about 159,000 photographs and a total of about 1.6 million triples. The interface contains only 5 facets, which ensures fast response times. The facets include a time-span facet for the date the photograph was taken, a keyword search for descriptions, and basic facets for related people and places. Fig. 2 shows a screenshot of the photograph perspective.
The perspective uses \in nite scrolling" to display the photographs: more results are retrieved as the user scrolls down for more photographs. Clicking on a photograph shows the user more information about the photograph, and provides hyperlinks to other WarSampo perspectives via linked entities. 4
In this paper we have presented the SPARQL Faceter for creating client-side faceted search applications. The con guration of the facets has been kept as 12 http://www.sotasampo. /en/photographs/ simple as possible. SPARQL Faceter handles querying the SPARQL endpoint when needed, mapping the SPARQL results to JavaScript objects, and creating and updating the facet elements. To make use of the facet selection values, the developer using the tool has to retrieve results based on selected values, which usually includes writing SPARQL queries.
Results Section 2 presented the design requirements for a Semantic Web tool that provides client-side faceted search of RDF datasets published as SPARQL services. Here is a detailed view of how the SPARQL Faceter manages to satisfy these requirements: 1. Data read from a SPARQL endpoint. All data is retrieved via SPARQL, from an endpoint de ned by the user. 2. Easily adaptable to di erent datasets. Con guration of the tool is required for every dataset. The con guration required for setting up facets is kept to a minimum. 3. Easy integration to web pages. A faceted search can be easily added to a web page by using the developed AngularJS components. The facet selections have a default look that can be customized using CSS. 4. Fluent user experience. For datasets that are distinctly smaller than the ones used in the use cases, the tool is almost certainly fast enough for good user experience. For the faceted search applications in the use cases, some user selections can be slow, but common usage gives results based on user selections in a few seconds. For larger datasets, the amount of facets may have to be restricted, depending on the processing capabilities of the SPARQL server. 5. Support for hierarchical facets. Two-level hierarchical facets are supported by the tool, and demonstrated in the rst use case. The dataset can contain more than two levels, but the hierarchical facet attens the hierarchy to two levels for display in the select element. 6. Easy to maintain. The separation of concerns design principle is used in development to simplify code structure and maintenance. Automated tests are used to help maintain good code quality.
Our application is able to satisfy the given requirements, and thus provides a usable tool for faceted search of RDF datasets.
Related Work Jassa [
Sparklis [
Oren et al. [
Acknowledgements Kasper Apajalahti and Jouni Tuominen contributed to an earlier version of our tool. This work was supported by the Linked Open Data Science project14 funded by the Ministry of Education and Culture in Finland. 13 http://www.irisa.fr/LIS/ferre/sparklis/ 14 http:/seco.cs.aalto. /projects/lodsci/