Database Reference
In-Depth Information
In order to acquaint the prospective user with our previous work and cor-
responding system version, the next subsections analyse the previous system
architecture and its main basic components.
3.1 Previous System Architecture
The architecture of the previous version of the system, shown in Fig.
1
, comprised
a component called
Distributor
responsible for processing user requests in terms
of Linked Data Management Service (LMS) methods and then forwarding each
request to one or more
Scaling Layers
. The latter components were responsible
for the management of data pertaining to one or more data providers (and thus
corresponding RDF graphs) such that data partitioning among different layers
and replication at same layer was achieved in order to sustain a high-level of data
reliability and integrity. Each scaling layer consisted of many image instances,
called just instances from now on, each exposing the basic system functionality
in terms of LD Management and containing a LMS implementation and an
underlying Virtuoso Universal Server exploited by this service. Each scaling layer
was responsible of forwarding a user query or export request to one instance,
thus catering for load balancing, and all update requests to all instances to
guarantee that all such instances were mapping to the same RDF data. As LMS
and Virtuoso constitute the backbone of our system providing the basic LD
management functionality exposed by it, they are analysed in the following two
subsections.
3.2 LD Management Service
The two variants of our system rely on Virtuoso as the back-end triple store. While
Virtuoso offers a SPARQL end-point, a REST-based Service called LMS was devel-
oped which exposes an API that provides all appropriate management function-
ality to be exploited by data providers and potential users of geo-spatial Linked
Open Data (LOD). This service abstracts way from the particularities of any RDF
Data Management API exposed by an underlying triple store and enables the
simple and intuitive use of a specific set of LOD management methods. In fact,
with little re-engineering effort (mostly concerning connection peculiarities), LMS
could well function with a different underlying store. LMS allows a programmatic
as well as a web-based access to its methods, where the web-based access can be
facilitated through the development of particular forms accessible via a browser in
a specific URL. Moreover, LMS exposes a querying capability that allows produc-
ing results in the following formats: “sparql-results/xml”, “sparql-results/json”,
“sparql-results/tsv” and “sparql-results/csv”
14
. In addition,
importing
and
csv and tsv
→
Search WWH ::
Custom Search