What do we need Identifiers For?

Having reviewed a bewildering array of identification mechanisms, nearly all under active development, we can see that we really do need some clearer idea of what we want identifiers for and how we want to use them:

1.

When doing updates, we need to be able to determine if the supplied identifier in the update refers to a feature in the original dataset to decide whether to update it or to create a new one.

2.

When comparing versions, we want to be able to find the previous version of a feature from the current version and vice versa.

3.

When doing some work outside a GIS, we want to be able to make a reference to specific features in a published dataset which persists for some indefinite time into the future.

4.

Within some defined scope (usually the ``same'' dataset), we want to assert that a relationship of a certain type exists between two features and we want this relationship to persist when any feature collection containing the related features is copied to another dataset.

5.

When we copy a feature collection in its entirity, it would be useful if there were some simple relationship between the feature handles in the two copies, e.g. differing only in some prefix, so that access in both directions were quick and easy.

We introduced feature descriptors and feature handles earlier; but how can we use them ?

• A feature descriptor is useful only for finding and then acquiring a specific feature. It has no other purpose and since feature descriptors come from ``outside'' the system expressed in a variety of types of language there can be no guarantee that two different descriptors will not produce (resolve to, evaluate to, return) the same feature. In which case the two (different) descriptors have ``equality by reference''.
• A feature handle will also produce a feature, but some scopes will also define that only identical feature handles can return the same feature. This means that ``equality by value'' implies ``equality by reference''.
• There is also the intermediate case where a feature descriptor may be defined by a global scope which provides a ``re-phrasing'' service such that two different descriptors of specified types could be cast to a canonical form in which ``equality by value'' does then imply ``equality by reference''.

What do we mean when we say a feature descriptor ``returns a feature''? There are two possibilities:

1.

we get a lump of binary data encoded in a ``well-known format'' which contains all the feature's attribute data and sufficient references to a schema to be able to decode the names and types of the attributes,

2.

we get a feature handle which incorporates the identification of the scope in which is is valid.

Whereas when we ask what happens when a feature handle ``returns a feature'', we must mean that we get the binary lump.

Assuming that we used the descriptor to make a query on some third-party indexing service, we get a handle but we must then find the actual dataset repository. We require some naming scheme so that we can use the handle to then obtain information about the scope object itself (the dataset).

Each scope may have its own coding function which it uses to evaluate the handle and to return the feature itself (in a well-known binary format).

Some scopes may publish their coding functions and allow independent access into the dataset, e.g. a directory tree of files in well-known formats, others may maintain their own integrity and require access using opaque handles using a private coding function.