Re: RDF Display Vocabulary

From: Emmanuel Pietriga <epietriga_at_yahoo.fr>
Date: Mon, 13 Sep 2004 17:28:25 +0200

Hello all,

Here are a few comments I have, based on my experience with GSS and
feedback I've got from its users.

First some general thoughts:
- 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. This
could be managed at a fine-grain level, conflicts between lenses being
resolved through well-known mechanisms (e.g. by computing the weight
associated with the different lenses ; that's what I do with GSS rules,
and it is being used in CSS, XPath+XSLT).

- on the "hooks vs. rdf-syntax" issue I am for hooks too, especially for
the user-friendliness of it.


- more inline comments follow.


> 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.
>
> 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.




> 2. Filtering
> >
> > There can be an overbundance of data that is not useful to users in a
> > dataset. The ontology must provide a way to filter out extraneous or
> > user-irrelevant data for presentation. Mechanisms that work on
> > explicitly showing or explicitly hiding specific resources should be
> > provided.
> >
>
> Yes, and we should also deal with the case of different filters for one
> class.
> People might want to display different aspects of a resource, e.g.
only the
> work related information about a person or information concerning certain
> activities. The different filters could interactively be chosen in the
> browser
> (Haystack lenses) or set in the browser configuration. We should also
think
> about different people providing filters for the same class.


Filtering is obviously very important, but another related issue is how
you will be able to convey/encode some data in a more user-friendly manner.

One basic example is removing rdf:type information for resources, but
changing those resources' appearance (e.g. the GSS stylesheet for foaf
[1] removes rdf:type statements pointing to foaf:Person and changes the
subjects' appearance from a std resource - green ellipse - to a bitmap
icon representing a man ; it does the same thing for foaf:Organization,
etc., and this greatly improves the graph's readability).

[1] http://www.w3.org/2001/11/IsaViz/gss/gssmanual.html#example

 From what I've understood of the two proposals, this seems to be
achievable, right (e.g. using dsp:AsSubstitution) ?





> 3. Relational Specification
> >
> > The form of a triple - particularly the predicate portion of a
triple -
> > may be better expressed in ways other than a plain text label,
such as a
> > node-and-arc or containment layout. Terms for expressing different
> > relationships for particular predicates should be provided.
> >
>
> Yes.

Definitely. The default behaviour of GSS is to show relationships as
nodes and arcs. But some (or all) properties associated with a given
resource can be grouped in a table (and sorted). Another alternative
would be to embed this table in the subject resource's "node" (right
now, it is outside the subject, with an unnamed link between the subject
and the resource). Being able to actually nest table inside one another
would be nice too (it could also be interesting to apply semantic
zooming here, in the context of a ZUI, e.g. to provide basic info about
an object at high altitude and provide the user with more info when
going down).




>
> 4. Representation
> >
> > Certain types of data are better represented graphically or in some
> > manner other than plain text, and certain classes of data are better
> > summarized by using something other than its label or title.
Mechanisms
> > for specifying alternate expressions of a triple, perhaps by
> > substituting graphics or the like, should be provided.
> >
>
> Yes, definitively.

Agreed (related to what I said in 2. above)




> 5. Granularity
> >
> > The scope of action for certain mechanisms should be applicable at the
> > broadest level, for every resource in a dataset, and the most specific
> > level, for specific subject - property - object combinations. These
> > mechanisms include filtering, relational specification, and
> representation.
> >
>
> Yes, didn't think about this yet. Which will mean that we end up with
> cascading RDF style sheets (CRSS :-)

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.





> # -----------------------------------------------
> # 2. Use Cases
> # -----------------------------------------------

> (like LongWell, Haystack, AnSeB) using different application-specific
> ontologies and
> multiple sets of style sheets provided by different authors.

A good and clearly-defined cascading mechanism might do part of the job
here, with one stylesheet for each vocabulary. This clearly does not
cover all the needs however...


Emmanuel
-- 
Emmanuel Pietriga (epietriga_at_nuxeo.com)
http://claribole.net
Received on Mon Sep 13 2004 - 15:28:31 EDT

This archive was generated by hypermail 2.3.0 : Thu Aug 09 2012 - 16:39:17 EDT