The choice of URI as the identifier was made very early in the design process, and has never really been questioned. It is based on the following characteristics of URIs:
The existing URL protocols immediately usable: http, ftp, file etc., as well as the probability of useful future protocols. Especially in mind are the specifications for identifying single files inside JAR archives with a URI, which makes it simpler to download whole archives of components at once, as well as definitions for identification over IOCP (used in CORBA) with the help of URIs. URIs, and not least URLs, has been proved useful and functional.
The existing standardized encoding in ASCII text, making it universally usable, as well as the universal support in different programming environments. A not small part of this point is that users actually are used to this type of identifiers. Note that the encoding of special characters in ASCII is not yet implemented.
The hierarchical structure of the standard URI protocols. This is what makes the idea of a "base URI" work; it is a simple matter of appending one string to another.
The possibility of defining your own protocols. In fact, URIs have exactly the flexibility wanted: it allows everything from completely abstract identifiers (such as URNs) to identifiers such as URLs which specify both location of the object and the protocol of access.
We see no real need for support for the FTP protocol, as this is mostly intended for large file transfer, which is not our case. Perhaps it could be interesting to use for saving components.
The urn:path: protocol is used in order to be able to specify the location of an object without having to specify the method of access, i.e., data format and physical location. Such a protocol is absolutely necessary as seen in the discussion in the section called Functional requirements.
The table resolver mechanism must be replaced, as the idea of everyone having a complete table of paths is absurd. The idea is to replace the table mechanism with, e.g., an LDAP resolver, or even the DNS extension used in the Path URN specification [pathurnspec]. Such a resolver would, for a path, return a base URI and the data format to use, just as the table does today. This resolving represents a considerable overhead if it has to be done for each component downloaded (cf. DNS when browsing the web), which is why only paths are queried, not individual identifiers. This allows us, namely, to cache the resolved paths.
In short, we believe that we are on the right track using Path URNs, even though there are decisions left to take. There has gone a lot of thinking into the design, and we are satisfied with the resulting system.
In fact, we did not originally use Path URNs, but a home brewn protocol. After having experimented with this protocol and enhanced it to fulfill our needs, we recognized that we had mostly redesigned the Path URN protocol. So we decided to switch to this possible future standard.
Note that relative URIs in concept maps and neurons are supported.