Re: Another suggestion & a question for Eric Miller (Was RDF Display Vocabulary Second Draft)

From: David R. Karger <karger_at_mit.edu>
Date: Tue, 12 Oct 2004 14:55:32 -0400

I've started looking at the n3. I'm sending issues piecemeal.

I wanted to compare the fresnel approach to some haystack ideas.
These are approximately what haystack actually does, although in some
cases I am engaged in wishful thinking.

In haystack, there are two distinct but related concepts; a "viewPart"
is a general widget responsible for presentation of some information,
while a "property-set lens" is more in line with what's being
discussed right now---a list of properties to be displayed. It is a
particular type of "lens", which in haystack is something that
displays some _possibly noncomprehensive_ aspect of the object. So,
for example, we might have a lens for people that shows all the papers
published by the person. Such a lens is certainly useful information
_about_ the person, but does not serve as a particular good
representation/view _of_ the person.

So our notion of lens is in a sense a composition of an "aspect" (some
function of the underlying object, often returning a list of value)
fed into a "view" (of the result of that function). A property-set
lens produces as its aspect a list of desired (property, value) pairs
of the given object and feeds that to a view that knows how display a
list of pairs.

Since lenses show _aspects_ of an object, it is generally desirable to
show a lot more than one lens. Haystack never presents a single lens
for an object---rather, it presents a single _view_ for the object.
One of the view is the "metadata view", which shows a canvas with
_all_ the "relevant" lenses for the object, each in its own box with
its own expand/close tab. What does relevant mean? Well, most
obviously the lens gets associated to a certain class. However, we
have also just scratched the surface of "context"---certain lenses
that only show up depending on what you are doing. For example, there
is a lens showing a list of categories to which you can assign the
given object, which is only visible when you are performing the
"organize my stuff" task. A help lens shows help about the object,
but only when you want help. As another use of context, we also
annotate our views with how much space they need, as this is often the
determining factor in which view is appropriate for the given object
in a given context. We haven't gotten around to doing the same for
lenses: we show all, regardless of size, in the metadata view canvas.
This is due to unplanned evolution.

I'm not certain the distinction between "view" and "lens" can really
be formalized---obviously, every view is only showing some aspect of
the object. But there do seem to be very different ends to the
spectrum, that perhaps need to be handled differently?
In particular, note that the current fresnel idea of a lens is, like
haystack's, a combination of "aspect" (choosing the properties) and
"view" (choosing the presentation of the resulting property/value
list). If we really wanted to limit fresnel to the presentation
layer, we should be thinking about factoring away the "aspect" portion
to be handled elsewhere.

As another thought experiment, note that the current approach only
lets me select actual (materialized) properties of the object. But
sometimes, we might want to show a _derived_ property. Eg, suppose I
am looking at a person and want to show the weather where they live?
There is unlikely to be a "weather where they live" property; however,
there is probably an address property that, when composed with a
weather property, yields what we want to show. Do we handle this:
  1. At the data layer, requiring the data model to materialize the
     "weather where they live" property so it can be shown? It seems
     questionable that we want to materialize properties that are used
     for such a special purpose.
  2. Extend the property lenses to allow arbitrary, more complex
      queries against the data model? This seems to blur the separation
      between data and presentation.
  3. Use a "hack" that exploits the view architecture: declare that
      to show the person, we want to show the value of the address
      property, but somehow specify that when showing the address, we
      should show a "weather there" view of the address?
      (Weather-there can't be implemented as a lens, but it can be
      implemented as a haystack view). This approach achieves
      composition in the data model by exploiting the recursive
      structure of the views, but seems like cheating/fragile?

Separately, I think there is a lot of power to having a "view of
views" that lets users see and select from the entire pool of
available lenses of the object.
Received on Tue Oct 12 2004 - 18:55:34 EDT