Emmanuel Pietriga wrote:
> Chris Bizer wrote:
>
>>>> Disadvantages
>>>> - Less expressive.
>>>
>>>
>>> Why is it less expressive? not trying to be dense, just curious.
>>>
>>
>>
>> Please express "Display all person that know more than 30 other persons
>> using a special color" with a CSS selector ;-)
>
>
> That's the kind of thing I was refering to in our off-list discussion
> about the intermediate tree being "far" from the source data we are
> actually interested in visualizing (meaning that selectors such as the
> one you mention here, even if they can be expressed, will seem more
> abstract, I mean "far" from the source RDF data). But that is of course
> not a reason to stop investigating this. There are many advantages to
> this approach.
>
> And we could always replace CSS selectors by XPath expressions (just
> kidding...)
>
>> Emmanuel, what do you think?
>> Would something like this fit into IsaViz?
>
>
> I guess it would. Actually, you could say that as long as you are able
> to get some SVG rendering of this tree, it fits into IsaViz. But that
> does not really answer the question. More precisely, the question
> becomes: would something like this, which obvisouly fits well into
> XHTML+CSS (nested box model), also fit well into SVG (which has no
> predefined representation model)?
>
> We are not really making any assumption on how to present the data,
> except for the fact that we now have a more explicitly hierarchical
> structure which has a fairly obvious mapping to an XHTML structure. But
> there are different ways of representing a hierarchical structure. So my
> a priori answer to the question is "yes, it should fit well, we only
> have to find an appropriate representation of such trees in SVG/IsaViz".
> By appropriate I mean something different from what an XHTML version
> would look like. There is no point in doing the same rendering as XHTML
> but in SVG. Actually, this idea of finding this appropriate SVG
> representation is very interesting.
>
> I am willing to go in this direction.
Keep in mind that once we have this XML output, not only we reuse CSS in
a more complete way, but we also enter the XML world too, where
pipelines and transformations are a first class citizen.
The world of presentation interfaces is based on trees, there is not a
single one based on graphs (also because nesting and containments are a
natural thing in a tree, but totally unnatural in a graph).
At the same time, having a graph as a data structure is a major win too,
is bridging the two that is hard and knowing where to draw that line.
But people are just not going to stop using the technologies they are
used to and that work well for them just because we say so, especially
if we don't give them any advantage over what they already have.
Another approach I thought is to allow people to use whatever stylesheet
language they want: they can associate a CSS stylesheet with a lens
group or they can associate an XSLT stylesheet with that (which might
contain inside CSS instructions too!)
That would allow us not only to avoid thinking about style and reuse
what other people do (and still allow fresnel lenses to be portable!),
but also avoid taking sides in the CSS vs. XSLT battle of titans (which
is not an easy one).
What do you think?
--
Stefano Mazzocchi
Research Scientist Digital Libraries Research Group
Massachusetts Institute of Technology location: E25-131C
77 Massachusetts Ave telephone: +1 (617) 253-1096
Cambridge, MA 02139-4307 email: stefanom at mit . edu
-------------------------------------------------------------------
Received on Mon Mar 21 2005 - 18:32:54 EST