Database Reference
In-Depth Information
Aside from text documents, information can also be accessed from the Web via
Web applications or services; from Web-based e-mail to booking an airline ticket,
these allow the user to send and receive information from the Web site, according to the
Web site's own particular data structures and capabilities. The user's data (e.g., e-mail
address or flight details) will be stored in a database, which is accessed by the Web
server. Many Web sites now allow other software developers to access the capabilities
of the service, and hence the data that sits behind their application via an Application
Programming Interface, or API. For example, the Facebook API allows developers to
add a “Like” button to their Web site or enables users to log in to the third-party Web
site using their Facebook log-in details. The API in effect specifies what queries can
be asked of the service and how the response from the service should be interpreted.
While older methods of describing Web services using CORBA (Common Object
Request Broker Architecture), RPC (Remote Procedure Call), or SOAP (Simple Object
Access Protocol) describe what the Web service can
do
, a more recent development in
Web service design is the REST (Representational State Transfer) architecture, which
concentrates on describing the
resources that the service provides.
RESTful appli-
cations use HTTP (Hypertext Transfer Protocol) requests to post (create or update)
data, delete data, or make queries (i.e., read the data). A REST service can respond
with the data formatted in CSV (comma-separated value) files, JSON (Java Script
Object Notation), or XML, and the service can be documented (that is, specifying
what data is available from the service and what queries can be asked) using version 2
of WSDL (the Web Service Description Language) or can be simply described using a
human-readable HTML file. However, although the data access mechanism has been
greatly simplified using REST, the
structure
of the data still remains proprietary to
each Web service, and if the structure of the XML output were to be changed, say,
it would break any client that currently consumes the data. Furthermore, there is no
way of indicating links
out
of the individual dataset, that is, there is nothing analogous
to an HTML link, which could signpost where the authors of the dataset believe it
might overlap with other datasets.
So, if a programmer wants to write an application that uses data from several
APIs (e.g., to plot where all the programmer's Facebook friends live on Google
Maps), the programmer would have to understand the structure of the data returned
by each separate API and discover all the relevant links between the two datasets.
For a well-coded API, this may be relatively straightforward, but it cannot be done
automatically, and it cannot be done in the general case. However, if the data were
published in a structured format that was commonly understood, and if there was
a description of the meaning of the data, this would make each dataset not only
understandable but also discoverable: This is what Linked Data sets out to do. This
is particularly important for Geographic Information (GI), because GI is so often the
common element between datasets. In effect, publishing Linked Data provides an
alternative to publishing an API.
The idea behind the Semantic Web is to describe the meaning of the information
that is published on the Web to allow search and retrieval based on a deeper under-
standing of the knowledge contained therein. The Semantic Web adds structure to
Web-accessible resources so that they are not only human readable but also can be
understood by computational agents. Instead of text, which cannot be processed by
