Database Reference
In-Depth Information
• Borders: The boundaries of two regions intersect, but their interiors do
not intersect.
•
Spatially Equivalent: The two regions have the same boundary and interior.
Unlike in the ontology development of Chapter 10, we do not now start to link
together the concepts and relationships in the RDFS ontology. Unless there are tri-
ples that are valid at the class level (i.e., true for every instance of the class), which is
not often the case, this will not be necessary. The only exception to this is when we
want to use the RDFS ontology to validate the data, that is, when we need to impose
a requirement for every instance of the class on the data. If Merea Maps wanted to
make sure that it was supplying quality data, such that every Parish included in its
data was supplied with area information, it could link the class Parish to the relation-
ship “has Area” with a datatype object. Think carefully before doing this, however,
as it will mean that you will need to make sure you have the data available to instan-
tiate the ontology. And having said that, it is now a good time to turn to the data and
look at how it is structured.
7.4.2 S
tep
2: l
ook
at
the
c
Urrent
GI D
ata
The reason for not looking at the data until the second step of the process is to avoid
preconceived ideas about what we want the RDFS ontology to look like. Frequently,
it is the case that the data is in a legacy format, and the current database or file format
structure is a consequence of previous technological and implementation limitations
rather than a requirement of the domain. This gives us a chance to start afresh with
a new ontology. It is certainly possible to assign one URI to each row in the database
table, spreadsheet, or comma-separated file, to create class names based on the table
names and property names based on the column names, but they may not always be
very meaningful to the outside world. Merea Maps has a dataset in a table, named in
their database as “Regions,” which is based on the structure of
Table 7.1
.
If alternatively Merea Maps was working with proprietary formats such as ESRI
Shapefile or MapInfo Tab or MID/MIFF files for exchange of information, it would
at this point look at the .dbf file (or similar) that stores the attribute information of
the administrative region features.
There are a number of points to note from Table 7.1. First, not every field in the
data record is needed. Some are only really internally relevant to Merea Maps. Other
fields correspond to metadata, for example, edit date. Second, we do not need to
stick to the field names that were previously chosen and perhaps shortened due to
limitations on string length in the database technology. We can choose meaningful
names for our classes and predicates. RDF has its own limitations on string names;
for example, no spaces are allowed, so we can also use the
rdfs:label
to provide
more human-friendly readable names. Third, we will reuse vocabularies and ontolo-
gies if possible. This not only saves us work but also makes linking to other datasets
much easier. Merea Maps identified the WGS84 Basic Geo Vocabulary as useful for
expressing latitude and longitude. Other potentially useful RDF vocabularies have
already been outlined in Chapter 5.
