Database Reference
In-Depth Information
guarantee that the URI will not be either ambiguous or so unwieldy to be effectively
unusable. To be more precise, in most cases it is impossible.
An alternative approach that resolves the issues of both change and uniqueness
is simply to make the URI opaque, that is, not even try to make it human readable.
This is our view and was also the view of Tim Berners-Lee when considering URIs
in the more general context of the Web as a whole: “The only thing you can use an
identifier for is to refer to an object. When you are not dereferencing, you should
not look at the contents of the URI string to gain other information” (Berners-Lee,
1996). In this view, the URI is usually based on a combination of domain name and
some arbitrary unique ID, normally just a number that is assigned to the thing being
identified and never reissued to anything else. So, in such a scheme Medina could
have a URI of the form mm:/670020 and Ash Fleet Farm would have mm:/871113.
Such URIs are quite jarring to the eye, but they are nonetheless free from the prob-
lems identified. Small compromises are possible; for example, we could differentiate
between physical things and administrative areas so that the farm could be identified
as a topographic object: mm:/topo/871113. The ugliness of this solution is likely to
become less of an issue in the fullness of time as better Linked Data tools are used,
the URI becomes less visible, and it is less relevant whether it is visible or not.
Last, we have spoken up to this point only of the situation from the perspective
of Merea Maps. If we consider the situation from the point of view of a different
organization, then that organization may choose to use the URIs allocated by Merea
Maps or allocate its own URIs to the same things. This of course means that while
URIs must be unique, they need not be exclusive. Simplistically, the ideal is for
each thing to have only one URI assigned, but this is rarely possible, so we have to
accept that things will have multiple URIs assigned by different organizations. The
reasons why an exclusive URI is not always possible are twofold. It is necessary for
the second organization to know that a URI will always have been assigned by the
first organization and that this URI is publicly accessible; this is rarely the case:
There is always the possibility that the receiving organization will be in a position to
acquire information about the existence of the resource before the first organization.
There are occasions when this will definitely not be the case, a postal service issuing
postcodes, for example, but this kind of guarantee is rare. The second issue is one of
trust: How much does organization A trust organization B to always have the URI
available? This problem is likely to be reduced with time as organizations become
better at managing URIs, but it is always likely to exist to some extent or other.
The trick therefore becomes how to manage the problem of multiple URIs rather
than attempt to resolve it. Mechanically, this is about correlating these different URIs
using
owl:sameAs
, but this is really an abbreviation for the general problem of data
conlation, something that will be dealt with more fully elsewhere in this topic.
In summary, the main issues when considering assignment of URIs are whether
it is possible to reuse URIs already assigned by others and, if a new URI is needed,
how opaque it should be, that is, how much of the semantic meaning of the item
should be encoded in the URI itself. The former problem is one that revolves around
the mechanics of the order of assignment and trust. The second problem is one of
how reliable and resilient to change a URI can be if it attempts to embed semantics
of the resource within it.
