Database Reference
In-Depth Information
6.3 IDENTITY: NAMES
Names, whether they are place names or names of any other thing, can be complicated.
Place names are also known by the formal term
toponym
, but we use place name in
this topic. Places can have any number of names: an oficial name (sometimes more
than one), short names, vernacular names (ones given through common usage that
may or may not be official), historic names, and so on. Names may not be unique:
think of how many High Streets and Springfields there are. Indeed, names are rarely
unique. Names also can have their own life cycles, quite independent of the thing
that they name. In our example island of Merea, Ash Fleet Farm was once known as
Manor Farm, a name not used for over 100 years. So, we might want to hold informa-
tion about the name itself, not just about the thing it names.
But, let us start with a simple case and then progressively look at the possi-
ble complications; like many things, the level of complication that you choose to
represent will be dependent on the complexity of the situation you encounter and
the need you have to represent that complexity. A general piece of advice is to
keep it as simple as possible. The simplest possible case is when a place only has
one name and will only ever have one name (or you will only ever care about one
name). In this case, the simplest thing to do is to represent the name as a string, for
example, “Ash Fleet Farm.” Now, even in this simplest example there are choices
to make. These choices concern the use of the relationship (property) that is used
to associate the name with the place it identifies. The most obvious thing to do
is to use
rdfs:label
, as discussed in Chapter 5. After all, is this not what this
property is all about, to provide a human-readable label for the thing? The answer
is yes, but; the “but” concerns technical limitations that apply to this property and
most specifically the fact that you cannot define a domain or range for this property.
Also, the established use of
rdfs:label
is to be a simple human-readable label
for anything (things, properties, and datatypes), whereas we would like to assign the
semantic meaning of “name” to our property. It is therefore better to define a sepa-
rate property that you have complete control over, or to use an already-established
property, the most obvious being
foaf:name
. The use of
foaf:name
is a popular
solution for naming places, but it was really designed to identify people, not places.
However, there is nothing at present to limit the use of
foaf:name
to people,
so in many respects it is fine to use
foaf:name
; after all, why invent when you
can reuse? The arguments against this course of action are not overwhelming but
nonetheless should be taken into consideration. The first question is simply a matter
of how comfortable you feel about reusing something not really intended for the
purpose you have. The second is potentially more damaging (although probably
unlikely in this case): What do you do if the World Wide Web Consortium (W3C)
decides to give
foaf:name
the domain of
foaf:Person
? Now, wherever you
have used
foaf:name
the implication is that the named places are also people.
The safest solution is the establishment of a simple property to name places, such as
“
has place name
.” Until such a property is established as a standard, it is prob-
ably better either to use
foaf:name
or to define your own. Perhaps a reasonable
compromise is to define your own place-name property with a domain of places and
make it a subproperty of
foaf:name
as follows:
