InverseFunctionalProperties and distributed hash tables
This thread discusses the intuitive use of InverseFunctionalProperties to refer to objects expressed in RDF on the semantic web. What is an inverse functional property? It is a property (or attribute) of an object that uniquely identifies that object. A social security number is an InverseFunctionalProperty of a person that, when taken alone, uniquely identifies the person who possesses it.
It is valuable to refer to objects by inverse functional properties because it short-circuits the technical (and sociological) problem of assigning canonical URIs to objects, as is the current RDF practice. URIs are a hierarchical naming scheme based, somewhat unintuitively, on the domain name system. This scheme binds object names to an existing hierarchy, which serves a practical purpose at the moment: it combines the naming and the addressing schemes for referring to objects.
However, there's a mismatch here. DNS load balancers are an illustration of this mismatch. You request information from www.yahoo.com, but there isn't a single host called "www.yahoo.com" serving up that information. Your request is, in truth, a request for information from an abstract resource: yahoo. See this paper for a better treatment of this topic.
For InverseFunctionalProperties to serve as effective resource identifiers, there must be a distributed mechanism to associate properties with the resources themselves. Put differently, some abstraction layer must be built between the naming scheme that InverseFunctionalProperties provide, and the addressing scheme that URIs provide.
InverseFunctionalProperties exist in a flat namespace, bound only by the constraints of the ontologies that define them.
Consider a distributed hash table which provides a flat keyspace. InverseFunctionalProperties can comprisee part of that keyspace. Simply concatenate the ontology URI that describes the InverseFunctionalProperty with its value and write or read the key in the distributed hash table. The value written and read from the hashtable for such a key would be a resource URI for the InverseFunctionalProperty's inverse (optionally signed by its owner or by a third party).