Motivation. Faceted search is a prominent search paradigm that became the standard in many Web applications including online shopping and real-estate portals, where users can progressively narrow down the search results by applying filters, called facets [9] which are organised in faceted interfaces. Faceted search has also been proposed in the Semantic Web context for exploring and querying RDF graphs and a number of RDFbased faceted search systems have been developed (see [3,7,4,5,2,6] for an overview). One of the main challenges that hampers usability of faceted search systems is information overload [9]: when the size of the faceted interface becomes comparable to the size of data over which the search is performed. The overload is already a challenge in the case of the classical faceted search and it becomes even stronger when faceted search is applied to RDF data. Indeed, observe that in both classical and RDF settings the search is over annotated entities, at the same time, in the latter case the number of annotations and possible values is typically much larger: any predicate occurring in an RDF data set can give a facet during a search, and any entity or value that it points to in the RDF data can become a value in this facet. At the same time, in the classical case the list of possible facets is typically predefined and controlled. Moreover, differently from the classical case, in the RDF settings entities are also interconnected. Thus, in an RDF driven faceted interface one has to nest facets in order to reflect this interconnections. In Figure 1, left, one can see a possible way to nest facets which is implemented in our SemFacet system. This not only raises a non-trivial problem of how to arrange nested facets within an interface in an intuitive and user oriented way, but also leads to an unavoidable overload of the interface with various paths of nested facets. Thus, faceted navigation over RDF requires from users to be experts in the structure of the underlying RDF graph in order to be able to find the required facet which can be deeply nested. In order to see why it might be hard to find a required nested facet, consider in Figure 2 an example RDF data. Assume that one is looking for a smartphone with the price within £500-£900 and the processor that is manufactured by a company with headquarters in Asia. One can see in Figure 2 that Samsung S8 is such a smartphone. At the same time, finding this smartphone via a faceted interface requires one to traverse the data via 4 nested facets (Figure 1, left). SemFacet System. In our RDF-based faceted search system SemFacet we propose to address the information overload by - ranking facets and their values and thus offering to users top-k most prominent facets and values; ? This work was supported by the Royal Society under a University Research Fellowship and the EPSRC under an IAA award and the projects DBOnto, MaSI3, ED3, and VADA.
Introduction phone keywords
phone
type SmartPhone Laptop
hasPart Processor producedBy ANY
withHQ ANY inCountry ANY inContinent ANY Asia
North America price 0 500 900 1.600
Galaxy S8 is a phone that of ers an exceptional experience for any user. The large screen is a real turning point in flagship phone design and should usher in the end of large bezels, and the camera and slick performance work bril iantly under the finger. ANY facet predicate facet values answer Search Task: Fin▪d smwahrotpsheopnreoscessor ▪ icsommapnaunfyactured by a ▪▪ a£wn5itd0h0wh-£eh9ao0ds0equparricteersisinwAithsiina type SmartPhone (8.270) ANY Laptop (5.850)
hasPart Processor (2.490) producedBy ANY (1.800)
withHQ SSAuaNnwYoDniego (63((580))) enter facet price max 0 500 900 1.600 Reachable facets aggregate facets
Galaxy S8 is built around the new Exynos 8895, featuring new custom CPU cores, new Mali GPU, and with the whole thing fabricated via a cut ing-edge 10nm process intended to maximize performance and power ef iciency. refocusing
refocussed answer
Search Task:
Sh▪ow mwehopsreocpersoscoersssoofrsmartphones
▪▪▪ iapwsnriotmdhvawihdneheuaorfsdasceqistumu£ar5aretx0de0rpbs-ry£iicn9ae0Ac0asomiamopnagny
inContinent
Asia (
Observe in Figure 1, right, the SemFacet interface where all these three features are incorporated. The facets and values are now ranked and only the top 10 of them are displayed. The users can choose whether to look for a maximal price of entities by activating aggregate functions within facets with numerical values. In the screenshot the user selected max and thus the system is searching for smartphones whose maximal price across providers is within the range £500–£900. Finally, the users can enter the name of a desired predicate instead of choosing a facet value in order to ask the system to find a shortcut (a reachable facet). In the screenshot the user entered inContinent instead of selecting SanDiego or Suwon.
Demo Overview. The goal of the demo is to show the attendees how our novel features, that is, ranking, aggregation, and shortcutting, make hard faceted search—over RDF datasets that are highly interconnected and with many data values—easier. In order to experience the impact of these features the attendees will be able to explore the demo dataset using two versions of our SemFacet systems: with and without the features. 2 SemFacet System We first give an overview of SemFacet with the focus on its novel components and then present technical details behind ranking, aggregation, and shortcuts.
System Overview. SemFacet is implemented in Java and available under an academic license [1]. In Figure 2 there is the architecture of SemFacet where the arrows denote the data flow between the systems’ components.
On the client side, SemFacet has an HTML 5 based GUI consisting of three main parts: a free text search box for keywords, a hierarchically organised faceted interface, and a scrollable panel containing snippet-shaped answers. User keywords are sent by the client to the server, evaluated and this gives the initial faceted interface. User selections in the faceted interface are compiled into a SPARQL query using the SPARQL query constructor and then sent to the server for evaluation. The snippet composer and facet composer receive information about facets and answers that should be displayed to the user and update the currently displayed interface and query answers. The system updates the faceted interface incrementally: only the parts of the interface that are affected by users’ actions are updated, which allows for a significantly faster response
800 900 290 270 price price price price phone :SamsungS8 hasPart :Exynos producedBy :Samsung withHQ :Suwon inCountry :S.Korea phone type type type
inContinent Smartphone Processor Company :Asia :NorthAmerica type type type inContinent :HP Elite X3 hasPart :Snapdragon producedBy :Qualcomm withHQ :SanDiego inCountry :USA
price 730 price price 280 300 type SmartPhone (8.270) PLaropcthoeapssPorart ((25..489500))
Composer
AgHgarengdaletiron SHhaonrtdcluetrs RHaannkdilnegr HRaanndgleer RDF Data, Rules Exycon8Proces or Galaxy S8 is built around the new Exynos 8 95, featuringnewcustomCPUcores,newMaliGPU,and withthewholethingfabricatedviaacuting-edge10nm proces intendedtomaximizeperformanceandpower eficiency.
Composer Client GSennieprpaetotr Server
Ranking facet values. Besides ranking of facets, it is important to rank facet values as well. We adopt the count-based ranking (see also [10]): facet values that lead to a larger number of results are ranked higher. Although the computation of counts is conceptually trivial, the main challenge is in their update. Indeed, the integers associated to each facet value in the interface must be updated every time the user interacts with the faceted interface without affecting the performance of the system. Additional challenges come from (i) graph structure of the data and (ii) interplay of conjunctive and disjunctive interpretation of facet values. In our experience, implementing the straightforward approach to updating counts leads to a significant increase of the user interface response time. To mitigate this problem, we adopted a multi-threading solution: each thread receives a set of facet values for which counts need to be updated and, additionally, the load among the threads is balanced. For instance, we avoid the situation when one thread is busy with updating counts for values with a high number of results only, while another gets away with updating counts for values with a low number of results. This approach led to a significant response time decrease.
Aggregation. Recall that every interface update performed by the user (i.e., refocusing,
selection of a facet or a facet value) results in formulating a corresponding SPARQL
query on the fly that is then issued to RDFox. Then the interface is updated (i.e., with
search results and available facets at this point) depending on the result of this query.
When aggregate facets are considered, it is possible to follow the same approach and
formulate aggregate SPARQL queries. However, we decided to do materialisation of
aggregate information at loading time instead since (
Reachability. SemFacet provides the shortcut functionality described in Section 1. In the user interface, SemFacet offers a search box within each facet that allows users to search for reachable facets. As the user has typed in a facet name F in the box, the system checks if such a facet is reachable from the current facet. For this we perform breadth-first search to find all reachable nodes with an outgoing property F and we store corresponding witnessing paths. These paths are important in constructing the corresponding SPARQL query for fetching possible facet values for F and for further facet navigation. For a faster response time, we predefine a parameter B and check facet reachability up to length B instead. In our example, in Figure 1 (right) the user can search for the inContinent facet, which in this case is reachable within 2 steps, and then select ‘Asia’, thus selecting processors produced by an asian company.