If I was given the task to come up with a way to present an RDF model,
how would I do it?
Let's look at existing technologies:
RDF/XML + CSS -> terrible mix because CSS cannot alter the DOM
structure and RDF/XML has inherently poor (and uncanonicalized!) tree
structure. Even if we canonicalized RDF/XML (work that would have to be
done for any kind of RDF digital signing anyway), the inability to alter
the original tree would be insufficient for meeting flexibility
requirements in presentation.
RDF/XML + XSLT -> better mix because XSLT can alter the DOM structure
but still hard to write the XSLT if the RDF/XML is not canonicalized.
Also, requires a different transformation per rendering channel and
style information has to be copied.
RDF/XML + XSLT + CSS -> better than the above since the styling
instructions can now move into CSS and be reused more easily across channels
NOTE: XML+XSLT+CSS are currently the state of the art of XML presentation.
Problem with this approach for RDF:
1) acting on the 'XML serialization' instead that on the RDF model
feels wrong, therefore writing the XSLT feels unnecessarely complex.
2) lack of canonicalization of RDF/XML makes the xpaths in the xslt
stylesheet very verbose and hard to decypher, this is a result of #1
3) xslt is a very effective hybrid procedural/declarative tree
transformation language trapped in the wrong name and in the wrong
syntax for the wrong reason (transforming xslt with xslt looks appealing
but in the real world nobody uses it). as a result, it's terribly hard
to market it in the real world because it appeals designers because of
the name and the syntax but repels them because of the semantics, it
repels procedural programmers because of the recursive declarativity
(they want explicit iteration loops) and it repels functional
programmers (more used to recursive declarativity) because of the syntax
and the name.
4) real-world xslt reusability is close to zero, feels like a write
once scripting language. XSLT 2.0 improves things but nobody supports it
(not yet recommended) and it increased its complexity 10 times for a
very marginal increase in appeal.
I believe that RDF presentation should follow the XML experience but
keep an eye on the differences:
graph -> graph transformer -> graph/tree bridge -> declarative styles
^ ^ ^
| | |
transformation/query bridging styling
rules/instructions instructions instructions
Entering Fresnel
----------------
Fresnel currently covers the last two phases: the bridging instructions
are the lenses and the styling instructions are the styles.
But there are two possible scenarios here:
1) fresnel is a bridge between an RDF model and an *existing* XML
vocabulary
2) fresnel is a bridge between an RDF model and a tree model that
contains styling instructions
at the implementation level things are very different: the first is
basically a tranformation between a graph and a tree and the problem of
styling goes back in being the problem of styling that XML vocabulary.
the second requires a fresnel processor to process both bridging and
styling instructions and output an existing XML vocabulary and its
styling instructions.
Fresnel is designed as an instance of the second scenario and the reason
for that is that one of the requirements was to be able to allow fresnel
clients to discover and download 'views' of RDF data they did not
understand how to present.
This means that those fresnel views should contain enough information
for the client to be able to visualize the 'presented RDF model' by
itself (for example, in a single-stage fresnel client like Haystack) or
generate XML+CSS information and send that back to the client (for
example, in a two-stages fresnel client like Longwell).
The problem with this approach is that fresnel views have to contain
both the bridging instructions and the styling instructions. In order to
avoid reinventing yet another styling wheel, we agreed to reuse the CSS
styling vocabulary (plus SVG extensions).
- o -
Now, one of the questions on the table was whether or not to embed the
CSS information inside or outside the fresnel RDF model and whether or
not to encode that in RDF directly.
We decided not to encode CSS in RDF because it made it very verbose and
added very little functionality (and it felt like one of those example
of 'golden hammer' antipattern).
But the question now is another one: should we embed CSS instructions
'inside' the fresnel styles or just 'name' the lenses and let CSS use
its own selectors to get to those?
In theory, since lenses output is always a tree, there is no need to use
a graph-capable selection language at that point, CSS selectors would
work just fine.
As for view portability, the lens groups could identify the URI of the
associated CSS file that would work on that group... and normal CSS
specificity algorithm would work for cascading and all that.
Now, if we allow this separation, the lenses have to be somehow "named"
or 'classified' for the CSS selectors to be able to work on them. The
temptation at this step is to create a controlled vocabulary for those
'classes' of lenses.
I strongly warn against this temptation: it is true that without a
defined controlled vocabulary for classes the reusability of the CSS
file would be zero, because those classes are just locally defined hooks
between the fresnel lenses and the associated CSS style.
But this is not different from what happens in XHTML+CSS today: XHTML
provides a 'controlled vocabulary' yet the real-world 'reusability' of
CSS stylesheets is of marginal imporance, at best: people far prefer to
'pick cherries' and cut/paste parts of existing stylesheets that are
useful for them in their own CSS stylesheet. Controlling the lens class
vocabulary in Fresnel would just consume more effort than its worth.
But I do advocate that we should aim at a clearer separation between
Fresnel and CSS, allowing lenses to be 'classified' and CSS selectors to
work on those lenses, instead of using fresnel selectors for selection
and embedding CSS instructions in the fresnel model directly as we do today.
I believe the biggest mistake we made was to consider the output of a
lens an RDF model (a tree encoded in a graph with explicit names of
relationships) instead of thinking of it as an XML model (a tree encoded
in a tree-oriented structure with implicit nesting relationships). This
creates unnecessary complexity to the 'style' part of fresnel and for no
benefit.
Comments?
--
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 Sun Mar 20 2005 - 17:35:24 EST