VoID (Vocabulary of Interlinked Datasets) has been proposed by W3C as the vocabulary for expressing metadata about RDF datasets. Despite its important contributions, VoID cannot express metadata that concern the connectivity of semantic warehouses. We use the term semantic warehouse to refer to a read-only set of RDF triples fetched (and transformed) from different sources that aims at serving a particular set of query requirements. Connectivity metrics are important for evaluating the value of a semantic warehouse, since they reflect its query capabilities. Moreover they also quantify the contribution of each constituent source to the warehouse. To allow the representation, exchange, and querying of such measurements, in this paper we describe an extension of VoID that allows representing them. We demonstrate its applicability through the case of a real and operational semantic warehouse for the marine domain.
An increasing number of datasets is already available as Linked Data. For exploiting this wealth of data, and building domain specific applications, in many cases there is a need for fetching and assembling pieces of information coming from more than one sources (including SPARQL endpoints). Then, these pieces can be used for constructing a warehouse, for offering more complete browsing and query services (in comparison to those offered by the underlying sources).
We shall use the term Semantic Warehouse (for short warehouse) to refer to
a read-only set of RDF triples fetched (and transformed) from different sources
that aims at serving a particular set of query requirements. There are
various such warehouses (e.g. [
W3C proposed VoID (Vocabulary of Interlinked Datasets), a vocabulary for
describing open and linked datasets [
In a nutshell, the key contributions of our work are: (a) we motivate (through
a concrete scenario) why VoID should be extended, (b) we propose an extension
of VoID that models all metrics proposed in [
The rest of this paper is organised as follows: Section 2 describes the required background, i.e. the VoID vocabulary and the connectivity metrics. Section 3 describes the proposed extension of VoID and describes its applicability through the case of a real and operational Semantic Warehouse for the marine domain. Finally, Section 4 concludes the paper. 2
Here we describe in brief VoiD (in §2.1), we synopsize the warehouse connectivity metrics (in §2.2), and discuss related works (in §2.3). 2.1
This section describes briefly the current version of VoID (Vocabulary of
Interlinked Datasets) [
Conceptually, it has been built around the notions of void:Dataset, void:Linkset and RDF Links. A void:Dataset is a set of RDF triples that are published, maintained or aggregated by a single provider. A void:Linkset is a collection of RDF Links between two datasets. An RDF Link is an RDF triple whose subject and object are described in different void:Dataset.
Based on Dublin Core [
Access metadata used to describe methods of accessing the RDF data using various protocols. They are: void:sparqlEndpoint, void:dataDump, void:rootResourse, void:uriLookupEndpoint, void:openSearchDescription.
Structural metadata providing high-level information about the schema and internal structure of a dataset and can be helpful when exploring and querying the dataset. They are: void:exampleResource, void:uriSpace, void:uriRegexPattern, void:vocabulary, void:subset, void:classPartition, void:propertyPartition, void:triples, void:entities, void:classes, void:properties, void:distinctSubjects, void:distinctObjects, void:documents.
tiple datasets are related and can be used together. They are: void:Linkset, void:target, void:linkPredicate and all patterns for describing datasets can equally be used for void:Linkset. 2.2
One method to check and quantify the connectivity of a semantic warehouse
is through the connectivity metrics proposed in [
In brief, the main metrics are: (a) the matrix of percentages of the common URIs and/or literals (it shows the percentage of common URIs/literals between every pair of sources), (b) the complementarity factor of the entities of interest (it is the number of sources that provided unique triples for each entity of interest), (c) the table with the increments in the average degree of each source (it measures the increment of the graph-theoretic degree of each entity when it becomes part of the warehouse graph), and (d) the unique triple contribution of each source (the number of triples provided by a source which are not provided by any other source). The values of (a),(b),(c) allow valuating the warehouse, while (c) and (d) mainly concern each particular source.
For reasons of self-containedness, here we summarize the definition of the metrics. Table 1 introduces the symbols that are required for defining the metrics. However, for computing the metrics several policies can be followed for deciding whether two URIs or two literals should be considered equivalent. The proposed policies for equivalence are shown in Table 2. Finally, Table 3 shows how each metric is defined. Symbol Meaning S = S1, . . . Sk the set of underlying sources. triples(Si) the set of triples that each source contributes to the warehouse. Ui the URIs that appear in triples(Si) Liti the literals that appear in triples(Si) W the triples in the warehouse E the entities of interest, in the form of a set of literals and/or URIs T a set of triples degT (e) = |{(s, p, o) ∈ T | s = e or o = e}|, i.e. the degree of an entity e in T degT (E) = avge∈E(degT (e)), i.e. the average degree of the entities E in T ui a URI last(ui) the string obtained by getting the substring after the last “/” or “#” of ui, turning the letters of the picked substring to lowercase and deleting the underscore letters that might exist. sameAs the sameAs relationship between two URIs according to the entity matching rules that are (or will be eventually) used for the warehouse.
The metrics are currently used by the tool MatWare [
Another metric, that was not proposed in [
Provenance. W3C has proposed the PROV Family of Documents6 which defines
a model, corresponding serializations and other supporting definitions to enable
the interoperable interchange of provenance information. In addition, the work
in [
Connectivity among Concepts / Fuzzy LinkSets. In [
Statistics. The RDF Data Cube Vocabulary7 [
In [
Difference of our approach. The main difference of our approach is that we focus on modeling metrics regarding the connectivity and the quality of a Semantic Warehouse, thus it can complement existing initiatives like VoID and it can be used together with approaches that focus on provenance, completeness, statistics, etc. These metrics reflect the query capabilities of a warehouse (so they are important for evaluating its value) and also quantify the contribution of the underlying sources, allowing evaluating the importance of each source for the warehouse at hand. 3
At first we discuss the requirements (in §3.1), then we describe the proposed conceptual model (in §3.2), then we provide an example of using that model (in §3.3). Subsequently, we show how we can compute these metrics (in §3.4) and how we can store and use their values (in §3.5). Figure 2 gives a total view of the functionality of the metrics and the proposed extension. In brief, we could say that the extension should allow all information expressed in the tables of Figure 1 to be expressed in a machine processable (and queryable) manner. If such information is exposed in a machine-readable format, it could be exploited in various methods, e.g.: – For producing visualizations that give an overview of the contents of a warehouse. – For comparing different warehouses and producing comparative reports. – For aiding the automatic discovery of related data since software services/agents based on these metrics could decide which SPARQL endpoints to query based on time/cost constraints. – For crediting good sources since these metrics make evident, and quantifiable, the contribution of a source to the warehouse.
Another requirement is that the proposed extension should be compatible with the existing VoID vocabulary and the available VoID-based descriptions.
Figure 3 shows the core conceptual model as an implementation in RDF/S. As one can easily see, the implementation reuses classes and properties from VoID, Dublin Core, RDF/S and XML Schema Definition, while the new modeling elements are defined in a separate namespace, generally named with the prefix vdw and here depicted as the default namespace.
We can see that there is the notion of Measurement which is actually a specialization of Event and therefore inherits the property date. A measurement is carried out by an agent using a specific metric according to one (or more) configurations over one (or more) datasets (atomic or composite) and produces a value (i.e. literal).
Each metric is an individual with a URI and is defined by a resource (e.g. the DOI of the scientific paper that defined that metric). The notion of Configuration concerns issues that explain how the measurement was done. At this point, and for the requirements at hand, we need two subclasses: the first concerns the way URI equivalence is defined (e.g. through the policies given in Table 2), while the second concerns how the entities of interest are defined. Regarding the latter the current modeling allows someone to specify the desired set of entities by providing a SPARQL query that returns them.
The extension is currently published in http://www.ics.forth.gr/isl/ VoIDWarehouse, and apart from the vocabulary it contains URIs for the connectivity metrics. 3.3
Here we show how with VoID and the proposed extension we can describe
the MarineTLO-based warehouse [
Now, Figure 6 illustrates how the value of the connectivity metric called
common URIs, as computed over FLOD and Ecoscope, is represented using
the proposed extension. We can see that MatWare carried out this measurement
and computed 1,738 common URIs between these two sources, according to the
suffixCanonicalization-based URI equivalence. Also notice that exact definitions
of suffix Canonicalization and commonURIs, are given in the paper [
void:Dataset . vdw:measurement_1 rdf:type vdw:Measurement; vdw:carriedOutBy dst:MatWare; dcterms:date "2014-03-14T03:18:56"^^xsd:dateTime; vdw:over dst:EcoscopePart; vdw:over dst:FLODPart; vdw:accordingTo vdw:suffixCanonicalization; vdw:producesValue "1,738"; vdw:usesMetric vdw:commonUris . vdw:commonUris rdfs:isDefinedBy <http://ceur-ws.org/Vol-1133/paper-40.pdf> . vdw:suffixCanonicalization rdfs:isDefinedBy <http://ceur-ws.org/Vol-1133/paper-40.pdf> . dst:MatWare rdf:type dcterms:Agent .
For making clear the entire life cycle, here we show how the values of the connectivity metrics can be computed using SPARQL queries (this corresponds to the process “1. SPARQL compute” of Figure 2).
Common URIs. The metric Common URIs over two sources Si and Sj , can be computed with the following query: SELECT COUNT (DISTINCT ?o) WHERE { graph :Si {{?s1 ?p1a ?o} UNION {?o ?p1b ?o1}} . FILTER(isURI(?o))
graph :Sj {{?s2 ?p2a ?o} UNION {?o ?p2b ?o2}} } In the context of the warehouse, this metric should be computed over all pairs of sources, i.e. all (Si, Sj ) such that Si, Sj ∈ S and i 6= j. Note that this metric is symmetric, i.e. the value of the pair (Si, Sj ) is equal to the value of (Sj , Si). Common Literals. The Common Literals between two sources Si and Sj can be computed in a similar manner, i.e.: SELECT COUNT DISTINCT ?o WHERE { graph :Si { ?s ?p ?o} . FILTER(isLiteral(?o))
graph :Sj { ?a ?b ?o} } Again, this metric should also be computed over all pairs (Si, Sj ) of the warehouse.
Unique Triples Contribution. To compute the unique triple contribution of a source, say S1, to the warehouse S = S1, . . . , Sk, we have to count the number of triples of S1 that do not intersect with the triples of any of the other sources of S (i.e. with none of the sources in S2 ... Sn). This can be done using the following query: SELECT COUNT(*) WHERE { graph :S1 { ?s ?p1 ?o} .
FILTER NOT EXISTS { graph :S2 { ?s ?p2 ?o} } .
...
...
FILTER NOT EXISTS { graph :Sn { ?s ?pn ?o} } } Complementarity Factor. This metric is computed for a specific entity over all sources of the warehouse. In particular, the complementarity factor of an entity e is increased by 1 for each source Si ∈ S that contains at least one unique triple having the entity e. This means that if all sources in S contain unique triples for e, then its complementarity factor will be n. The query below gives the complementarity factor of an entity e over S. Notice that the WHERE clause contains n graph patterns. Each graph pattern i returns 1 if Si contains unique triples for the entity e, or 0 otherwise.
SELECT (?CF1+ .. + ?CFn) AS ?CF WHERE { { SELECT xsd:integer(COUNT(*)>0) as ?CF1
WHERE { { graph :S1 { ?s ?p1 ?o } }
FILTER NOT EXISTS { graph :S2 { ?s ?p2 ?o} } .
...
...
FILTER NOT EXISTS { graph :Sn { ?s ?pn ?o} } FILTER (regex(?s, e,’i’) || (regex(?o, e,’i’))) } } ...
... { SELECT xsd:integer(COUNT(*)>0) as ?CFn
WHERE { { graph :Sn { ?s ?pn ?o } }
FILTER NOT EXISTS { graph :S1 { ?s ?p1 ?o } } .
...
...
FILTER NOT EXISTS { graph :Sn-1 { ?s ?pn-1 ?o } }
FILTER (regex(?s, e,’i’) || (regex(?o, e,’i’))) } } } } Increase in the Average Degree. Let E be a set of entities coming from a source Si. To compute the increase in the average degree of these entities when they “enter” into the warehouse, the following query computes both average values (before and after the entrance to the warehouse) and reports back the increase. Note that that above query considers the “entity matching” policy of Table 2.
SELECT ((?avgDW-?avgDS)/?avgDS) as ?IavgD WHERE { { SELECT xsd:double((count(?in)+count(?out)))
/xsd:double(count (distinct ?e)) as ?avgDS FROM :Si WHERE{ ?e rdf:type :E.
{?e ?in ?o} UNION {?o1 ?out ?e} } } { SELECT xsd:double((count(?in)+count(?out)))
/xsd:double(count (distinct ?e)) as ?avgDW FROM :W WHERE { ?e rdf:type :E .
{ ?e ?in ?o} UNION {?o1 ?out ?e} } } Time efficiency. Table 4 shows the query execution times for computing the metric Common URIs for each of the three policies of Table 2, i.e. Exact String Equality, Suffix Canonicalization and Entity Matching9. The first row corresponds to the pure SPARQL approach that was presented earlier. The second row corresponds to a hybrid approach, where more simple queries are used for 9 The experiments were conducted using Openlink Virtuoso V6.1, Ubuntu 12.10 64bit, Quad-Core, 4 GB RAM getting the resources of interest (i.e. the two sets of URIs, one for each source Si, Sj), and Java code is used for computing their intersection. We observe that the hybrid approach is faster than the pure SPARQL, as the comparisons are implemented faster in Java. In general, we have observed that the hybrid approach loses in time efficiency when the implemented queries return a big amount of data (as in the case of Unique Triples Contribution), while it is faster (than pure SPARQL) in comparisons. The following query shows how SPARQL applies Suffix Canonicalization on URIs using some functions of Virtuoso. Regarding this policy, the pure SPARQL approach becomes less efficient, as the string comparisons cost more when implemented over the endpoint. Regarding the third policy, both approaches are increased by 1 minute. This uniform increase is reasonable as an additional graph that contains the triples with the sameAs properties is taken into account. SELECT DISTINCT bif:lower(bif:regexp_substr(’[^#|/]+\$’,?o,0)) as ?o FROM :Si {{ ?s ?p ?o } UNION { ?o ?p ?s } FILTER(isURI(?o)) } 3.5
The measurements computed by the aforementioned queries can be represented and exchanged using the VoID extension. They can also be stored in a graph space in the triplestore; indeed MatWare can compute and store these triples in a separate graph space in the same SPARQL endpoint (this corresponds to the process “3. store” of Figure 2). Figure 8 gives an example of this procedure for the metric Common Literals over the sources Ecoscope and FishBase. The query both computes the metric and inserts the computed values (expressed using the VoID extension) to a graphspace.
After that, one could retrieve these values from the warehouse using SPARQL queries (this corresponds to the process “4. query” of Figure 2). For example, the query in Figure 9 returns all triples of the warehouse that concern the common URIs metric. 4
W3C has proposed VoID as the vocabulary for describing interlinked and open linked datasets. Motivated by a concrete scenario of modeling connectivity metrics in the context of an operational semantic warehouse of the marine domain, we have proposed an extension of VoID which is able to represent these metrics. prefix dcterms:<http://purl.org/dc/terms/> prefix dst:<http://www.ics.forth.gr/isl#> prefix vdw:<http://www.ics.forth.gr/isl/VoIDWarehouse#> INSERT INTO dst:Metrics { vdw:measurement_2 rdf:type vdw:Measurement ; vdw:usesMetric vdw:commonLiterals; vdw:producesValue ?commonLiterals; dcterms:date "2014-03-14T03:19:45"^^xsd:dateTime; vdw:carriedOutBy dst:Matware; vdw:over dst:EcoscopePart; vdw:over dst:FishbasePart . } WHERE{{ SELECT (count(distinct ?o) as ?commonLiterals )
WHERE { graph dst:EcoscopePart { ?s ?p ?o } . FILTER(isLiteral(?o))
graph dst:FishbasePart { ?a ?b ?o } } } }
The benefit of the proposed extension is that it allows someone to publish the metrics and their associated values in a standard and machine processable way. Finally, we have shown how the metrics can be computed and we have reported the times required for computing these metrics either using solely SPARQL, or SPARQL and programming language code.
This work was partially supported by the ongoing project iMarine (FP7 Research Infrastructures, 2011-2014).