Danny Ayers is blogging about Patrick Stickler's materials on URI Query Agents and Concise Bounded Resource Descriptions. This is the thoroughly-being-considered semantic web parallel universe of a fundamental feature of the iCite net I was / am working on.

iCites, essentially, provide descriptions for web resources. Simply, iCites link together web resources (which, if that term freaks you out, just think of web pages) like an act of description. iCites can also add additional data to these links (which, being outside of the linked resources, probably can be usefully thought of as metadata).

One thing in particular that iCite containers (which are just web applications) can do is take in a URI and return a corresponding iCite (set of descriptions) for that URI. So, you can basically ask "give me the iCite that corresponds with http://example.com".

Besides whatever personal idiosyncrasies I may be building into the iCite net so far, I also seem to violate several of the no-nos that URIQA specifically avoids. From the URIQA faqs, here are some answers for the iCite net:

Why not use a link in the representation to provide the URI via which the description can be accessed?
So, the iCite net handles these kinds of links, e.g., along the lines of the way people link to FOAF and RSS (also called autodiscovery links) from web pages, but should be able to be extended to work with URIQA. All the things URIQA would solve sound nice as the iCite net doesn't address these issues.

Why not have a standardized suffix, prefix, or other URI transformation that allows one to derive from a resource URI another URI via which the resource description can be accessed?
Big no-no, but the iCite net will use the .icu suffix as a standard. This is only in the realm of file-oriented URI schemes like HTTP and FTP. I wasn't planning on there being a standard way to derive iCite URIs for protocols like POP or Jabber.

Why not first use a HEAD request to get another URI via which the description can be accessed?
A lot of the argument about not doing this in URIQA is because of the burden of giving every description its own URI. The iCite Container functions as a service specifically to grant every description its own URI, but I agree with the URIQA concern that using HEAD assumes too much about how servers (in my case, that are not iCite Containers) will respond to the request.

Why not use DDDS (DNS) to get another URI via which the description can be accessed?
CNS is the iCite net parallel to DNS, and it is specifically part of what allows each description to have its own URI. It is part of the lookup mechanism that can be used to map a resource URI to a corresponding iCite. The iCite Containers are (the distributed) part of the CNS system.

Why not use OPTIONS . . .?
Out of scope!

Anyway, this post was mostly meant to remind me to keep an eye on URIQA because it is considering and addressing important and similar issues to things I'm trying to build into the iCite net.