The publication of data as Linked Open Data (LOD) gains traction. There are lots of di erent datasets published, more vocabularies are becoming W3C Recommendations and with the introduction of DCAT-AP v1.1 and the emergence of the European data portal and a multitude of national open data portals, lots of datasets are discoverable and accessible using their DCAT-AP metadata in RDF. Yet, the consumption of LOD is lacking in comfort and availability of tools that would exploit the bene ts of LOD and allow users to discover, access, integrate and reuse LOD easily, as promised by the promoters of LOD and supposedly paid by the additional e ort put into the 5-star data publication by the publishers. Compared to the consumption of 3-star CSV and XML les, the consumption of LOD is still quite complicated and the LOD bene ts are not exploited enough nor visible enough to justify the e ort for many publishers. In this paper we identify 40 requirements which a Linked Data Consumption Platform (LDCP) should satisfy in order to be able to exploit the LOD bene ts in a way that would ease the LOD consumption and justify the additional e ort put into LOD publication. We survey 8 relevant and currently available tools based on their coverage of the identi ed requirements.
H.3.5 [Online Information Services]: Data sharing; H.3.5 [Online Information Services]: Web-based services
A considerable amount of data represented in a form of Linked Open Data (LOD) is now available on the Web. More and more data publishers are convinced that the additional e ort put into the last 2 stars of the now widely accepted and promoted 5-star Open Data deployment scheme1 will bring the promised bene ts to the users of their data. The publishers rightfully expect that the users will appreciate the 5-star data much more than the 3-star CSV les or 2-star Excel les given that the proper publication of 5-star data is considerably harder and more costly to achieve.
Naturally, the expectations of users of LOD are quite high as the promoters of LOD promise that the non-trivial effort put into publishing the data as LOD will bring bene ts mainly to them, the users of the data. These bene ts, compared to 3-star Open Data, include better described and understandable data and its schema, safer data integration thanks to the global character of the URIs, better reuse of tools and libraries, more context thanks to the links and the ability to (re)use only parts of the data. They are supposed to come at the cost of learning RDF, dealing with potentially broken links and understanding the risks of presenting data from foreign datasets. However, in the best case scenario, what the user gets now is usually either a link to a rather large dump in Turtle or RDF/XML, a limited SPARQL endpoint or the possibility of dereferencing a URI and getting an HTML or RDF description of a data entity. While this is appreciated by Linked Data experts and enthusiasts, more regular users used to 3-star open data will not be able to enjoy the expected bene ts. They expect a level of experience higher than what they get by using tools for "less open" 3-star data such as Microsoft Excel2, Google Sheets3 and many more for tabular data and tools such as Altova XMLSpy4, oXygen XML editor5 and many more for XML data. These tools provide a comfortable way of working with such data and therefore, the experience of working with 5-star Linked Open Data is expected to be even better. This is supported also by the presentation of the 5-star scheme where the fourth star is for using URIs and, preferably, RDF, and the only downside should be the need to learn RDF. However, this is not the case so far because compared to 3-star data there is a lack of quality tools for LOD processing at the consumer end.
LOD is mainly a data publishing format, therefore, the data published in this format usually need to be transformed back to a representation usable by conventional tools which need e.g. the speed of relational databases or the power of existing data mining or machine learning techniques. Linked Open Data exists for some time now and lots of the necessary techniques and vocabularies which can be used to facilitate its proper consumption are W3C Recommendations now. There is a multitude of tools which work with LOD in speci c ways. What is missing is a platform, or at least a set of compatible and reusable tools, that could be recommended to the users, who are familiar with 3-star open data and used to work
with it, as the platform that will enable them to immediately enjoy the promised bene ts of LOD.
The contribution of this paper is a set of requirements on a Linked Data Consumption Platform (LDCP) which we identi ed as crucial in order to be able to demonstrate the bene ts of Linked Open Data to the consumers. We consider three types of stakeholders, a journalist, who wants to create articles based on Linked Data, a data analytic, who wants to use the data published as Linked Data in a tool of his choice and a developer, who wants to build services on top of the platform. Majority of the requirements are based on existing W3C Recommendations and popular research areas. Moreover, we compare 8 existing tools, which are presented in the literature as tools for Linked Data consumption, with respect to the given requirements. Some of them provide visualizations features, which is a kind of consumption. Some of them provide other features also important for consumption (e.g., data transformation, advanced data loading from di erent kinds of data sources, data previews, etc.).
This paper is structured as follows. In Section 2 we provide a motivating example of a user scenario in which a journalists wants to consume LOD and expects a platform that will enable him to enjoy the promised LOD bene ts. In Section 3 we describe the identi ed requirements and in Section 4 we survey existing tools and their coverage of the identi ed requirements. In Section 5 we survey related studies of Linked Data consumption options and in Section 6 we conclude. 2.
To motivate our work, let us suppose a potential user of Linked Open Data, who could ideally use the Linked Data Consumption Platform (LDCP) to gain the bene ts promised by the promoters of publishing data as LOD. The potential user is a data journalist used to working with non-RDF open data on the web such as HTML pages, CSV tables and Excel les and XML les. The goal of our user is to collect data about population of cities in Europe and display an informative map in an article he is working on. The intended audience of the article are statisticians who are used to CSVs, so the user wants to also publish the underlying base data as a CSV le attached to the article. The user now wants to use Linked Data because he heard that it is the highest possible level of openness according to the, now widely accepted and promoted, 5-star Open Data deployment scheme. The user expects the experience working with LOD will be somehow better than the experience working with 3-star data such as CSV or XML les once he learns RDF. Let us suppose that the user has learned RDF and understands the above mentioned side e ects of the distributed character of LOD. Now the user expects to get better access to data and a better experience working with the data than if the data was available in a 3-star CSV or XML le. Naturally, the rst thing which the user expects is a tool that can be used to work with such data and enjoy the promised bene ts of LOD. Ideally, the tool would be an integrated platform that supports the whole process of LOD consumption from identi cation of data sources to the resulting visualization or processed data ready to be used by other tools while using the bene ts of LOD where applicable.
Intuitively, the user needs to nd data about cities in Europe, their location so that they can be placed on a map and data about their population. Here, LOD can help already since recently a number of national open data catalogs emerged and are being harvested by the European data portal6 which utilizes the DCAT-AP v1.17 vocabulary for metadata about datasets and exposes a SPARQL endpoint, which can be queried for e.g. keywords (city) and formats (RDF - SPARQL, Turtle, JSON-LD, etc.) LDCP could therefore support loading and querying of dataset metadata from DCAT-AP enabled catalogs and even contain a few wellknown catalogs, such as the European data portal, preset so that the user can see and search some datasets right away.
Let us suppose that the user has identi ed a few candidate datasets that could be of use to him and needs to choose the ones that contain information needed for his goal. Let us also suppose that the metadata loaded from a catalog contains correct access information for each candidate dataset. A helpful functionality of LDCP could be various kinds of summaries of the candidate datasets and characterizations based both on the metadata of the dataset and the actual data of the dataset. For example, for each candidate dataset, LDCP could o er the vocabularies used, numbers of instances of individual classes and their interlinks, previews tailored to the vocabularies used, datasets linked form the candidate, datasets linking to the candidate, spatial and time coverage, etc. Using this information, the user would be able to choose a set of datasets containing the required information easily.
Another feature that could help the user at this time is recommendation of related datasets. Based on information on datasets already selected such as vocabularies used, entities present or their metadata, LDCP could suggest similar datasets to the user. Given a set of datasets to be integrated, a useful feature would be the ability to analyze those datasets in order to nd out whether they have a non-empty intersection, e.g. whether the population information speci ed in one dataset actually links to the cities and their locations present in another dataset.
Let us now suppose that the user has all the datasets needed for his goal. There could be an interoperability issue new to Linked Data caused by the existence of multiple vocabularies describing the same domain. In our example, it could be that the dataset containing the locations of the cities could have the geocoordinates described using the schema:GeoCoordinates8 class from the Schema.org vocabulary while e.g. the tools to be used next accept the geo:Point 9 class of the WGS84 Geo Positioning vocabulary. Since both of those vocabularies are well-known and registered at Linked Open Vocabularies (LOV)10, LDCP could contain components for data transformation between them and o er them to the user automatically. Because of the growing number of vocabularies, a desired feature would be sharing of those transformation components in the community around LDCP.
Our potential user now has all the datasets needed in an
interoperable format. What is left is to choose the entities
and properties from those datasets that are needed for the
goal and which can be omitted. This could be done in a
graphical way e.g. used by graphical SPARQL query builders
such as SPARQLGraph [
Finally, the data should be prepared for further processing.
7https://joinup.ec.europa.eu/asset/dcat_application_profile/
asset_release/dcat-ap-v11
8http://schema.org/GeoCoordinates
9http://www.w3.org/2003/01/geo/wgs84_pos#Point
10http://lov.okfn.org/
This could mean RDF enabled visualizations such as in the
Linked Data Visualization Model (LDVM) [
In this section, we identify and group the technical user requirements that we see as crucial for a Linked Data Consumption Platform (LDCP). We focus on requirements which can be satis ed by exploiting the bene ts of consuming Linked Data compared to 3-star data and which, when implemented, can be used to demonstrate those bene ts. 3.1
In order to start working with Linked Data, the user has to rst identify relevant datasets, which is what we call dataset discovery. There are multiple ways in which LDCP could assist the user with this task.
The most obvious way is the ability to load dataset metadata from a data catalog. There is the DCAT12 vocabulary and DCAT-AP v1.1, the DCAT application pro le for European data catalogs, providing the vocabulary support for dataset metadata. There are existing data catalogs utilizing these vocabularies and providing access to the machine readable, standardized metadata. Examples of such data catalogs are the European Data Portal13, integrating dataset metadata from various national data catalogs and the European Union Open Data Portal14 providing information about the datasets from the institutions and other bodies of the European Union. LDCP should therefore support loading this machine readable information and provide means of searching the metadata to identify datasets needed by the user. LDCP should also have some well-known data catalogs preloaded, so that the user can start choosing datasets right away. A part of this discovery scenario is the ability of the user to add a dataset to LDCP through its URI, provided the URI is dereferencable. As a partial coverage of this requirement we may consider the non-RDF, but widely used CKAN API15.
Requirement 1 (Catalog support) Support for loading dataset metadata from dereferencable dataset URIs and data catalog APIs, data dumps and SPARQL endpoints which provide the metadata (preferably DCAT and DCAT-AP compatible metadata).
The previous requirement assumes that publishers describe
their datasets with manually created metadata. However,
a more advanced way of dataset discovery is through
implementation or support of a custom crawling and indexing
service not necessarily relying on metadata found in data
catalogs. Such a service can build its own index of datasets
comprising metadata computed automatically on the base
of the content of the datasets. The index may encompass
used classes and predicates, labels of resources or their other
properties present in the dataset [
Discovered datasets marked as relevant by the user can than be used as a context for other kind of dataset discovery which searches for additional semantically related datasets. By the term \semantically related" we mean various kinds of semantic relationships among datasets. E.g. these can be datasets which provide statements about the same resources, use the same vocabularies or contain links to the datasets in the context.
Requirement 3 (Context-aware discovery) Support for recommendation of additional datasets semantically related to datasets already discovered and selected by the user. 3.2
A common problem of Linked Data tools out there is their limited support for standards of representation of Linked Data. LDCP should support all the standard ways of accessing Linked Data so that there are no unnecessary limitations of the available data. These include IRI dereferencing, SPARQL endpoint querying and the ability to load RDF dumps in all standard RDF 1.1 serializations16, i.e. RDF/XML, Turtle, TriG, N-Triples, N-Quads, RDFa and JSON-LD. This functionality can be achieved relatively easily, e.g. by integrating Eclipse RDF4J17 (formerly OpenRDF Sesame) or Apache Jena18. Inability to load all standardized formats from the dump (only some) will be classi ed as partial coverage of the requirement.
Requirement 4 (IRI dereferencing) Ability to load RDF data by dereferencing IRIs using HTTP content negotiation and accepting all RDF 1.1 serializations.
Requirement 5 (RDF dump load) Ability to load data from an RDF dump in all standard RDF serializations, both from an URL and locally.
Requirement 6 (SPARQL querying) Ability to load data from a SPARQL endpoint.
Besides these traditional ways of getting Linked Data, LDCP should support the recently published Linked Data Platform19 speci cation for getting resources.
Requirement 7 (Linked Data Platform input) Ability to load data from the Linked Data Platform compliant servers.
In addition to RDF data sources, LDCP should support at least in some basic form the input of non-RDF data sources. For tabular data in CSV, this can be done automatically in a standardized way using Generating RDF from Tabular Data on the Web20 W3C Recommendation. For tree-like data in XML, a support for XSLT transformation can be included and for JSON data, support for adding a JSON-LD21 context can be provided. 16https://www.w3.org/TR/rdf11-new/#section-serializations 17http://rdf4j.org/ 18https://jena.apache.org/ 19https://www.w3.org/TR/ldp/ 20https://www.w3.org/TR/csv2rdf/ 21https://www.w3.org/TR/json-ld/ Requirement 8 (Non-RDF data input) Ability to load non-RDF data sources using standardized methods.
In addition to be able to load data in all standardized
ways, LDCP should also provide a way of saying that the
data source should be periodically monitored for changes,
e.g. like in the Dynamic Linked Data Observatory [
The discovery mechanism provides the user with a list of candidate datasets he can potentially nd useful. Therefore, the user has to nally select the required datasets from these candidates. The dataset preview should help the user with this selection by presenting a short summary of each discovered dataset. This can be done in a number of di erent ways and again we focus on the bene ts which arise from the Linked Data principles. Some of the Linked Data vocabularies recently became W3C Recommendations22, which are de facto standards, and as such should be supported in LDCP. These include the Simple Knowledge Organization System (SKOS)23, The Organization Ontology (ORG)24, the Data Catalog Vocabulary (DCAT) and The RDF Data Cube Vocabulary (DCV)25. Having the knowledge of these vocabularies, LDCP can generate vocabulary speci c summarization of each of the candidate datasets more e ectively, giving the user more information for his decision making. For example, if LDCP detects the usage of DCV, it can summarize the dataset by giving an overview of the number of data cubes present, concepts used in component properties etc. while in the case of ORG it can summarize it by displaying the number of organizations with the numbers of their departments etc. Speci cally for each of these vocabularies, the time and spatial coverage can be computed for each dataset where appropriate.
Requirement 10 (Preview { W3C vocabularies) Support for dataset preview based on used vocabularies that are W3C Recommendations.
While so far there are only few vocabularies that have
reached the W3C Recommendation status, there is plenty
of vocabularies that are also well-known and widely reused.
Some of them are on the W3C track as Group notes, e.g.
VoID26 used to describe RDF datasets and vCard Ontology27
for contact information. Others are registered in Linked Open
Vocabularies [
Requirement 11 (Preview { LOV vocabularies) Support for dataset preview based on used well-known vocabulary registered at Linked Open Vocabularies.
A proper Linked Data dataset is described by its metadata using standardized vocabularies such as DCAT and VoID. These vocabularies provide support for basic characteristics like indication of vocabularies used, identi cation of main classes and properties and numbers of classes, properties and their instances. These are all relevant metadata that should be accessible to the user to support his decision making. Requirement 12 (Preview metadata) Provide dataset description and statistics metadata recorded in DCAT, DCATAP and VoID.
Similarly to the discovery requirements, the user may require a preview compiled not on the base of descriptive and statistical metadata provided by the publisher about the dataset but on the base of metadata automatically computed on the base of the dataset content. As can be seen in the LOD Cloud diagram32 and also in LODStats, the majority of datasets are not so big that they could not be e ectively queried to get these basic statistics (e.g., classes and properties used, number of their instances, etc.) Therefore, it is a reasonable requirement that LDCP should be able to generate these statistics independently of what is contained in the metadata records.
Requirement 13 (Preview data) Provide dataset description and statistics based on automatic querying the actual data.
Part of the statistics based on the actual data could be the schema extracted from the data in the form of classes and properties used and their interlinks based on the presence of links among their instances. Such a schema can be very informative, however, its generation can take some time even for moderately sized datasets.
Requirement 14 (Preview schema) Provide a schema extracted from the given dataset in a form of classes and properties among them.
Besides metadata, statistics and used vocabularies there
are many other criteria regarding data quality that should
also be presented to the user to support his decision making.
There is a recent survey of such techniques [
Requirement 15 (Quality indicators) Provide quality measurements based on Linked Data quality indicators. 3.4
The requirements discussed in the previous sections support the user in discovering individual datasets isolated from one another. However, the user usually needs to work with 29http://xmlns.com/foaf/spec/ 30http://www.heppnetz.de/projects/goodrelations/ 31http://schema.org 32http://lod-cloud.net/ them as with one integrated graph of RDF data. Therefore, he expects that the datasets are semantically related with each other and that he can use these semantic relationships for the integration. If a dataset is not in a required relationship with other discovered datasets the user needs to know this so that he can omit the dataset from the further processing. We have brie y discussed possible kinds of semantic relationships in Requirement 3. However, while Requirement 3 only required LDCP to show datasets which are somehow semantically related to the selected one, now the user expects a deeper analysis of the relationships.
Each existing semantic relationships among discovered datasets should be presented to the user with a description of the relationship, i.e. the kind of the relationship and its deeper characteristics. The descriptions will help the user to understand the relationships and decide whether they are relevant for the integration of the datasets or not.
When the datasets share resources the deeper characteristics may involve the information about the classes of the resources, the ratio of the number of the shared resources to the total number of the resources belonging to these classes, compliance of the datasets in the statements provided about the shared resources, etc. When the datasets are linked together the deeper characteristics may be similar, e.g., information about the classes of the linked resources from both datasets complemented with the linking predicate, the ratio of linked resources to all resources which belong to the classes, etc. This can be extended by considering not only direct links expressed in a form of a single RDF statement but indirect links formed by a path of RDF statements. When the datasets neither share the resources nor there are links between them, the semantic relationship may be given by the fact that they contain resources of the same classes. The provided deeper characteristics for this kind of relationship may involve information about the shared classes, numbers of resources which can be uni ed and compliance of the datasets in the statements about those resources. Requirement 16 (Semantic relationship analysis) Provide characteristics of existing semantic relationships between datasets which are important for the user to be able to decide about their possible integration.
As a supplemental requirement to the previous one is to
support methods for automated or semi-automated deduction
of semantic relationships between datasets. These methods
may be useful when semantic relationships cannot be directly
discovered on the base of statements present in the datasets
but new statements must be deduced from the existing ones.
There are tools like SILK [
The user now needs to process the discovered datasets. As we discuss later in Section 3.7, this means either visualizing the datasets or exporting them for the purposes of processing in an external tool. In general, it means to transform the datasets from their original form to another one, which is necessary for such processing. We can consider transformations, which transform RDF representation of the datasets to another RDF representation or to other data models (relational, tree, etc.). In this section, we discuss the former transformations. The others are covered in Section 3.7. A transformation involves various data manipulation steps which should be supported by LDCP.
First, LDCP must deal with the fact that there exist different vocabularies which model the same part of reality. We say that such datasets are semantically overlapping. Let us note that semantic overlapping is a kind of semantic relationships discussed in Requirement 16. Therefore, it often happens that the vocabulary used in the dataset is di erent from the one required for the further processing. In such situation it is necessary to transform the dataset so that it corresponds to the required vocabulary. The transformation can be based on an ontological mapping between both vocabularies or it can be based on a transformation script speci cally created for these two vocabularies. This requirement is realistic when we consider well-known vocabularies (e.g., FOAF. Schema.org, GoodRelations, WGS84 pos, etc.). There are not so many well-known vocabularies so LDCP implementors may create, provide or even share libraries of such mappings or transformation scripts.
Requirement 18 (Vocabulary-based transformations) Provide transformations between well-known semantically overlapping vocabularies.
It is also frequent that datasets do not re-use well-known vocabularies but use speci c vocabularies created ad-hoc by their publishers. Even though transformation support for these vocabularies in terms of the previous requirement is not realistic (simply because there are too many ad-hoc vocabularies), the user can still expect that LDCP will provide some kind of support when such vocabularies appear among the discovered datasets. In particular, the users can expect that LDCP will at least discover that there exist possible semantic overlaps between the vocabularies. Discovering these semantic overlaps may be achieved by ontology matching techniques which are already involved in Requirement 17.
Having the possible semantic overlaps, the user then needs
to specify the particular transformation on his own. Or he
can expect that LDCP will be able to (semi-)automatically
discover the transformation itself. Such discovery can be
achieved by exploiting various techniques of ontology
alignment [
Requirement 19 (Vocabulary alignment) Provide (semi)automated discovery of transformations between semantically overlapping vocabularies.
Another often required kind of data manipulation is inference. Inference can be used when additional knowledge about the concepts de ned by the vocabulary is provided which can be used to infer new statements. Such knowledge is expressed in a form of so called inference rules. Semantic mappings between vocabularies mentioned above are also a kind of inference rules but here we consider them in their broader sense.
Requirement 20 (Inference) Support inference on the base of inference rules encoded in vocabularies (or ontologies) of discovered datasets.
A speci c kind of inference rules allows one to specify that
two resources are the same real-world entity (i.e. owl:sameAs
predicate). Having such inference rule means that statements
about both resources need to be fused together. Fusion
does not mean simply putting the statements together but
also identi cation of con icting statements and their
resolution [
Requirement 21 (Resource fusion) Support fusion of statements about the same resources from di erent datasets.
Besides transformations, the user will typically need the
standard operations for data selection and projection. LDCP
can assist the user with speci cation of these operations
by providing graphical representation of the required data
subset, which may correspond to a graphical representation
of a SPARQL query like in SPARQLGraph [
Requirement 22 (Assisted selection and projection) Support assisted graphical selection and projection of data.
Besides the above described speci c data manipulation requirements, the user may need to de ne own speci c transformations expressed in SPARQL.
Requirement 23 (Custom transformations) Support custom transformations expressed in SPARQL.
Having the support for all kinds of data manipulations described above it is necessary to be able to combine them together so that the discovered datasets are transformed to the required form. The user may be required to create such data manipulation pipeline manually. However, we might also expect that LDCP complies such pipeline automatically and the user only checks the result and adjusts it when necessary.
Requirement 24 (Automated data manipulation) Support automated compilation of data manipulation pipelines and enable their validation and manual adjustment by users. 3.6
For the output data to be credible and reusable, detailed provenance information should be available capturing every step of the data processing task, starting from the origin of the data to the nal transformation step and data export or visualization. There is The PROV Ontology33, a W3C Recommendation that can be used to capture provenance information in RDF.
Requirement 25 (Provenance) Provide provenance information throughout the data processing pipeline using a standardized vocabulary.
Part of metadata of a dataset should be, at least in case of open data, the information about the license under which the data is published. A common problem when integrating data from various data sources is license management, i.e. determining whether the licenses of two data sources are compatible and what license to apply to the resulting data. This problem gets even more complicated when dealing with data published in di erent countries. A nice illustration of the problem is given as Table 3 in ODI's Licence Compatibility34 page. 33https://www.w3.org/TR/prov-o/ 34https://github.com/theodi/open-data-licensing/blob/master/ guides/licence-compatibility.md Requirement 26 (License management) Support license management by tracking licenses of original data sources, checking their compatibility when data is integrated and helping with determining the resulting license of republished data. 3.7
One of the possible goals of consuming Linked Data can be
generation of visualizations of discovered data sets. This can
be either automated, based on correct usage of vocabularies
and a library of visualization tools as in the Linked Data
Visualization Model (LDVM) [
Requirement 27 (Manual visualization) O er visualizations of Linked Data based on manual mapping from the data to the visualizations.
Requirement 28 (Vocabulary-based visualization) Offer automated visualizations of Linked Data based on wellknown vocabularies.
The other possible goal of our user is to output raw data for further processing. The output data can be in various formats, the most popular may include RDF for Linked Data, which can be exported in various standardized ways. The rst means of RDF data output is to a dump le using standardized serializations. The inability to create a dump in all standardized formats (only some) will be classi ed as partial coverage of the requirement.
Requirement 29 (RDF dump output) Ability to export RDF data to a dump le in any standardized RDF serialization.
Another way of outputting RDF data is directly into a triplestore, using one of two standardized ways, either the SPARQL Update query35 or using the SPARQL Graph Store HTTP Protocol36.
Requirement 30 (SPARQL Update output) Ability to load RDF data to a SPARQL endpoint using SPARQL Update.
Requirement 31 (SPARQL Graph Store HTTP Protocol output) Ability to load RDF data to a SPARQL endpoint using the SPARQL Graph Store HTTP Protocol.
Lastly, LDCP should be able to write RDF data to Linked Data Platform compliant servers.
Requirement 32 (Linked Data Platform output) Ability to write data to Linked Data Platform compliant servers.
Another popular choice for data export is into CSV for tabular data. The usual way of getting CSV les out of RDF data is by using the SPARQL SELECT queries. Such CSV les can now be supplied by additional metadata in JSON-LD according to the Model for Tabular Data and Metadata on the Web37 W3C Recommendation. The inability to produce such metadata will be classi ed as partial coverage of the requirement. 35https://www.w3.org/TR/sparql11-update/ 36https://www.w3.org/TR/sparql11-http-rdf-update/ 37https://www.w3.org/TR/tabular-data-model/ Requirement 33 (Tabular data output) Ability to export CSV data and its standardized metadata.
Requirement 39 (Project reuse) O er support for reuse of shared projects as data sources.
Besides tabular data, tree-like data are also popular among 3-star data formats. These include XML and JSON, both of which the user can get, when a standardized RDF serialization in one of those formats, i.e. RDF/XML and JSON-LD, is enough. This is already covered by Requirement 29. However, for such data to be usable by other tools, it will probably have to be transformed to the JSON or XML format accepted by the tools and this is something that LDCP should also support. The ability to export data in only one of those formats will be classi ed as a partial coverage of the requirement.
Requirement 34 (Tree-like data output) Ability to export RDF data in custom XML and custom JSON.
For advanced graph visualizations it may be useful to
export the data as graph data e.g. for Gephi [
For most of our requirements there already is a tool that satis es them. The problem why there is no platform using these tools is caused by their incompatibility and the large e ort needed to do so. LDCP does not have to be a monolithic platform and can consist of multitude of integrated tools. However, the tools need to support easy integration, which motivates the next requirements. Each part of LDCP and LDCP itself should use the same API and con guration which it exposes for others to use. The API should again be standardized, i.e. REST or SOAP based, and the con guration should be consistent with the rest of the data processing, which means in RDF with a de ned vocabulary. Requirement 36 (API) O er an easy to use API (REST or SOAP based) for all important operations.
Requirement 37 (RDF con guration) O er RDF conguration where applicable.
Since one of the ideas of Linked Data is distribution of
e ort, the data processes de ned in LDCP should
themselves be shareable and described by an RDF vocabulary
as it is with, e.g. the Linked Data Visualization Model
(LDVM) pipelines [
In addition to the ability of using a project that someone else has created, an important feature is the ability of LDCP to reuse this project as a data source inside a new project. This facilitates the creation of a library of useful projects and project parts, each maintained by its author and reused by others in the same manner as other Linked Data.
When the whole process of data gathering, processing and output is described in LDCP, it may be useful to expose the resulting transformation process as a web service, which can be directly consumed by e.g. web applications. This could facilitate live data views or customizable caching and update strategies.
Requirement 40 (Deployment of services) O er deployment of the data transformation process as a web service. 4.
In this section we survey existing approaches to Linked
Data discovery, data processing and visualization and
evaluate, how they cover the requirements identi ed in Section 3.
We include approaches related to Linked Data consumption
and covering multitude of our requirements, showing that
they are a good starting point on a way to a full- edged
integrated solution. The single-purpose approaches which
cover only one or few closely related requirements besides
data input and output serve more as a motivation of our
requirements, but we omit them here as they are not meant
to be used as integrated platforms. An example of such a
tool is the well-known linking tool SILK [
Information Workbench as a Self-Service Platform
for Linked Data Applications (IWB) [
The most complex representative of an integrated
solution is the platform resulting from the recently nished
FP7 project Linked Data Analytics (LinDA) [
Linked Data Integration Framework (LDIF) [
Linked Data Visualization Wizard (LDVizWiz) [
LinkedPipes ETL (LP-ETL) 39 is an ETL tool mainly
for Linked Data publication. However, with its library
of data processing units (DPUs), it can also support the
Linked Data consumption as, besides RDF input and output
through SPARQL (Requirement 6) (Requirement 30)
(Requirement 31) and dumps (Requirement 5) (Requirement 29)
and non-RDF input and output (Requirement 8)
(Requirement 33). There is a repository for sharing of DPUs on
GitHub through which the functionality can be extended.
The user interface is, however, not meant for users who would
like to consume Linked Data and is purely ETL oriented.
LP-ETL is a successor to Uni edViews [
LinkedPipes Visualization (LP-VIZ) 40 is a an
implementation of the Linked Data Visualization Model [
OpenCube [
There is a mention of Assisted Linked Data Consumption Engine (ALOE)43 at the website of the AKSW group, however, no results of this project were found. The project was supposed to provide a platform for easier consumption of Linked Data through tackling schema mismatches.
In this section we go over related work in the sense of similar studies of Linked Data consumption possibilities.
The Survey on Linked Data Exploration Systems [
A recent survey on Ontology Matching [
A survey on Quality Assessment for Linked Data [
A survey on Linked Data Visualization [
In Exploring User and System Requirements of Linked
Data Visualization through a Visual Dashboard Approach
[
In this paper we identi ed the lack of user friendly software for Linked Data consumption, which causes unful lled user expectations as to the usability and usefulness of Linked Data, especially compared to the comfort when working with 3-star open data such as CSV or XML les. We identi ed 40 42https://www.r-project.org/ 43http://aksw.org/Projects/ALOE.html technical user requirements on the Linked Data Consumption Platform and surveyed 7 existing tools which cover parts of these requirements and seem to be good candidates for establishing the way to LDCP. It is clear that in order to ful ll the user expectations, an integrated platform implementing the identi ed requirements is needed. Lots of those requirements are already covered by separate tools, which are, unfortunately, hard to integrate with each other, prohibiting their easy integration in such a platform. This is often caused by the fact that those tools were created as part of a now nished research project where they served their speci c purpose and are now no longer maintained. It seems that the ideal way would be if such tools provided a simple REST API and were con gurable via RDF, as it is e.g. with Apache Jena Fuseki44 triplestore or R2RML45 implementations. 7.
This work was supported in part by the Czech Science Foundation (GACR), grant number 16-09713 and in part by the project SVV-2016-260331. 8. 44https://jena.apache.org/documentation/serving_data/ 45https://www.w3.org/TR/r2rml/