Putting it all Together

We have clearly seen that we need some type of ``repository'' which manages multiple feature collections (datasets), which maintains scopes, which can respond to queries about schemas, which can evaluate feature handles to return features and which can be identified and located from part of a feature handle's observable value. We need such a repository for each ``project'' on which several people are working; incorporating several ``lines of effort'' at the same time. We have also seen that we need something (else?) which can evaluate feature descriptors and, if valid, return a feature handle. This latter service could make use of RDF and other metadata services and protocols.

It is suggested that the repository manager be identified with a URN and that feature handles also be legal URNs but where the initial part of the scheme-specific encoding is the URN of its manager.

It is not necessary that the repository manager actually be ``on line'' at any time: the important characteristics are soley the persistence and uniqueness of the identifiers. If desired, these could be maintained by an entirely manual process consisting of paper forms and authorised signatures as currently used in many file-and-directory-based GIS archives. (The probability that an organisation will want to participate and yet refuses to register with DNS is assumed to be neglible.) There are places for randomly generated identifiers, e.g. when generating new feature handles in disconnected remote sites, or generating short locally unique strings for storage as feature attributes [15]. However, since we need some kind of federated system for relating repositories which are going to exchange data anyway, it makes sense to use that for the primary architecture. We should also remember that not every feature necessarily needs to be issued an identifier, especially in inherited systems, and that identifiers do not necessarily need to be held ``in'' the dataset as attributes on the features.

The types of relationships, e.g. version relationships, between the different feature collections making up a collectively-managed ``scope'' could usefully be partially standardised [5] to encourage a software component market. The types of relationships which already exist in ad hoc, manually managed systems are varieties of ``source'' data related to ``working'' datasets and eventually ``published'' data. Those GISs which provide version services have better defined semantics for the narrower domain of version control.