Jacco, Lloyd,
thank you very much for your feedback, this is very useful.
> - You can have multiple matching lens or style definitions, as in CSS
> or XSLT. It seems like the rules for conflict resolution are still
> under specified at the moment.
I personally feel that the style part is just going to slowly reinvent a
lot of wheels. I hope one day, to be able to convince my colleagues that
the style part of fresnel is not that useful, but that seems to be a
lost battle for now, so I love the new ammunitions you are giving me ;-)
> - I'm not quite sure I like the idea that the order is determined by
> the lens, and not by the style, but I've no strong feelings about
> that.
Hmmm, this is a good point.
> - I'm not quite sure I like the behavior of alternateProperties. In
> our experience with noadster, sometimes dc:title and rdfs:label have
> the same value, and you want to show only one of them, while in other
> cases they have different values and you want to show both. It is
> also not clear to me how you specify which property label to display
> (e.g that of dc:title, of rdfs:label or both).
this goes back to the styling issue: I think that fresnel should be a
bridge between a graph and a tree... and once you are in 'tree world'
you can use whatever you want to present that, as there are many
technologies and best practices already.
> - Related issue: we had many cases in which we wanted to display
> multi-valued properties in a single box (e.g. I have multiple
> foaf:projects that I wanted to display as a comma-separated list in a
> single box. You seem to cater for this (I assume this from the
> existence of contentAfter etc), but I do not see how you control the
> formation of boxes in the box model to deal with this.
Yes, I brought this up as well: I dislike very much the notion of an
'implicity layout' because it reduces the view portability.
My suggestion was to use "table-cell" CSS display properties to describe
the layout, but it was turned down because a 'table-cell' doesn't fit in
the IsaViz paradigm.
So, even if label is on the left and values are on the right as an
implicit assumption (which I hate, but let's assume that), how do you,
for example, specify a border on the left side of *all* the values?
I personally think that the output of the fresnel selection should be
somethink like a tree of <div> with special classes and *NO* implicit
layout whatsoever.
We still have to reach consensus on all that, and being *the* critical
piece of the whole research, it feels kinda wrong to rush the whole thing.
> - I find the whole box model still a bit under specified. I've also
> questions about the general applicability of the box model --- isn't
> it a bit Longwell-specific? How would an application such as IsaViz
> use the box model?
This, to me, is the tip of a huge iceberg: currently, all we can do is
to select the font and the color of things, since even borders, padding,
margins, etc, lose meaning (or change it!) in a vector canvas like
IsaViz or Welkin.
One of the requirements was that Fresnel should be 'browser independent'
and achieve complete 'view portability' across browsers, well, I
personally feel we pretty much failed on that as the only portability we
achieve is minimal and pretty soon we'll have to 'tag' views with the
types of browsers that support them, and at that point, the style part
will feel like an obstacle rather than a help (to me, it already does!)
> - Interoperability: would it be possible to use the lens processor of
> one fresnel tool and combine it with the style processor of another
> tool? If so, you need to be very specific about what is the result of
> applying a set of lenses. I vaguely remember reading that the result
> is an ordered RDF-graph, but that may need some more specification
> too.
We did have a intense discussion about the introduction of an
'intermediate representation' between the selection part and the style part.
DavidK and I are all for it, Chris is strongly opposed since he feels
this is unnecessary as it's an implementation detail.
As I said above, the part that is really missing in the RDF presentation
space is not lack of activity in the style/presentation of markup, but
it's the bridge between graphs and trees.
Having the intermediate representation explicit would allow people that
don't care/need view portability to just focus on the selection part
(which is way easier to implement, also), moreover, as you mention
above, it would allow people to "reuse" existing fresnel style processors.
I'm very much in favor of this.
> - You talk about displaying RDF, while in fact you mean RDFS. The
> vocabulary even states it is "ontology centric". Maybe you want to make
> sure
> there is some default lens/style that allows flat, class-less untyped
> RDF triples
> to be displayed properly? (see noadster for an example).
Well, I don't see anything in the selectors that stops you from
selecting things like you want. Just like it's easier to get access to
an DOM node if it has an ID, it's easier to select an RDF node if it's
typed, but I don't think this is a really a constraint.
> -----Ursprüngliche Nachricht-----
> Von: Jacco van Ossenbruggen [mailto:Jacco.van.Ossenbruggen_at_cwi.nl]
> Gesendet: Donnerstag, 21. April 2005 19:16
> An: chris_at_bizer.de
> Cc: lloyd.rutledge_at_cwi.nl
> Betreff: Comments on Fresnel and your ISWC draft (part II)
>
> About the paper (please do not feel offended!):
[snip *lots* of very valuable points!]
[Chris, now you understand why you want to do things in the open! :-)]
I'll come back to these points later.
--
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 Fri Apr 22 2005 - 13:34:15 EDT