Database Reference
In-Depth Information
to nodes, and no link may connect directly to another link but must do so via a
node. It is fairly straightforward to represent this model as we can generate link and
node classes and map our Features to them. However, it does raise an interesting
issue: In Linked Data terms, the things we represent are real things that we wish to
describe using information that is obtained by dereferencing the associated URIs.
However, the classical network model is a representation of an
abstraction
of the
real-world things. To explain this difference further, consider how we would repre-
sent our example network. Medina is a City (in turn a kind of settlement, that is in
turn a Feature), and Medina Road is a road (in turn a Feature), so we would expect
these assertions to have been explicitly stated:
Medina is a City.
Medina Road is Road.
However, in our abstract network model, Medina is also a Node, and Medina
Road a Link:
Medina is a Node.
Medina Road is a Link.
So, now Medina is both a City and a Node, but can it actually be both in the same
model? One is modeling a real-world thing, the other an abstraction. We also saw
the Old Medina Road is broken up into a number of road stretches, and these are
directly connected. In the network model, we cannot do this; they have to be con-
nected via nodes, so we have to invent nodes to join the road stretches. Now, it can be
argued that Merea Maps also had to invent road stretches, but in this case, it is easy
to demonstrate the physical existence of the stretches. It is very common practice for
roads to be segmented in this way and the stretches named for road maintenance and
management purposes; of course, in many cases these may be considered and named
as roads in their own right. The same cannot be said for the invented nodes; they
physically represent nothing in the real world; they are a requirement of an abstract
model and nothing more. We could change the relationship from “is a” to “is repre-
sented by,” but the real point is that the abstract network model is not really adding
anything other than additional complexity. This is not to say that this model is not
without its benefits: It provides a uniform way of representing a network that can sig-
nificantly improve computational efficiency over the network. However, this example
highlights a difference in purpose between the two ways of representing a network:
The first focuses on simplicity and accuracy of representation, the latter on consis-
tency and computational efficiency. Each therefore makes compromises, and each is
appropriate in its place. It is also worth adding that it is perfectly simple to represent
the standard link and node model as Linked Data, and there will be many occasions
when this is what you need to do. For example, it is better to express the network in
link and node form if you know in advance that the network will be used for routing.
The general issue is of course not a problem specific to networks; it will occur
wherever an abstract model introduces modeling elements that have no real-world
counterpart. The OGC Feature and INSPIRE Spatial Object are other examples of this.
