In order to pose queries on SPARQL endpoints, users need to understand the underlying structure of the data that is stored. Unfortunately, and despite the importance of endpoints in the Semantic Web infrastructure, in most (if not all) publicly available endpoints the only way of understanding this structure is by performing a considerable number of probe queries, perhaps inspired in a few examples that are also made available. This paper looks into the problem of providing additional information for SPARQL-fluent users that need to query a RDF dataset they are not familiar with. We set up to understand what is the essential information that a user needs to query a SPARQL dataset, and then propose a visualisation that can effectively help users learn this information. This visualisation consists of a labelled graph whose nodes are the different types of entities in the RDF dataset, and where two types are related if entities of these types appear related in the RDF dataset. We illustrate our visualisation using the Linked Movie Database dataset.
SPARQL Endpoints are one of the key elements in the current Semantic Web
infrastructure. The idea of these endpoints is to allow users to extract
information from a remote RDF dataset; the dataset is made available to be queried
over the HTTP protocol, and the information must be obtained using SPARQL
queries, according to the latest SPARQL specification [
From an algorithmic point of view, the problem of querying endpoints (or
at least a single endpoint) has been very well studied, and nowadays there is a
considerable number of working endpoints that permit querying databases from
numerous different domains. See [
Unfortunately, this is a pretty strong assumption: even if the endpoint is
up and running, and even if the user is an expert in SPARQL, the task of
producing a query that extracts the desired information may end up demanding
more resources than those needed to actually compute the query. The problem is
the unstructured nature of RDF: as there is no real notion of schema, knowing
what and how the RDF data is stored is not an easy task. In contrast with
relational databases, where users can directly consult the schema information for
the names and attributes of tables, with RDF data one has almost no alternative
but to understand the data by issuing several probe queries. This behaviour has
been confirmed when analysing query logs of different endpoints [
As an example of the challenges we face, consider and endpoint for Linked
Movie Database (LinkedMDB [
Q: Return the names of all directors that have also acted in one of their movies.
The landing page of our LinkedMDB endpoint of choice would probably not provide any information on the structure of the data residing in the endpoint. Furthermore, the only guidelines for constructing the appropriate SPARQL query would be a small number of general examples that may not even mention the entities we are looking for. In particular, for our query Q above we would need the following information.
– First, how are directors stored in the database? In RDF one typically identifies resources with types, so one would expect that a pattern of the form {?x a linkedmdb:director} would match precisely all directors in our database. However, to be able to produce such a query we need to obtain the precise IRI used in the dataset to indicate the director type, in this case http://data.linkedmdb.org/resource/movie/director. – Next, how is the connection between actors, directors and movies stored? Assuming we already know how to identify actors, directors and movie resources with SPARQL, we still need information about the way these are linked together. In the case of LinkedMDB, directors are connected to entities of type film via the same predicate http://data.linkedmdb.org/resource/movie/director, and similarily for actors and films. – How to understand when a director and an actor are the same person? There could be several possibilities. For example, there could be a linking triple {A owl:sameAs D} between an actor resource A and a director resource D. But in LinkedMDB this is not stored directly, so we need to query for actors A and directors D that have the same name. Thus, we also need to understand the way in which the names of actors and directors are stored in the database. Furthermore, there is no way of knowing that an owl:sameAs link will not work without an explicit SPARLQ query that looks for the existence of triples of this form.
We argue that users new to RDF datasets would benefit tremendously from
a graphical interface that would explicitly give them the information they need
to start producing meaningful SPARQL patterns. We want a quick and easy
lightweight solution, that can be added onto endpoints without much
computational overload. This issue has been recognised before, in e.g., [
But how can one identify which of these visualisations has the necessary ingredients to be a good aide for querying endpoints? We try to answer this question by proposing 3 basic requirements that must be fulfilled by any system or visualisation if they aim to be a reasonable help for users posing SPARQL queries. Then, as a proof of concept, we present one visualisation that does fulfil all of our requirements, and explain the different choices made when creating this interface. Thorough the paper we assume familiarity with RDF, SPARQL, and the basics of SPARQL endpoint architecture. 2
In RDF databases the term schema is used in two completely different contexts.
First there is the notion of RDF schema [
But in relational databases, a relational schema not only defines the structure of the data, but also gives us guidelines on how to query the data: the names of the relations, which attributes are associated to each relation, the domains of each of those attributes, etc. RDF schema, being stored in RDF itself, does not automatically provide this information, and thus this second notion of schema is not immediately present when dealing with RDF, and has to be obtained by other means.
Thus the natural question: what kind of meta-information is actually needed to write SPARQL queries? Think of the information that a SPARQL expert would need in order to produce a query that fulfils the task at hand, when confronted with a new RDF dataset she doesn’t know. This information can be represented in several ways, so we do not discuss how this information should look like, but rather specify what should be expected from it. To this extent, we propose three requirements that any aide for querying SPARQL must have.
R1: The user should be able to identify all different types of resources in the database, and search for the types she is interested on.
This is the most basic requirement one could think of: if we need to query a
certain type of entity (such as actors, directors, or films), we need to know how
each of these entities is stored in the database, and how to recognise them by
means of patterns. Usually one specifies the types of an entity e with triples of
the form {e rdf:type <type>}, but we we refer to type in an abstract way; if
RDF schema types are not present then there are other options to classify the
resources in a database, such as discovering them as in [
The main challenge behind this requirement is that the amount of different types in a database may be so big that simply showing a list of types is useless (for example DBpedia, as reported in http://wiki.dbpedia.org, has more than a hundred thousand different types). Thus, a way of navigating this information has to be present or included in the interface, so that the user can look for the types she needs without being confronted to a list with thousands of entries.
R2: When given a pair of types, the user should be able to identify how and when are two entities of these types connected to each other.
Even if we can identify entities of a given type, we still need to know how they link with each other. Thus, any meta-information that deems to be useful towards query formulation needs to be able to produce, for each pair of types A and B, all relations that span between an entity of type A and an entity of type B (and vice-versa). For some types we always know that all entities of the given types are connected to each other (like actors and films in LinkedMDB). But sometimes there might only be a few connections between entities of two given types. Thus, we also need a way of specifying how likely is that two entities are connected to each other.
R3: For each type, the user should be able to identify which attributes are common to entities of this type, and how common is this attribute amongst all entities of the given type.
To put common terms between RDF and the relational models, we define the attributes of an entity e as all the properties p present in triples of the form {e p l}, where l is a literal. Attributes give us specific information of entities: if we want to know the name of an actor a, then it is probably stored in a triple of the form {a actor name <name>}, and likewise for any other name or numerical attribute associated to e. Again, while some attributes may be common for all entities of a given type (such as the titles of films in LinkedMDB), in other case these attributes may appear only in a subset of the entities (such as the duration of films, as less than a fifth of the films in LinkedMDB has this information).
We also note that there is a scalability issue which is orthogonal to all of these requirements: small datasets are of course easier to understand, but bigger datasets (in terms of different types and relationships) are harder, and thus the visualisation must work regardless of the size of the dataset. For this reason, it is almost impossible to develop a static visualisation that satisfies these requirements. On the contrary, we believe that the best option is an interactive page when users can be clearly guided so that they see the details only in the information that they are looking for. We describe our approach at building such a system in the following section. 3
Our approach is to compute, in advance, a graph that contains all the information mandated by requirements R1, R2 and R3, so that users can see this information when attempting to query the endpoint. As we have mentioned, our visualisation is not static, but instead allow the users to select the level of granularity they wish to see in this graph. We start in section 3.1 with a high-level description of our system, and then proceed, in section 3.2, to specify the more specific choices that were taken when designing our visualisation. As a running example we use LinkedMDB’s dataset, but of course the ideas are independent of any particular dataset used3. Our visualisation of LinkedMDB is available at http://jreutter.sitios.ing.uc.cl/VisualRDF.html. 3.1
Our main visualisation is a labelled, undirected graph, where the nodes are the types of the dataset, and where there is a p-labeled edge between nodes t1 and t2 if and only if there are entities u1 and u2 such that u1 is of type t1, u2 is of type t2 and the dataset contains the triple {u1 p u2}. That is, two types are related to each other is there are entities of these types that are connected by a triple in the dataset.
However, showing just this graph is probably not enough for users. In a
similar research related to the exploration of social networks, Viegas et al. [
In what follows we give a brief description of our visualisation, while discussing the satisfaction of requirements R1, R2 and R3 given in the previous section. Further details ara available in the following subsection. Hierarchical navigation of types. In most RDF graphs the type assignment is hierarchical. Entities can be of different types, but there is usually a hierarchy between them: there can be two types, A and B that are subclass of a higher type C. In turn, C itself can be a subclass of a type D, and so on. We take advantage of the forest-like shape of the RDF type hierarchy4 and include in our visualisation the ability to slice the type graph in different levels of this hierarchy. Coming back to our example, Figure 2(a) describes the same visualization of LinkedMDB as in Figure 1, but where some nodes are hidden and the emphasis is on the Person node. In LinkedMDB there are several types which are a subclass 3 We do note that computing the necessary files for our visualisation may take several minutes, or even hours, so it is not possible to offer on-demand visualisations. 4 Note this is not necessarily the case with more powerful ontologies in the OWL profile, this is in fact an interesting direction for future work. of Person, and users interested in one of them can drill down on this node, subdividing Person into each of its subclasses, as shown in Figure 2(b).
Together with the left panel, we believe this interactive visualisation fully satisfies requirement R1: all types are present in the graph, but we prevent an overload of information by showing only the top-level types first, allowing the user to produce more fined-grained views on demand.
Navigation and summarisation of relations. It is not strange to find different relations amongst entities of the same type in an RDF dataset. For example, there are several relations between persons and films in LinkedMDB. As we did with nodes, we aggregate all relationships into a single set, and only show the more fine-grained relationships whenever they are requested by the user, by hoovering over the relation. This again prevents information overload, and allows users to visualise only those relations that are interesting, thus satisfying requirement R2. Figure 3 shows an example of a relation that is in fact an aggregation of several different properties, shown in the right-side panel. Summarisation of attributes. Recall that an attribute of a an entity u is a property that relates u with a certain string or value. For example, in Linked MBD, entities of type performance have attributes such as performance actor, performance character, etc., according to Figure 1. As we have specified in requirement R3, attributes are vital to users when asking questions meant to retrieve literal values, such as What is the name of...? or In which year did...?. However, due to the unstructured nature of RDF data, it is presumable that there will be several attributes that could potentially be associated to each type, and possibly not all entities of the same type have the same attributes. More
(a) Graph with Person node (b) Result of dividing the Person node over, it is impossible to show each of the types attributes in the same graph at the same time. For this reason we construct our visualisation so that, when users hover over or select a particular node in the graph, the right-side panel displays all the information about the attributes of entities of this type. Additionally, we also show the percentage of entities of the chosen type that posses this attribute. 3.2
Finally, we shed light on the specific choices and details of our visualisation. Architecture: The input to the visualisation is a JSON file that needs to be pre-computed from the dataset wanted to be visualised. This JSON contains the information of all types present in the dataset, as well as the relationships between them. The visualisation is separated into a back end, in charge of retrieving the appropriate data from the JSON file, and a front end built with D3 that displays only the nodes and relations pertinent to the current state of the interaction. This separation allows the server to handle the bigger document with all the pre-processed types, and whereas the computational power of producing the visualisation is shifted to the front end, with the double advantage of reducing the amount of computational resources demanded from the server, and hasting the response time of simple operations in the visualisation. Panes: The visualisation is divided in three panels. The central and main panel is our connection graph. The left-side panel is available on demand, and it shows a box with the 10 most important entities in the current graph. The left-side panel is connected to the graph, so that a selection of one of the entities in the box it is reflected as if it was selected on the graph. For example, in Figure 1, the user is selecting the node performance in the left side box, which appears highlighted in the graph. The right-side panel is where the details of the nodes are shown. There are two different visualisations. When a node is selected, the box shows the URI and name of the corresponding type, and all properties that connect at least one entity of this type with a literal (names are assigned automatically from URIs). In turn, for each property we show how many entities of the selected type have this connection, the minimum number of such connections in an entity of this type, and the maximum number of such connections. For example, looking at the first line after Properties in the right-side box in Figure 1, we see that the 100% of entities of type performance have a connection of the form {e performance actor <string>}. Finally, if the type has any subclasses, then the right-side panel also shows all of these subtypes. This can be seen in Figure 2(a), when the Person node is selected. Next, when a relation is selected, the right-side box shows all the different relations that connect entities of this type, as well as the total number of such connections, their URI, and their direction. For example, Figure 3 highlights all connection between entities of type film and type Person. The right-side box in this case shows, for example, that there are 1955 triples of the form {e1 cinematographer e2} where e1 is of type film and e2 is of type Person.
Color: The graph uses essentially two colours: we use red for nodes and relationships that can be navigated (or split) in several subtypes or that contain different relations, and blue for the ordinary nodes and relations. Coming back to LinkedMDB, we see that the node Person is shown in red, because one can divide it (into actor, cinematographer, etc). On the other hand, nodes such as film are instead shown in blue, because film has no subclasses. The system highlights nodes and/or relationships by applying a more vivid version of the same colour. Furthermore, the name of the node or relationship is always shown when nodes are highlighted.
User interaction: Apart from displaying the left-side panel and highlighting nodes or relationships, by right-clicking the objects a user can interact with the visualisation in the following ways: First, one can hide a particular node and all the edges that connect this particular node. But also one can hide everything that is not related to a given node (keeping only those nodes connected to the selected node), or show all nodes that are related to a given node (in case they where previously hidden). Finally, there is the subdivide operation: Any red node can be subdivided into their immediate subclasses. When this operation is performed the red node dissapears, and for each subtype of the red node we create the corresponding node with their relations. In our LinkedMDB example, Figures 2(a) and 2(b) show the outcome of dividing the Person node, creating nodes actor, director, editor, cinematographer and film crewmember. Size and positioning of objects: In both nodes and edges, the total area is proportional to the number of entities (respectively, triples) of a given type (relationship). The positioning is also relative to the area, so that the bigger the nodes the farther away they appear. This is done to avoid visual stress by clogging two big nodes together. We take advantage of a number of D3 libraries to produce a graph that can be dragged and repositioned at will. Together with the ability to hide nodes, this facilitates the exploration and analysis of the graph. Figures 4(a) and Figure 4(b) provide an example of this power: The second graph is built from the first by simply hiding a few unimportant nodes and repositioning the important ones. 3.3
The system closest to our ideas is LODSight [
More on the profiling side one can highlight ExpLOD [
There is still much to do in terms of understanding the best way to facilitate SPARQL query answering, and it would be interesting to continue demonstrating the appropriateness of our requirements. There are two main directions that one could take. First, it is important to analyse previous work on visual information about RDF datasets from the lenses of our requirements: what do they satisfy, what don’t they satisfy, and how does this reflects at the time of producing SPARQL queries. In this respect, it would also be useful to understand whether a graph visualisation such as ours is the best one can do in order to fulfil these requirements, or whether one should look for other paradigms. The other direction is to demonstrate, via an empirical experiment, the usefulness of our particular visualisation. A possible way of doing this experiment would be to divide a group of SPARQL experts not familiar with a particular dataset, and assign the same set of tasks to both groups, but where only one group is allowed to use our visualisation while the other is not. The feedback from this experiment could then be used to improve our visualisation. We believe this is an interesting line of work and, to our best knowledge, one that is almost unexplored. Acknowledgements. Work funded by the Millennium Nucleus Center for Semantic Web Research under Grant NC120004. The author Denis Parra was funded by Chilean research agency Conicyt, Fondecyt grant number 11150783.