Commentary by Mark Wahl
Organizing principles for identity systems:
Directory access via Open Search RSS and reader annotation
(2005/6/9)
The Amazon Open Search RSS protocol, mentioned in Google CTO Adam Bosworth's presentation at SD Forum, defines an XML format for encoding search results based on RSS 2.0. The protocol basically defines how a service can specify where search terms are supplied to it in a query string, and how the client can request paging through a result set. Currently it appears to be limited to simple keyword lists for search terms. A9 currently has pointers to more than one hundred search engines for various types of data, including locating persons by their names.
It would be conceptually straightforward to map this onto an enterprise's directory service with content in one of the many white pages schemas, in which the query string is or'ed across the likely search attributes (cn,o, etc.). Each matching entry is represented by an RSS item, either by translating the attributes into HTML (as is done with today's web gateways), or by using a namespace, such as of DSML, SPML, vCard or FOAF, in which the attributes are presented essentially as they are stored. At present, schema negotiation, authentication all would have to happen out-of-band, so this capability would most likely be useful either within private communities where there is a means for authentication and access control, or to access publically-accessible data (such as a University directory e.g. University of Texas, or where the user consents to its publication).
What services come to mind when directory data meets RSS (or Atom)?.
One would be the ability to poll for and retrieve changes to specific, identified users. One benefit of social networking sites such as LinkedIn is that members can change their name, affiliation, email address without needing to directly notify everyone in their contact list who might wish to know their revised information. This element of service could be provided by enterprise and community directories, with essentially unmodified newsreader applicationss as the clients.
The second would be aggregation. While years ago there were attempts, including Centroids, Index DSAs and the Common Indexing Protocol, to make summarized directory entries and substrings available over an indexing protocol in order to support searching across multiple servers (e.g. find a particular person named Roland somewhere in Sweden), I'm thinking of aggregation for joining two or more smaller communities, rather than for joining massive data sets. Ideally a virtual directory could provide a join between identity information in two different services.
The third would be reader annotation. In the current RSS model there's no means for a reader to store annotations and observations on the orginating site, so the reader must store them locally or on a third party server. An infrastructure with the above capabilities would allow an application to read attributes of an object from one service, potentially replicate to another service, and create and store additional attributes about that object on a third service. Such an integration would be most useful if it were to allow these annotations and relationships to themselves be first-class objects along with the 'real-world' objects (e.g. those with types person, department, role, organization, or location), so that they can themselves be replicated. A little island of semantic web.
For imagination purposes, let's suppose that Alice is listed in example.edu's public directory, and so an entry (RSS item http://dir.example.edu/s?x=1234) for Alice is returned when example.edu's directory is searched. Alice and Carol are both members of an organization example.org, and when Carol authenticates to example.org, is able to see Alice's membership information represented as a entry (RSS item http://dir.example.org/s?y=5678). Carol has a Personal Directory Service, and in that service links the two representations by declaring that those two items are part of the same person Alice. Carol might also create other objects in her directory, such as for Alice's neighbor Bob. Carol might choose to use an external aggregator site (such as a Google or A9) such that if in the future Bob created a personal web site or other records appeared that identified him, Alice could be informed and could choose to aggregate that information into her view of Bob's entry.
