Database Reference
In-Depth Information
2 Related Work
To the best of our knowledge, there is no geospatial data management sys-
tem that is scalable, supplies high performance levels and provides all appropri-
ate management functionality in a LD technology-independent way. Our claim
is backed up by the following table which classifies and compares the related
approaches with respect to particular comparison criteria. These criteria include:
-
distribution:
a characterization of whether the approach is
centralized
,
clus-
tered
or
cloud-based
which is related to the approach capability to scale in
order to exhibit better performance levels.
-
store type:
the type of store (i.e.,
research (and open)
or
proprietary
)which
can have an influence on the cost of the respective approach based on the
required capabilities.
-
geospatial support:
indicates the level of geospatial support provided by the
approach (i.e.,
none
,
basic
and
advanced
), where the difference between a basic
and advanced support is that the second enables the use of more advanced
geospatial operators, such as (feature) aggregation operators.
-
service level:
indicates the level of the services offered (i.e., RDF
query
or full
management
services). Obviously, a full management service level is preferred
as the additional effort in adapting a particular approach selected will be
minimal.
-
input mapping:
indicates the capability of the approach to map input data of a
different form to RDF ones (i.e.,
none
,
relational
and
multiple
input formats).
This is a very interesting and important aspect, especially if we consider the
current form of the Web and the need for transforming data from various
formats into RDF ones. Thus, a data mapping approach supporting multiple
input formats will be preferred. Please note that as the relational mapping is
the most involved one, especially in terms of realization, an approach is evalu-
ated as supporting multiple input formats when it supports at least relational
mapping along with the mapping from one or more additional formats. Please
consider that such kind of mapping might also be used for doing on the fly
SPARQL to SQL rewritings so that we can query the original data sources.
As it can be seen from Table
1
, our approach is the sole approach evaluated
with the best possible choice for each criterion. Next comes Oracle with two
particular disadvantages with respect to our approach: (a) it is a proprietary
solution and (b) does not support the mapping of data from various formats
to RDF. Virtuoso is another good alternative, which apart from being propri-
etary has the disadvantage of providing only basic geospatial support. Another
possibility is the Strabon RDF store which however does not offer a data input
mapping functionality. The worst approaches seem to be the cloud/clustered
research ones which do not provide geospatial and full RDF management sup-
port as well as input mapping functionality. This seems quite reasonable if we
consider the fact that such approaches have been developed to showcase how
Cloud-based technologies can be exploited to boost the query answering time.
Search WWH ::
Custom Search