In the examples and elsewhere on this site, you will see mention of iCites being query-able. I wanted to give some background on iCite queries to provide a little context until I can do a full example on them.

The idea for queries of iCites comes out of the perspective that accessing web pages is a form of querying. I think of browsing the web as being like functionally similar to accessing a database in the following ways:

• browser = the query builder
• URI = the query subject and modifiers (i.e., table name, where and order by clauses)
• HTTP header = the query very (i.e., select, update)
• web server = the database engine
• web page = the result set(s)
• browser = the reporting tool (i.e., render results in nice format)

What I find interesting about this set of interactions, in light of a RDBMS database using SQL, is that the browser lets one start with a kind of default query--a HTTP GET (i.e., typing a URL in the location bar on the browser), which is not unlike a SQL SELECT. But, once a result set is returned to the browser, the report (i.e., rendered web page) itself acts as an interfaces to new queries.

Classic database reporting / interface tools like PowerBuilder actually do a "closed" version of this interaction too--the classic example being the master - detail interface. In the master - detail interface, there is a master record area and a second area with details. Here is a quickie HTML mockup of this kind of interaction, with master records on the left and detail records on the right:

In many database interfaces, each time you click on a different master record, a new query is run returning the corresponding detail record. (Of course, database interface tools like PowerBuilder have ways of pre-loading and caching things--and n-tier applications usually have to have aggressive pre-loading and caching strategies to minimize round-trips from middle tier to the database and/or from client to middle tier.)

What is "closed" about the classic database interaction is the limitations on what one can link to when compared with a web page in a browser that has access to the Internet--but this is really a matter of relative closed-ness. With database tools, usually one is connected to the one database--so the master and detail bits are all from a single database. Of course, actually, most of these tools can actually handle spanning multiple databases, referencing external files, and now also pulling in web pages. So, technically, these database interfaces aren't absolutely closed off--though most often they are used in closed networks and with interface constraints that restrict how people are allowed to play with them.

But, with websites, in some sense, every web page is like a database table or view. And, web pages link not only within their own server, but all over the place--across many servers. So, imagine a world of open databases where anyone could create relationships between any tables on any DBMS servers. This is something like the web already--and the iCite net imagines some ways to realize this further.

An iCite is, through its URI (including query parameters), completely decomposable--referring to the term functional decomposition that is used to descibe web services. iCites are certainly a web service in this sense.

Coincidentally, blojsom, which powers this blog, uses a "flavor" query parameter to change the ("result set") format of a blog entry between HTML, RSS 0.92, RSS 1.0 (RDF), RSS 2.0, and text. (Just noticed the new version 1.9 of blojsom also supports a RSD flavor--need to check that out.) Take a look at the permalinks below and notice how the query parameter changes. I will leave it as an exercise for the reader to try flavor=text. But, iCite HTTP URIs work similarly to this as a way of expressing queries.