David R. Karger wrote:
> >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.
SPARQL is one of the three possible selection languages (along with FSL
and its subset called "simple RDF naming") used to express lens domains.
Are yo considering the use of SPARQL here in a different way?
> >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).
Yes, that is what we had in mind.
> 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.
Styling information in Fresnel, according to the presentation model
called the box model, is to be "interpreted" by each application
according to its underlying representation model. Applications are free
to interpret and/or ignore styling instructions depending on their
relevance w.r.t the representation model.
People disagree about the usefulness of such a model.
--
Emmanuel Pietriga
INRIA Futurs - Projet In Situ tel : +33 1 69 15 34 66
Bat 490, Université Paris-Sud fax : +33 1 69 15 65 86
91405 ORSAY Cedex FRANCE http://www.lri.fr/~pietriga
Received on Fri May 20 2005 - 15:09:31 EDT