On the simplest level, iCites are lists where each item on the list links to some information, plus has some attributes assoicated with the link. These links can link to other iCites, or to any addressable information (e.g., URLs on the Internet).

This example illustrates how iCites can be used as interfaces to the structures of information systems. First, here is a definition of information architecture quoted from the super excellent and highly recommended book: Information Architecture for the World Wide Web: Designing Large-Scale Web Sites (second edition), by Louis Rosenfeld and Peter Morville:

in·for·ma·tion ar·chi·tec·ture n.

1. The combination of organization, labeling, and navigation schemes within an information system.
2. The structural design of an information space to facilitate task completion and intuitive access to content.
3. The art and science of structuring and classifying web sites and intranets to help people find and manage information.
4. An emerging discipline and community of practice focused on bringing principles of design and architecture to the digital landscape.

(thanks to the O'Reilly Network Safari Bookshelf for making it easy for me to copy that quote from the book, which can be read online there!)

iCites are relevant to the first two definitions, though I think that information architects may someday value iCites as a useful tool in their science, art, discipline and community.

Since iCites list information, they can naturally list information about the organization, labeling, and navigation schemes of an information system. Of course, other things can be used to create such lists. In my information architecture practice, I usually start my lists in a text document (using EditPad). So, what is different about iCites?

There are two things that iCites can do well that are presently hard to do:

1. expose the information structures of working systems (e.g., websites) as part of the system
2. package information structures in modular ways and reuse them

Information architects create many documents to specify the architectures of an information system. But, the *architecture* in those documents are usually then either embedded in the code of the system (e.g., a controlled vocabulary reflected in a search engine's results) or are simply used as guides for the system design and implementation (e.g., a visual designer makes buttons with names matching the architected labeling system). This seems to make sense, I think, because of the way conventional architecture is done. But, in the digital domain, here is why it seems strange to me:

If we look at a conventional physical building and how it is architected, we see architecture specified on paper or on computer or with small models, and then the actual structure is built large-scale out of wood, steel, stone, etc. But with information architecture, we see architecture defined with digital information and the structure also built out of digital information. So, why is it, with information systems, that the architectural information and the actual system implementation don't co-exist in a single system (perhaps what might be called a meta-system)

In computer programming, there are tools that allow one to visually model a computer program, and then generate computer code--or vice versa (take computer code and produce a visual model). Examples are tools that use the Unified Modeling Language and tools that produce Entity-Relationship diagrams for databases. This is something akin to what iCites can do, though iCites are, most basially, just lists (which can be represented either in visually interesting ways, or as just lists of text).

If you are not familiar with what information architecture documents look like, you might appreciate this article on Building a Metadata-Based Website, by Brett Lider and Anca Mosoiu on the excellent Boxes and Arrows information architecture themed website.

One thing this article illustrates is how much information can be developed about a website in order to inform its design and implementation. And, what I am saying is: imagine what you could do if all of that information about a website was also made accessible through a standard published interface that could be linked to, queried, and used as a module in other documents. This is where iCites and information architecture can meet.

Here are some practical examples of how iCites can express information architecture, and how this might be used:

• an iCite that exposes a query-able site index for a website
• an iCite that exposes a thesauri of terms associated with each section or page of a website
• an iCite that exposes sub-topics of a section of a website, and allows subscriptions to changes in those topics
• an iCite that exposes elements of a page of a website, and allows subscriptions to changes in those elements (like, update me when a new client name is added to the client list in the projects zone of the work example page)
• an iCite that connects multiple department-level iCite website indexes into a single, master index
• an iCite that connects sections of multiple sites on the same topic, indicating that (whatever their names) each section represent the same sub-topics
• an iCite as a prototype site map
• an iCite as a prototype page schematic
• an iCite as a prototype navigation scheme
• an iCite as an ontology for search terms

Finally, remember, iCite links have attributes and those attributes are extensible and can themselves be published and subscribed to as iCites. So, all of the metadata associated with architectural elements would also be exposed. And, perhaps more importantly, an unlimited number of attributes can be added to these links by multiple people in a decentralized fashion, reflecting multiple views.

For example, a section of a website might be labeled "important" by one user type, and might be labeled "irrelevant" by another user type. Each user type could use an iCite interface to "re-index" the site using the weighting of these attributes.

Note: future versions of this example will include live iCite examples, tips and tricks, how to's.