Re-design the application's URL space

[cygri]

The current design of the URI space is pretty bad and really should be re-done. Examples of problems:

• Can't have resources with /data/ in certain places in the URI.
• Formats cannot be indicated through something that looks like a file extension, but has to be done via ?output=xxx and that's just ugly.
• 303 and content negotiation is done at the same place, rather than 303-redirecting to a generic resource which then replies according to accept header

New URI space structure

A resource hosted by Pubby, 303-redirects to /!about/resouce-id:

/resource-id

The information resource describing such a resource. First one does content negotiation, the others are format-specific variants:

/!about/resource-id
/!about.ttl/resource-id
/!about.html/resource-id

For everything except the 303-redirecting resource handler, instead of the relative URI resource-id we could have an absolute one, to support browsing resources not hosted by Pubby:

/!about/http://example/resource-id
/!about.ttl/http://example/resource-id
/!about.html/http://example/resource-id

Value pages, showing the values of a property on a certain resource, with possibility to invert the direction to show incoming arcs (/i/). Again, there is a content negotiated resource and then format specific variants.

/!values/ex:prefixed/resource-id
/!values/i/ex:prefixed/resource-id
/!values.ttl/ex:prefixed/resource-id
/!values.ttl/i/ex:prefixed/resource-id

Again, the resource can be identified via full URI:

/!values/ex:prefixed/http://example/resource-id

We need a way of doing these value pages even if no prefix is declared for ex. The challenge is to find a way of indicating where the property URI ends and the resource identifier part starts. This could be done in a number of ways. (1) encoding the length of the URI in the address; (2) %-encoding the entire property URI; (3) using a delimiter such as /// that is unlikely to occur in a property URI.

/!values/33/http://vocab.example.com/ns%23foo/resource-id
/!values/http://vocab.example.com/ns%23foo///resource-id

Finally, the “home” resource will be 302-redirected to conf:indexResource if that is defined:

/ 

Implementation

Do our own URL routing. Let RootServlet handle the entire URI space except for /static/. Then pull all the logic of creating or interpreting URIs from the various places (HypermediaControls, servlets, web.xml) into a single class. There could actually be multiple versions of that class, like a legacy URI router that implements the “old” behaviour.