the iCite net > news / blog > a permalink

news and thoughts on and around the development of the iCite net
by Jay Fienberg

Getting descriptions and the URI Query Agent (URIQA) Model

posted: May 6, 2004 8:09:39 PM

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".

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.

permalink | comments {0} · trackbacks {0}

also available as: rss · rss2 · rdf · atom

Comments and Tracbacks

Note: All comments and trackbacks are moderated. Spam is deleted. Other comments are approved as promptly as possible.

Note: Older posts no longer accept new comments or trackbacks.

« prev post
Simple suggestion for pDNS and FOAF (based on CNS)

» next post
Gallery opening for Anastasia's photography (in SF = you're invited)

blog newsfeeds

brief content:

 XML  ·  RSS  ·  RDF  ·  Atom 

full content:

 XML  ·  RSS  ·  RDF  ·  Atom 

blog archive

jan · feb · mar · apr
may · jun · jul · aug 
sep · oct · nov · dec
jan · feb · mar · apr
may · jun · jul · aug
sep · oct · nov · dec

jan · feb · mar · apr
may · jun · jul · aug
sep · oct · nov · dec

may · jun · jul · aug
sep · oct · nov · dec

first post: 
April 30, 2003

highlight views:
Spammers' Choice

Jay elsewhere online
Jay Fienberg - the official home page

Wrong Notes - the music blog of the Ear Reverends

Fine & Full, aka, a fine and full burger

Sociomobilepoetextologia (moblog, currently inactive due to lack of proper mobile)

to enjoy roll
sites I like to read when I start from here

· Anastasia Fuller
· Andy Baio
· Biz Stone
· Boris Mann
· Bre Pettis
· Chris Dent
· Danny Ayers
· Dare Obasanjo
· David Czarnecki
· David Weinberger
· Don Park
· Evan Williams
· Greg Narain
· Jason Kottke
· Jim Benson
· Lucas Gonze
· Marc Canter
· Matt May
· Matt Mullenweg
· Michal Migurski
· Nancy White
· Rebecca Blood
· Reg Cheramy
· Richard MacManus
· Sam Ruby
· Shelley Powers
· Tim Bray
· danah boyd

powered by blojsom

Entries by blojsim