Re: AW: still stuck on requirements

From: David R. Karger <karger_at_mit.edu>
Date: Fri, 20 May 2005 08:47:41 -0400

   Mailing-List: contact fresnel-dev-help_at_simile.mit.edu; run by ezmlm
   X-No-Archive: yes
   Reply-To: fresnel-dev_at_simile.mit.edu
   From: "Chris Bizer" <chris_at_bizer.de>
   Date: Fri, 20 May 2005 10:45:54 +0200
   X-Spam-Score: 2.318
   X-Spam-Level:
   X-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00,
           MSGID_FROM_MTA_HEADER autolearn=no version=2.63
   X-LocalTest: Local Origin



   Hi David,

>-----Ursprüngliche Nachricht-----
>Von: David R. Karger [mailto:karger_at_mit.edu]
>Gesendet: Freitag, 20. Mai 2005 07:27
>An: fresnel-dev_at_simile.mit.edu
>Betreff: still stuck on requirements
>
>
>I'm slowly catching up on this mailing list, and am seeing the
>discussion beginning to move towards specific questions of the lens
>and style vocabulary. I'm still stuck on some more basic questions.
>
>Chris uses the terms "selection" and "styling", but also argues for a
>device-independent notion of style. Let me take those terms
>literally, as sating that a set of lenses tells us _only_ what logical
>information needs to be conveyed to the user---ie, what properies and
>values. It is really just selecting a subset of the rdf. It says
>nothing about the way those properties and values should be presented.
>The "output" of a lens might just as well be an rdf graph, since that
>is as good a way as any of representing that logical information.
>

   In our current design, lenses not only select a subset of the graph but also
   transform this subset into a tree and order this tree. So maybe the term
   "selection" doesn't fit 100%.

   If lenses would do "pure selection" and their output could be a RDF model,
   then they would directly compete with SAPRQL and other RDF query languages,
   which would render them obsolete in my opinion.

Not necessarily. One could similarly argue that HTML is "obsolete"
because one can use java to render the pixels of the same page. We
don't make this argument, because it is convenient to have a domain
specific language for specifying in a cleaner fashion the subset of
rendering behaviors that we are interested in. Similarly, it would
not disturb me if everything we do with fresnel lenses could be done
with sparql, but the restricted domain of lenses made it easier for us
to express the specific queries we care about. As specific example,
writing down (and reading) a property set lens seems easier than doing
the same in sparql.

Also, the way that we bind specific lenses to be used in certain
circumstances is a different thing. It would be quite plausible for
lenses to have the form "for this type/purpose, use the following
sparql query to filter".

I am not asserting that we SHOULD switch to sparql for lenses, but
that we COULD and still have something meaningful. So our choice
(either way) needs justification.

>
>Styles are the first time that any thought arises about how that blob
>of selected statements should be presented to the user. It is then
>fair to ask, is there anything device independent about such
>presentation decisions? Arguably yes: we might want to make
>assertions about which resources or relations in the selected model
>are "central" and which are "peripheral".
>
>But the lens example below does not only select information to show;
>it also indicates structure-of-presentation, at least implicitly---ie,
>does lens below (taken from chris' email) demand implicitly that all
>the people this person knows should be shown together?

   Yes.

> Or is it a
>pure selection, that just says we should includes all the :knows
>statements in the selected submodel, but that a device might choose to
>display those knows relations in arbitrary ways?
>

   No. It says that they should be displayed together. Afterwards the device is
   free on how to display this hierarchical group of people (graph, boxes, any
   other way).

But note that eg a graph layout tool may not have a good way to
display those people "together". Or more generally, that a
hierarchical layout is overly restrictive for a tool that shows
arbitrary graphs.

>:personsKnowsLens rdf:type fresnel:Lens ;
>fresnel:lensDomain foaf:Person ;
>fresnel:showProperties ( foaf:firstname
> foaf:mbox
> foaf:depiction
> [ rdf:type fresnel:PropertyDetails ;
> fresnel:property foaf:knows ;
> fresnel:sublens :FriendLens ] ) .
>
>
>I guess another possible lens behavior might be to materialize a
>property that is not explicit in the data model. For example, one
>could a imagine a lens deriving "grandchildren" of a person by
>squaring the child relation, and shipping an rdf model containing
>grandchild assertions, even though the original data model contains no
>grandchild property. Or, should we require that the lens _only_
>filters and does not create new statements?

   It would be possible to materialize additional statements using lenses, but
   we ruled this feature out of scope because we agreed that this is a job for
   the inference layer.

But if the inference layer does it then it becomes part of the data
model. And maybe we don't want the changes in the data model.
Example: maybe we want to materialize a "collection of authors" of a
given paper for the purposes of viewing, but in the data model we
don't want that collection; we instead want each author individually
attached by an author statement.
Received on Fri May 20 2005 - 12:46:13 EDT