Database Reference
In-Depth Information
Web document describing the object available at all. For our example, an HTTP GET
request is made for
http://id.mereamaps.gov.me/topo
.
The server then returns the whole
RDF/XML file for all the Topographic Object data, and the client then has to run its
own code to search for triples involving
http://id.mereamaps.gov.me/topo#00012
.
7.3.3 S
laSh
verSUS
h
aSh
The advantage of the Hash mechanism is that only one HTTP GET request needs to
be made, so data access is faster. However, the downside is that all RDF triples that
share the same URI up to the # will be returned, which could be a big overhead if
the dataset is large. We would recommend using 303 redirects (Slash URIs) when
the dataset to be queried is large, particularly when the application does not demand
many repeated queries. Hash URIs are more suitable for early testing or prototyping
purposes, as the server does not need to be configured to perform the 303 redirects,
or when the RDF dataset is small and unlikely to change much over time. Hash URIs
are also used when RDF is embedded in HTML Web pages using RDFa (Resource
Description Framework-in-attributes), helping to keep the HTML document's URI
separate from the URIs of the RDF resources.
7.4 LINKED DATA DESIGN
This section assumes that you have some GI stored in a GIS or RDB or encoded in
an XML-based GML file or similar output format, and your aim is to publish it as
Linked Data. If you already have RDF data in a triple store, and you are satisfied
with your RDF data model, skip forward to Section 7.5.5., where discussion on pub-
lishing RDF data begins.
There are five main steps in the process of designing Linked Data: First, decide
what your Linked Data is about; second, look at your current GI data; third, specify
your RDFS (RDF Schema) ontology
3
; fourth, mint create your URIs; and finally,
generate your Linked Data. We look at each of these steps now in turn.
7.4.1 S
tep
1: D
ecIDe
W
hat
Y
oUr
l
InkeD
D
ata
I
S
a
boUt
We go into more detail about how to design an ontology in Chapter 10, but the pro-
cess for developing an RDFS ontology follows along the same lines, albeit producing
a simpler structure. First, think about the purpose of your data. What will you use
it for? And, a more difficult question: What might other people want to use it for in
the future? While you can never plan for all the possible future uses, selecting mean-
ingful names that are well known in your subject area and are not limited to your
own organization's jargon will help with this. Also, avoid overspecifying your data
in the RDFS ontology. If you include domains and ranges for every class, this will
limit their future reuse. Make sure that everything included in the RDFS ontology is
absolutely necessary to describe your classes. Also, make a statement of the scope:
What should be included, and as important, what
is not
necessary to be included in
the RDFS ontology? Scope creep is an inevitable pitfall of authoring an ontology,
