I'd like to take advantage of this discussion to propose a different
point of view to analyze the various aspects being discussed, which is
the one we have been adopting in our work on Web application design
methods for more than 10 years now, even before the Semantic Web.
I will try to be very brief, giving pointers to more detailed arguments
A web application (semantic or not...) is seen as a way for a user
(later this could be substituted by agent) to manipulate "information
items" in order to perform a task. These information items may be based
(but are typically NOT the same as) from data that is stored in some
database or repository; rather, they are normally "views" (similar to
DB views) over some information domain. These views are defined
depending on the particular set of tasks being supported. One of the
primary modes to access these information items is through navigation,
which therefore (and for other reasons, see  merit its own separate
model. This model is still "abstract", in the sense that it provides a
navigation topology for users to navigate through items as their task
requires. Furthermore, this is *independent* of particular interface
models. In other words, the same navigation topology may be supported
by several alternative interfaces (ie, layouts, widgets and operations).
A separate concern is, given a particular topology, what is a good
interface design to allow the user to navigate in it.
I have the impression that much of the discussion in this thread has
mixed the two aspects, and it might be useful to separate them.
As part of this research, the notion of "set-based navigation" has been
proposed as a design pattern already back in 1997 (see references in
). In particular, the SHDM method has incorporated them as design
primitives, which are supported in the HyperDE environment ([3,4]),
which provides a language to specify these navigations structures in a
concise way, and to generate running code. (It is a based on Ruby on
Rails, but uses RDF instead of relational data). Many of the tasks
described in the example could be supported with a navigation model
directly supported by the method, but with a different interface. And,
could also provide the access to the data itself as Kingsley advocates.
The work in these publications does not address so much the INTERFACE
aspects of the discussion (actually there are some, but this would be a
whole separate discussion). I believe David's contributions are
directly applicable at the
interface level, regardless of the underlying navigation model, and
could be incorporated into the method.
We are also currently working on this part and we should have an
alternative model and prototype to show very soon.