2004-05-02 Interconnected URI rationale I think there's a kind of syntax to the uri. http://example.org/one/two/?a=1&b=2 *says* something, doesn't it? There's a hierarchy, then a bag of parameters. So my feeling is that if the parameters are POSTed, that's fine, the uri is like a wormhole that takes the parameters and sends you off somewhere else. But if it's a GET, and the parameters are on the end of the uri, that should just locally modify whatever content you're getting back. The problem is that RSS or Atom or whatever other skin -- they're not just different representations, and they're not just transitory, so I don't want to put skin=rss in the query string. That's now for things like show_test_header or expand_comments or whatever (I don't actually use anything at the moment). But putting rss in the hierarchy doesn't work: /home/rss/ /home/2004/04/week/02/week/rss/ /home/2004/04/02/rss/ It's not a level deeper! It's a valid alternative to /home/ or /home/2004/04/02/ which is not a subset of the html representation. Plus, and this is more important, it's the same "rss" in all cases. Because it's under /home/, the same rules for how the rss works apply. Yknow, the same content encoding, the same interlinking. All the rss feeds apply to the same bag of stuff (only the latest rss feed is live at the moment, but only because I haven't got round to writing the redirect rules yet). TBL wrote a doc in 1996 about Matrix URIs, I kind of had that in mind when using the semicolon, but also that the semicolon has enough weight to hold its own against the slash, and you can read the uri with the "rss" as a separate clause: /home/;rss /home/2004/04/week/02;rss /home/2004/04/02/;rss "rss" is an axis, and it's the same axis that crosses everything. I have a 2 dimensional space: the first space is a hierarchy (date) and the second is a skin. Then query string parameters will modify the actual document at that location. It gets a bit more complicated for the mini links rooted at http://interconnected.org/home/mini/ -- the rss is still there: http://interconnected.org/home/mini/;rss http://interconnected.org/home/mini/2004/04/;rss I also wanted some way to filter the hierarchy by tag. Each entry in the links database can have any number of tags, and (for my internal system especially) I filter by "and" (+), "or" (,) and "not" (!). But, reading the uri left to right, that filter can't follow the ;rss. The rss feed (and the html too actually) is limited to a certain number of items. It would feel backwards to select the items based on the date, make a 30 item rss feed, *then* to filter it. No, the tags come at the bottom of the date hierarchy. I use "_" to separate them, because the tags are virtual filenames. Filenames are words (there aren't any yet, but there might be) and "_" denote smart filenames. The and/or/not is its own minilanguage: /home/mini/_timebank+!shirky;rss /home/mini/2003/12/_timebank,glancing;rss I could've made the tags another matrix axis, but that didn't seem quite right somehow: they're used in specifying the items to be shown. Again, query strings would be used here for user actions, things which pervade the entire system. Like page: /home/mini/_timebank+!shirky;rss?p=2 It's kind of like a clarification, I think. Start at the root, go down to date, use the tags as a pruning algorithm, move along the representation axis to rss, then the system asks you for clarification because given what you've said and how many items fit into an rss feed and so on, so you say page 2. Signifying a resource to retrieve a representation of isn't a matter of drilling down in a hierarchy, or triangulating it in some n-dimensional matrix. There's a structure to the document space with hierarchies in some places, strict axis in another. Different spaces afford different ways of navigating. The uri should represent that space (and the constraints and the incentives) *virtually* such that constructing one (and seeing what parts have to have order, which parts are optional, which are persistent across different uris) is not like just issuing an imperitive to the webserver ("give me this!") but like having a conversation with it. A carpentry rather than industrial approach, letting the user get the feel of and work with the material. I hope I've managed to make a uri which makes some kind of sense when read out. Possibly.