Chris Bizer wrote:
>>- I like the idea of lenses, and I would like (as a user of this vocab)
>>to be able to combine several lenses on a given (class of) resource(s),
>>especially considering that a cascading mechanism is considered.
>
>
> I clearly see the advantage of a cascading mechanism for display styles, but
> I think that cascading lenses are getting complicated for the user. What you
> are basically saying using a lens is: Display these properties in this
> order.
My mistake. I thought there could be some styling info associated with
lenses (don't kno where I took that from). In this context, I fully
agree with you.
>> > I was thinking the other night that even if not editable, the
>> > "dynamicity" of the presentation layer might be out of scope, but very
>> > important from a usability point of view.
>> >
>
>
> I think the question how dynamic the display is and which options are given
> to the user should depend on the specific browser implementation. Some might
> give plenty of options based on all lenses/styles they are finding somewhere
> on the Web. Others won't give any options and just render the data using a
> given set of lenses/styles. We should keep this in mind and stay general
> enough when writing the vocabs.
I understand what you are saying. Still, declaring in some manner what
to display at a given level of detail, e.g. by grouping lenses by
layer(s), sounds valuable to me. Mainly because this theoretically
provides a mean of having "relevant" filtering/grouping of data as
opposed to what a browser could do on its own (guess work, automatic
selection, or low-level/fine-grain selection by the user of what lenses
to use). I'm not sure I make myself clear here.
>> > For example: say I consider some properties primary and some others
>> > secondary and I would like to present them in a "click and show/click
>> > and hide" way (this is the usability model, the actual presentation is
>> > another concern), where does this fit?
>>
>>This is definitely important IMHO. Dynamic features like this can make
>>the representation much more easy to understand. Without going as far as
>>having a generic scripting language, the language could provide some
>>abstract (high-level) concepts such as layers. The stylesheet writer
>>would just specify on what layer a predicate should appear, and the user
>>could then select what layer(s) he wants to see.
>>
>
>
> I think this fits perfectly with the idea of lenses. The stylesheet/lens
> writer could specify one lens "FOAF person overview" and another lens "FOAF
> person details" which would include more predicates. He could then relate
> both lenses using for example
>
> ex:overviewLens disp:moreDetailedLens ex:detailsLens
>
> A browser could decide if he likes to use one or the other or provide
> drill-down functionality for the user.
Yes.
>>GSS offers a cascading mechanism, and I think this is a good thing to
>>have here too, one use case being people who want to override some style
>>settings made in a stylesheet applied upward (e.g. to increase
>>font-size). Conflict management between rules in GSS is as follows:
>>"As CSS, GSS supports the cascading of stylesheets. In case of conflict
>>between two rules belonging to different stylesheets, the rule in the
>>stylesheet applied last prevails. In case of conflict between two rules
>>belonging to the same stylesheet, the styling engine computes a weight
>>for the conflicting rules and selects the one with the heaviest weight
>>(a more specific rule will have a higher weight). If the weights are the
>>same, there is no guarantee on which rule will be selected." So this is
>>XSLT/XPath-like.
>>
>>One thing I have failed to evaluate from my quick look at the two
>>proposals is how expressive and easy-to-use are the selector languages,
>>i.e. the languages used to express constraints on resources and
>>properties the styling rules should be evaluated against. GSS offers a
>>fairly powerful selection language, but which has a major drawback: it
>>is difficult to understand and program with (not mentioning verbose).
>>This is probably partly due to the fact that it is expressed in RDF (all
>>GSS is RDF-based, with styling instruction values taken from CSS and
>>SVG). Some time ago, the idea of an XPath-like RDFPath language was
>>discussed on www-rdf-interest_at_w3.org, and several proposals have been
>>made. I intend to study those starting next month, as I would like to
>>rely on a more programmer-friendly selection mechanism for my next
>>attempt at styling RDF.
>>
>
>
> An XPath-like selector language sounds really interesting. I will also have
> a look.
Yes. This is something I am very interested in.
> I think our stylesheet and content-selection language should be RDF-based,
> but we surely can include other languages for certain tasks, as we are
> already doing with CSS and hooks.
I agree that the language should be RDF-based too. But if the selector
language becomes too complex/verbose in RDF, one thing that might be
considered is offering an alternative syntax (this has been done for
RELAX-NG, which has a std XML syntax and a compact syntax). This is not
something mandatory, but if we want a high level of expressiveness on
this side, there is a good chance we will end up with a complex/verbose
syntax in RDF/XML (probably less in N3, but will that be enough). I am
insisting on this because I consider this issue to be the weakest point
of GSS (that and the fact that the selector language is based on
something close to reification for expressing complex selection
constraints, which does not seem to be very user-friendly).
> We are having:
>
> A stylesheet language which:
> 1. is used for saying: Its a good idea to display foaf.depict as an image
> and a good idea to display foaf:name as text. Or this triple should be
> substituted by a specific graphic.
> 2. we use classic CSS for defining the display details like font-size ...
> 3. the css code is linked using hooks
> 4. the stylesheet language provides cascading mechanisms, so I can say:
> General rule "Display all properties as text", but display foaf:dipict as an
> image.
> 5. as selector language we might use RDFpath
Just so that there is no ambiguity here, I mentioned a discussion about
an XPath-like RDFPath language, but it does not yet exist. There have
been proposals in this direction, like RxPath, Versa, and others I don;t
remember (see discussion thread starting at [1]).
[1]
http://lists.w3.org/Archives/Public/www-rdf-interest/2003Oct/0126.html
>
> A content selection language which:
> 1. is used for grouping properties to lenses
> 2. order the properties
> 3. define alternative properties for missing values
> 4. define necessary bNode closures e.g. foaf:knows
> 5. might include terms for relating different lenses e.g. moreDetailedLens
From what you said earlier a cascading mechanism does not seem
appropriate here, and I agree. I think we misunderstood each other. When
I was speaking about cascading w.r.t to selection, I was not speaking
about the content-selection language, but rather the fact that the
selector language (as selectors in CSS) is involved in the cascading
mechanism in GSS. My point here is : I agree with your summary.
Emmanuel
>
> Different browsers that use these languages
> 1. will render different output ranging from RDF documents over SVGs to
> interactive websites.
> 2. decide which styles/lenses they are using and to which degree they leave
> the decision to the user, e.g. drill-down functionality or Mozilla like
> stylesheet switching.
> 3. Ignore terms in stylesheets that they don't understand, e.g. from
> different future style vocabs.
> 4. Some browsers might only use information from a fixed RDF store and a
> fixed set of stylesheets/lenses, others might search the web for additional
> information and additional stylesheets/lenses.
>
> Another question which came to my mind when looking at Haystack again: How
> do tables and thinks like photoalbums fit in our content-selection/style
> separation. It seam that you need a mixture of selection and style to
> define a table. Any ideas here?
>
> Chris
--
Emmanuel Pietriga
http://claribole.net
Received on Tue Sep 14 2004 - 07:06:07 EDT