GINDD-09-001

Groundwater Information Network

Aquifer Mapping for Groundwater Resources Program

Earth Sciences Sector / Natural Resources Canada

Geological Survey of Canada

Technical considerations for implementing a

URN resolution mechanism for GIN

Date : October 25, 2018

Document Reference Number : GIN DD-09-001

Category : Discussion Document

Author: Eric Boisvert

1.Revision History

Date / Release / Author / Description
2009/10/09 / 0.1.0 / Eric Boisvert / First version
2009/10/19 / 0.2.0 / Eric Boisvert / Rewrote section 4
2009/10/26 / 0.3.0 / Eric Boisvert / Rewrote section 5
2009/11/20 / 0.4.0 / Eric Boisvert / Added comments / improvement from A. Ritchie and discussions with S. Cox
2009/11/24 / 0.5.0 / Eric Boisvert / Added URI is URL to resolver option

2.Introduction

This document explores the concept of urn resolutions as described in ( This document will be used to guide Use Case redaction and Testbed planification for both GIN and GeoSciML communities. Typical GWML datasets, and other complex GML documents such as GeoSciML, use several externally defined concepts, such as vocabularies, units of measures, and common entities or features. Furthermore, due to the deeply nested and recursive nature of complex models, serialized version of the dataset must also use internal and external references to remove duplications and limit the size and the complexity of the dataset. Thisreport does not discuss the resolver implementation details, which should be discussed in another document on the implementation of the resolver, but discusses some aspect of the resolution seen from the client application perspective.

GML has a certain set of syntactic constructs to allow an external reference to be included in the XML document. The external reference can either be an explicit reference to a fragment of valid XML that lies elsewhere, or implicit references where the value conveyed in the document is part of a controlled list. In both cases, a client application parsing the document must be able locate those external resources to either complete the externalized parts of the dataset, or to take action according to the values serialized in the document.

The problem that is explored here is how a dataset making use of external and internal references can be adequately parsed and ingested by a client application. What is expected from a client application to use such a document? What information the client needs? When does the client need to actually fetch a resource? How does it extract this information ?

3.Linkages in GML documents

A formal way to make explicit links to a resource in XML documents is through XLink (deRose et al, 2001). These links are explicit in a sense that the client knows exactly (assuming the client is xlink aware) where linkages are made. GML applications add a second type of external reference that defines an authority for the content of a property in order to constrain the values that can be used. The authority (a.k.a code space) can be a resolvable identifier that can lead to a list of processable terms. We expect that some client applications might want to resolve those lists for various reasons, such as displaying a human readable text to replace a machine readable code (for instance, where multiple languages are involved) or to validate the content of the property. One other important use of those vocabularies is to query a datastore. Any non-numerical properties can only be queried effectively if the client has a prior knowledge of the list of terms and their meaning.

Linkage is expressed using a ‘pointing’ mechanism that can either be explicit, by providing the location of the resource or it can be implicit, where a unique key is provided to access the resource but the location and the method to get the resources is not provided.

For GML and OGC, this unique key is represented as a URN (Uniform Resource Name, see URN isasubtypes of URI (Uniform Resource Identifier). Another type of URI is the well known and URL (Uniform Resource Locator). URN is a scheme to represent an identity while URL is to represent a location. The common metaphor is to compare URN to a person’s name (assuming it is unique) and URL to his address. URN are persistent, URL are variable. The URN does not provide the location of the resource it represents, just its identity. The location of the resource identified by the URN must be resolved (or translated) using a separate system called a resolver.

The benefit of URN + Resolver over explicit URL is debatable. While URN does indeed shield resource identity from its location, it does it by dumping a lot of mechanic on the client application. It also implies that some support infrastructure must be created to provide URN resolution. What is gained by not relying on volatile URL might be lost by relying on a complex resolution infrastructure. Furthermore, the volatility of URL is not inevitable. If there is enough will to maintain the service domain name unchanged, the URLs can become as persistent as a URNs.

We can provide this initial list of pros and cons:

Pros

  • URN are atomic, therefore, they are easier to use as keys (while a URL must be parsed to extract the key). We can’t use the whole URL as a unique key since the location of the service might change, parameters might be slightly different, etc). This is one of the important use cases in dataset processing.
  • URNsare decoupled from the locationof the resource, therefore more robust to service location. Furthermore, URNsare independent of access protocols, therefore alternative API can be used to access a resource. URL implies an access method (WFS[1], SKOS[2]/SPARQL[3], SOS[4], etc.) and prevents alternative routes to be taken by the client application. In other words, URL does not provide good separation of concerns
  • Resolver can be engineered for robustness (redundancy) so when a resolver is down, another can take over transparently.
  • URNs are structured and thus can provide some information to a client about authority and nature of the resource being referred. Furthermore, the syntax constrains are explicit (order of elements and case sensivity) and does not allow creative variations, ensuring that the URN is always presented the same way (more on this later). Also, they are good regular expression[5]targets.

Cons

  • URNs require an external resolver that can suffer all the service access problems we can are used to (server down, corrupted registries, unresolved URN, slow service, proxy configurations). Granted this can also happen with URL, but URNs add one more layer of indirection where up and running WFS (from which the user just got the document) is unreachable because the resolver is down.
  • Complex architecture and several resolution services required (collection of several registries and authorities). Certainly not a KISS system. Having a service that is "resolver" ready implies a lot of work.
  • It is likely that a URN resolver will be tied to a community and document that bridges across communities will be complex to resolve. It essentially shifts the "where's the resource" problem to "where's the resolver" problem.

One of the core arguments to prefer URN over URL is URN persistence versus URL volatility. Although this is not strictly true, in theory a URL could be made permanent, there is one more quality to URN that is important to consider. URN syntax imposes a strict structure to the identifier while URL is looser. The consequence is that several URL strings can actually represent to the same resource. Although it’s not a problem for resolution, it is a problem when the URN is used as a unique key. A unique key is useful to compare two resource pointers to decide if they are the same (ie, is this vocabulary the same as this other vocabulary ?). With the looser URLscheme, the same vocabulary could be accessed through many different URLs, or the “same” URL with slight variations.

One further problem with URL is that data provider must coordinate service location and access method with service provider from other governances. It’s more efficient to leave this problem to an external (central) resolver than to maintain this mechanic on the provider’s end.

Example, let’s consider those fictive URLs. They are all different butcouldpoint to the same resource, in this example; they could represent a vocabulary for a term. :

  • <property codeSpace=””> term</property>
  • <property codeSpace=””> term</property>
  • <property codeSpace=””> term</property>
  • <property codeSpace=”...”> term</property>

(a) and (b) are just different servers, or alternate names that points to the same IP[6] while (c) is the same as (b), but the parameters are in different order and different case, which is perfectly legal as far as URL is concerned. (c) and (d) are again the same server, but different APIs. When those URLs are needed to provide a unique identifier (are two identical terms coming from the same vocabulary ?), URLs can’t be trusted unless there is a very strict encoding rule for URL, and even this would not help if the vocabulary is accessible from various servers or through various APIs. Of course, we don’t expect that URL structure would vary when provided from a single provider, but the whole point of interoperability is that we must deal with many providers. URN syntax is just easier to police.

Bottom line: URNsare good when we need to identify thing, URLs are good when we need to locate thing, which is precisely what their names stand for!. Choosing between URN and URL is really a matter of defining the role of the URI.

3.1.URN Structure

URNs are structured strings following a strict rule of hierarchical composition. The syntax is defined in It is composed of a series of alphanumeric strings separated by semi-colons. Strings are case-sensitive and the order of the strings (the scheme) is controlled by some governance. Reed (2004) proposed a specific URN for OGC while Cox (2008) is proposing a CGI scheme at . Thoses schemes regulates the creation of URN identifier for GeoSciML and therefore has ramifications into GWML. So far, there is no formal URN scheme for GWML (which is a gap).

4.Resolver and Resolution

Once we have a URN, we need to fetch the resource it stands for. This is done through a “resolver”. A resolver is an agent wholocates a resource, usually on a network, identified by a unique key (here, a URN). The actual location of the resource might not be explicit in the dataset (ie, from the service that provided the dataset or provided elsewhere in the dataset). It's the role of the resolver to bind this location. The resolver must have access to a registry (a database) to either match an identifier toits location (or use part of the URN structure to match a service that can return the resource) or use a “DNS” (Domain Name System[7]) approach of invoking a series of services hoping that one or more of those service can resolve the location of the resource. In the latter case, the resolver does not have prior knowledge of which service can reach the resource. The service to be invoked can be as simple as the direct address to a document on the web or a more complex parameterized request through a formal API (eg, WFS GetFeature) where the URN (or part of it) becomes parameters to be passed to the service. Each of the services invoked by the resolver can themselves be resolvers, producing a cascading resolution service.

Several resolution approaches are proposed in Daniel (1997).

  • N2R: URN is sent to resolver and resource is returned. An example is a Web based application (such as the one proposed by CSIRO) where a user copy/paste a urn in a form and expect to download/see the resource without knowledge or from where it actually got it. The common implementation uses HTTP 303 ( status code to tell the client application that the resource location has changed. The resolution is done by a process of redirection.
  • N2L: URN is sent to resolver and full url is returned. The client ends up with the full URL to the resource and might decide to fetch the resource of not (or defer the resolution, like turning the string into a HTML hyperlink for the user). Obviously, N2L might return a N2R link.
  • N2C: URN is sent to resolver and description of the resource is return.This technique allows the client application to get further information about the resource, and maybe even use this information to interact with the user.

N2C seems to be the most interesting approach since N2R and N2L are essentially embeded in this solution. If we stand on the client application side, N2C allows all possible operation, assuming that the information provided covers all the need. With a pretty thin layer on top of a N2C, it can be turned into a N2R or a N2L. Therefore, at the core, a resolver should always be able to provide a N2C response.

While all URNs are supposed to actually point to something, they are not all meant to be resolved. They might only be flags that affect the interpretation or processing of the document. Therefore, an efficient resolution process is not reduced to a replacement of all URN to their corresponding resources. Resolving or not resolving the URN depends of the context and where a large amount of URNs are to be processed, we can't request the user intervention for each occurrence. Furthermore, there are different environments where resolution is performed:

  • Deserialisation : The dataset is read from it's XML form into some memory representation by the client application. The decision to resolver a URN is specific to the application.
  • Transformation : The dataset is processed to generate another XML document. We could see this happening in WPS (Web Processing Service, Schut, 2007) where a XML document containing URN is processed and relevant URN are replaced by either URL or by the resolved resource. This is an potential use case where we need to deliver data to a client that does not have resolution capabilities and where it expects valid GML (ie, a generic WFS client such as Gaia[8]). Otherwise, we limit data to only resolver enable client application. We shall at least consider this option to resolve fragment URNs (to be discussed later). In this scenario, WPS or any other middleware application, would act as a preprocessor interacting with a resolver. This use case has some added constrains with regard to deserialisation as we suppose the resulting document must be schema valid, therefore:
  • Non embeddable resources won't be resolved
  • Resolved fragments must be valid and respect gml:id value uniqueness and non-repeatability.
  • The same resource should not be repeated, which is a different issue than gml:id repetition. The same feature can appear twice in the document under different gml:id (specially if the same feature comes from different services, for instance when the original document comes from an aggregation process). Of course, this is not the expected result.
  • Query building. For some properties, the filter need to refer to a vocabulary item, therefore the client application must allows the client to pick terms for a predefined vocabulary. In this case, we need to fetch a list of terms to provide it to the user.
  • Content validation (conformance test) is another use case where the resolution process is used differently. Now the references must be resolved to be checked against a controlled list. This usage is similar to #3

This actually brings a broader discussion on how a generic client can handle a domain specific GML documents. Even if we ignore the URN, we expect a generic client to be only able to 'understand' basic GML entities and all domain specific entities do not have any significance. The client app can at best display the data or provide tools to navigate the database and maybe call a resolver to get to more data. Why would a generic client resolve a URN to fetch a piece of information that it does not have a prior need for ?. The only thing a generic WFS client can do is to draw the geometries (because it knows GML geometries). Then one might ask: who will ever use such a client application just to display geometries?Why bother to create a rich data transfer format if the client application can't do much more than handle the geometries. Following this logic, we can argue that case #2 (above) is not a real requirement because any application that can ingest GWML will need prior knowledge of the domain and then won't need to systematically resolve all URN in the document but only those that are specific for a given task (e.g., draw a water well, get a water level, etc).

4.1.Resolution cases

There are four distinct cases of resolution (or non-resolution) of URI, expressed in the context of a GML document that is being processed by a client application.

4.1.1Fragment

GWML (or any complex GML document) can be deeply nested and even recursive. This produces WFS responses that can be quite large and some deeply nested elements are maybe not relevant for the client and outside the query scope but still serialized because of the connectivity between features. The extra features shall not be serialized but "pointed to" and leave the client application to decide if it want it or not. Fragment are always in xlink:href (but not allxlink:hrefare fragments, most notable exception are 'null' pointers, such as eg: urn:ogc:def:nil:OGC:missing).