Linked Data [3] is not any particular standard, it is just a set of common practices and general rules using which we can contribute to the Web of Data that emerged recently to enrich the traditional Web of Documents. So, what are these rules? First of all, each real-world entity should be assigned a unique URL identifier; these identifiers should be dereferenceable by HTTP to obtain information about these entities; and, finally, these entity representations should be interlinked together to form a global Linked Data cloud.
Nevertheless, despite there are also other ways how to follow the mentioned Linked Data principles, the most promising is obviously the RDF standard [6]. It assumes data modelled as triples with three components: subject, predicate and object. These triples can also be viewed as graphs, where vertices correspond to subjects and objects, while labelled edges represent the triples themselves.
One of our ongoing research efforts should result into a proposal of a new querying system dealing with large amounts of distributed and dynamic RDF data -issues we previously identified as open problems of the existing approaches from the area of RDF triples storing, indexing and querying [11]. It is apparent that, having the knowledge about structural and other features of data we want to process, we are able to manage such data more efficiently.
In fact, this idea predetermines the aim of this paper -we propose a set of characteristics of RDF triples and provide experimental results over several selected datasets. These characteristics capture features of individual triple components, triples themselves and also structural features of RDF graphs, while performed experiments attempt to outline the nature of real-world RDF data.
Outline First of all, in Section 2 we explain the motivation for this paper. Section 3 provides basic theoretical background and definitions of proposed RDF characteristics, while Section 4 presents results of performed experiments. In Section 5 we shortly discuss the related work, and, finally, Section 6 concludes.
If we knew characteristics about data we want to process, we would have better chances to propose algorithms and data structures that could be more efficient with respect to our expectations. In other words, this idea justifies the aim of this paper. Having understood RDF triples we want to store, index and query, we can, hopefully, achieve better results. Moreover, we can also come across approaches that require sort of a configuration (e.g. Structure Index by Tran and Ladwig [12] or Summary Index by Harth et al. [5]). But how can we provide required parameters, if we do not know enough about data or queries?
Therefore, we have proposed several characteristics we find interesting to study. First of all, the majority of indexing approaches (e.g. Hexastore by Weiss et al. [13] or BitMat Index by Atre et al. [1]) proposes to store components of RDF triples and triples themselves separately (even using fairly different structures) in order to reduce space requirements. Knowledge of string features of these component values could support this practice.
The second group of characteristics worth of studying is related to query evaluation and, in particular, access patterns to individual triple components. In case of full-text querying, we usually do not care which particular triple component should match the queried value, but in case of structural querying like SPARQL [8], we need to have suitable indices allowing us to efficiently access particular components according to the prompted query. These indices can be built, for example, on nested lists (Hexastore [13]) or B + -trees (RDF-3X by Neumann and Weikum [7]).
Finally, we can even attempt to study more complex characteristics based on structure of RDF graphs. When using SPARQL with queries based on graph patterns, we often need to do operations similar to traditional joining in relational databases, only with the difference that we are working with RDF triples, i.e. graph data. This joining can be supported by appropriate indices as well. Like, for example, precomputed paths (RDF-3X [7]) or stars (Structure Index [12]).
It is apparent that this paper cannot encompass all possible features of RDF data that influence possibilities of their processing. So, as we will see in the following section, we have proposed at least several of them (those we treat as the most important ones with respect to our research intent) and attempted to compute them over particular selected real-world datasets.
Having described our motivation, we can move forward to the core part of this paper. First, we provide some essential definitions in order to describe basic knowledge and theoretical background we need to understand to correctly introduce characteristics of RDF triples and datasets we want to study.
RDF triples are composed from three components: a subject, a predicate and an object. Beside literal values, the main building block for components of these triples is based on URI (uniform resource identifier) references as they are expected by the RDF standard. However, we assume that these references are always automatically translated to full URIs.
Thus, we can introduce U as a domain of all possible URI values, i.e. identifiers of resources. Analogously, assume that B is a domain for blank nodes and L a domain for literals. We do not need to study the content of these domains, we only use them to restrain the allowed values of individual triple components.
Definition 1 (RDF Triple). We say that t = (s, p, o) is an RDF triple (or just a triple),
All values (we call them terms) from domains U, B and L are seen as ordinary strings. This allows us to get deeper insight into the internal structure of URIs, generally conforming to SchemeN ame : HierarchicalP art [ ? Query ] [ # F ragment ] scheme (we came across and studied only URLs, thus we could make this simplification). First of all, having any term x, length(x) denotes a length of x, i.e. number of symbols it is composed of. Now, we describe how to split URI terms into two parts. Assume that x ∈ U and p is a position of the last # symbol in x. Then we define pref ix(x) as a substring of x before p and suf f ix(x) as a substring after p. If there is no F ragment part, then we analogously use the last occurrence of / symbol from the hierarchical part instead. This approach should capture the way how URI terms are usually used and designed by creators of data documents and ontologies.
Sets of RDF triples are commonly modelled as RDF graphs.
Definition 2 (RDF Graph). Given a set of triples T , we define G = (V , T ) to be an RDF graph (or just a graph) as follows:
-V is a set of graph vertices, where
and -T as a set of directed graph edges corresponds to the underlying set of triples.
Although we use a term graph, RDF graphs are in fact directed multigraphs since there can be more edges between the same vertices. Next, given a vertex v ∈ V and an edge e = (s, p, o) ∈ T , we say that e is an ingoing edge to v if v = o, and that e is an outgoing edge from v if v = s.
According to the discussed motivation, we are now able to propose several characteristics that may be useful to know about RDF data we want to store, query or process in a different way.
The first group of proposed characteristics is connected with features of individual terms in triples. First of all, the majority of existing approaches for indexing and storing RDF data attempts to find methods of reducing the space required to store the triples. For this aim we can exploit an idea that terms often repeat, or at least their substrings may often repeat across triples in a dataset.
In other words, we can inspect lengths of particular terms, either with respect to their type (U, B and L domains), or altogether. Next, we can split terms according to our definition of their prefix and suffix parts, exploring one suitable way of finding shared substrings.
Triple Features Now, we focus on characteristics of triple components and their categorisation. Suppose that we have a set of triples T . Given a particular term x (regardless its type), we may be interested how many triples contain this term at a particular component (subject, predicate or object). In other words, given a suitable term x, we can define P rojection s=x (T ) = { t | t ∈ T , t = (s, p, o) and s = x } as a subject projection (or just S projection) corresponding to the set of all triples in T having the given fixed subject value equal to x. Analogously, we can define P rojection p=x (T ) and P rojection o=x (T ) as P projection and O projection respectively. If we model T as a graph, S and P projections correspond to sets of outgoing and ingoing edges respectively.
Moreover, there is no problem extending this idea to projections on two components concurrently. Therefore, we can define SP projection, PO projection and SO projection analogously. For example, P rojection s=x,p=y (T ) = { t | t ∈ T , t = (s, p, o), s = x and p = y } for two suitable terms x and y. In particular, the SP projection is directly connected with the issue of multivalue properties of RDF triples causing problems in relational databases.
Star Patterns Let G = (V , T ) be a graph and v ∈ V a vertex. We define a graph star to be a set of edges Next, we define sig(S v ) as a signature of star S v (regardless full, ingoing or outgoing) to be a set of all predicates involved in a given star; in other words,
Given a graph G, we can split its vertices V into disjoint sets according to star signatures. This means that two vertices v 1 , v 2 ∈ V belong to the same set, if sig(S v1 ) = sig(S v2 ). Since this classification is an equivalency relation over V , we can call these sets as star classes. Analogously, we could introduce ingoing/outgoing star classes considering only ingoing/outgoing edges respectively.
Star classes and their sizes can describe uniformity of graph vertices, thus, we can base additional characteristics on the notion of stars. Apparently, their idea is connected (and inspired) by Tran et al. [12] and their Structure Index.
Path Patterns Let G = (V , T ) be a graph for a set of triples T and v S , v T ∈ V two vertices. We say that a sequence of edges P v S ,v T = e 1 , ..., e n with length n ∈ N 0 is a directed path from the source vertex v S to the target vertex v T , if the following conditions hold:
in other words, vertices do not repeat.
Given a particular path P v S ,v T , we can define its signature as a sequence of predicates of its edges, i.e. sig(P v S ,v T ) = p 1 , ..., p n .
Directed paths can serve as another characteristic that is closely related to the process of evaluating queries based on SPARQL graphs patterns.
The following listing provides a simplified overview of all characteristics over RDF triples we have proposed in this paper:
-Term lengths -length of U and L terms viewed as strings.
-Term prefixes -length of prefixes and suffixes of U terms.
-Data triples -ratio of data and other triples in datasets.
-Triple projections -cardinality of S, P, O and SP, PO, SO projections.
-Star patterns -sizes of graph, ingoing and outgoing star classes.
-Path patterns -path occurrences according to their signatures.
In this section, we first describe publicly available datasets we have chosen for our experiments, then we provide their implementation basics and, finally, we present results over these datasets together with some general observations.
The selection of appropriate datasets is probably one of the most important issues of any experiments. The first option could be to download a representative sample of RDF triples from the entire Linked Data cloud. However, with respect to the planned usage of our querying framework, we have finally decided to perform the experiments over a few selected datasets only. They are from different sources, cover different thematic areas and they contain several millions of triples. Although we cannot omit DBPedia as one of the most important Linked Data sources, we selected also other interesting ones. In particular, datasets that are listed in the following summary, including their abbreviations we will use in the further text:
-ACM (ACM publications 3 ) -ACM proceedings dataset with author and publication information. -DBCS (Czech DBPedia 4 ) -information extracted from Czech Wikipedia infoboxes. This dataset contains less clean data, which is actually a common situation in sources that are automatically derived from non-structured data. -DBEN (English DBPedia 5 ) -information about persons (records like date and place of birth etc.) extracted from English and German Wikipedia, represented using the FOAF vocabulary. -GO (Gene Ontology 6 ) -one of the datasets of Bio2RDF project describing publicly available DNA sequences. -MDB (Movie Database 7 ) -database containing triples about actors, movies and their relationships.
We downloaded dumps of all the previously described dataset in one of these formats: RDF/XML 8 , n-triples 9 or Notation 3 10 . Then we parsed these dumps using scripts 11 implemented in Java and Python.
After necessary data cleaning (some datasets contained syntax errors), we stored all obtained triples into MySQL database using Percona Server 5.5 12 running on Debian operating system.
Since we wanted to achieve efficient computation of the proposed characteristics, we designed the database schema so as to be based on three tables: the first table contains all URI prefixes, the second one full URI values, and, finally, the third one contains triples themselves. However, instead of URI terms we stored references to the second table and instead of literals it contains their MD5 hashed values together with original lengths. The simplified schema is shown in Figure 1.
The majority of proposed characteristics was computed using MySQL scripts 13 . The description of the most interesting observations together with detailed experiment results is the subject of the following text.
General Characteristics Firstly, we present the basic characteristics of the data, the number of unique prefixes, URIs and triples. These results show the diversity of triples within particular datasets (see Table 1). We can see that there are only 11 unique prefixes in ACM dataset, whereas there are 10,157 prefixes in DBCS dataset. These numbers suggest that ACM dataset is relatively closed (it contains mainly entities within its own domain -publications and their authors), while DBCS contains many dirty triples, i.e. triples where the object component is recognised as a URI but it is not a part of DBPedia (and probably neither a part of the Linked Data cloud).
The results also show the average lengths of URIs. Although there are no extreme values, we can see that ACM dataset differs. This is because the URIs (in 13 http://ksi.mff.cuni.cz/˜starka/ld mysql.zip all datasets) often contain artificial and often automatically generated identifiers combined with entity types and/or human readable names.
The detailed distribution of both URI and literal term lengths with respect to selected datasets can be seen in Figure 2. Since each dataset has a different total number of triples, we normalised the computed lengths by the total number of terms in each dataset. As we can see, all datasets except ACM use around 40 characters long. This is because identifiers in ACM dataset are padded by numeric values which causes these URIs are of the same length. On the other hand, the lengths of literals mostly range from 1 to 20 characters. This is caused by the usage of common values, i.e. person names, dates, numbers, etc. Only ACM dataset contains textual literals, in particular, keywords and concatenated lists of authors.
Triple Projections Assume that T represents a particular dataset, Θ is a comparison operator over N (e.g. = or >) and c ∈ {s, p, o} stands for particular triple component. Then we can define size Θz,c = |{ x : |P rojection c=x | Θ z }| as a shortcut for the number of terms x whose projections P rojection c=x according to a particular component c have exactly z triples in case of =, more than z triples in case of > (and analogously for the other comparison operators).
We can also define size Θz,c1,c2 = |{ (x 1 , x 2 ) : |P rojection c1=x1,c2=x2 | Θ z }| for double projections with both c 1 , c 2 ∈ {s, p, o} and c 1 = c 2 as expected.
These two notions help us to present interesting features of the triple projection characteristics. In other words, we study the distribution of terms (or pairs of terms in case of double projections) according to their significance inside given datasets. For example, having the condition Θz equal to = 1 and inspecting the object components, we are interested in terms x such that there exists right one triple in T with x at component o. Then, size =1,o gives us the number of such x in T . Several projection results are presented in Table 2.
The results show, that there are usually only few unique predicates which are used in the triples. In DBCS, there are over 270 triples for each predicate, which is the lowest ratio between all datasets. In other datasets, there are thousands of triples per predicate. For subjects, the average number varies from 2 to 20. In the second and third part of the table, we show projections for O and SP, PO, SO respectively. In each case we split the entire space into two disjoint parts: classes with size equal to 1 and classes with greater size. It is interesting that in most cases the projections usually have right one triple. We can also say that a typical dataset contains only a very limited number of predicates. Subjects are used mostly more than once, but they do not form large hubs.
Star Patterns Assume that T are triples of a particular dataset, then we can split vertices V of the corresponding graph G = (V , T ) into star classes according to signatures of their star patterns, as we already know. Figure 3 depicts the distribution of star classes according to their sizes, separately for ingoing and outgoing stars. In other words, e.g. for ingoing star patterns, the horizontal axis represents different possible sizes of signatures (different numbers of predicates on ingoing edges) and the vertical axis represents the overall number of ingoing star classes having the given size.
The values are normalised in the same way as in the term length characteristic, i.e. normalised by the total number of distinct star signatures in the particular dataset. We can see that most of the unique outgoing stars have the size (i.e. number of outgoing predicates) from 10 to 30. Similarly, most of the ingoing stars have the size from 10 to 30, only except ACM dataset where sizes are distributed uniformly. Moreover, for all datasets except DBCS, the first 10% of star signatures covers more than 80% of triples.
Path Patterns Similarly to star patterns, we computed also the path pattern characteristics. In particular, we considered paths of lengths equal to 2 and 3, since longer paths were out of our computation possibilities. For each path length we detected the number of unique path signatures and the overall number of all paths conforming to them, as we can see in Table 3.
Moreover, we also studied another aspect -having a particular number of the most frequent path signatures, how many paths do these signatures conform to? The number of paths with the most frequent signature is presented in the mentioned table, while the entire dependency is depicted in Figure 4. Finally, according to computed results, the ratio between unique path signatures and all paths themselves is relatively low. In other words, having a particular frequent signature, there are many paths conforming to it, which can be exploited in indexing techniques dealing with precomputed paths. Although there exist several works about analyses of semantic documents and Linked Data, there are still open questions that could be discussed.
We start this overview of the related work with one of our previous papers [10], where we proposed a system for automatic document acquisition and analysis. Although we primarily focused on structural characteristics of XML documents, some basic ideas and insight into the complexity of exported datasets can be applied also in the context of Linked Data. Ding et al. [4] described the analysis of more than 1.5 million FOAF documents. In particular, they inspected the usage of the FOAF namespace, host names and particular properties, as well as the relationships of a person in a group and other components of a social network. In general, this work describes several interesting characteristics, but its impact and context is very restrained.
Both the previous works assumed analyses at the document level, whereas Rodriguez [9] looked at datasets from the Linked Data cloud in a more complex way and computed some basic characteristics between them.
The general statistics of the Linked Data cloud are described in Bizer et al. [2]. The authors aimed at characteristics and link statistics between selected datasets. These datasets were divided by different thematic domains, for which several ingoing and outgoing statistics were computed. Provenance, licensing and dataset-level metadata published together with these datasets were also considered.
In this paper we focused on several characteristics of publicly available Linked Data datasets. The results show that although the datasets are from different areas, published by different methods and institutions, some of their characteristics are similar and, thus, the knowledge of these characteristics can be harnessed to make the management of RDF data more efficient.
We considered only a small sample of the Linked Data cloud as well as only a limited set of proposed characteristics dealing primarily with RDF triple components and structure only. On the other hand, we hope that despite this fact some observations presented in this paper can be generalised, further extended and appropriately exploited. In our future work, we plan to enrich these characteristics and also encompass a wider set of datasets and triples themselves.
This work was supported by the Charles University Grant Agency grant 4105/2011, the Czech Science Foundation grant P202/10/0573 and the EU ICT FP7 project 257943 (LOD2 Project).