Chris Bizer wrote:
> Hi Stefano,
>
> some short thoughts. I will answer your mail in detail next week.
>
> First, I agree
> - that I'm a golden hammer freak
LOL. Dude, I think you are not: the first sin of golden hammer freaks is
that they never recognize that they are (been there myself) ;-)
> - that Velocity is a great tool.
It took me years to realize that: I used to be on the camp of those who
believed that template information should have been part of markup
language in another namespace.
> I think there is a need for a "natively RDF friendly" template language
Definately agreed. As long as all of us are cautious about the 'golden
hammer antipattern' of the abuse of the RDF model for the description of
RDF data selection and presentation, I'm fine.
> and I will try to argue for an 3-layer architecture which could look the
> following:
hmmm, interesting:
> 1. Layer: Stylesheet language
>
> A purely declarative stylesheet language in which you say that it's a
> good idea to display foaf:name as text and foaf:depict as a picture and
> dc:description as multiline text. If you want to define further display
> details like fonts and colors you use a RDF-version of CSS. An example
> style might look like this:
>
> foaf:mbox rdf:type rdf:property ;
> style:hasStyle ex:boldRedLink .
>
> ex:boldRedLink rdf:type disp:DisplayStyle ;
> style:displayType style:Text ;
> style:style disp:ShowURI ;
> style:style disp:DisplayAsLink
> css:font css:SansSeriv ;
> css:color css:red .
>
> You see the golden hammer but no reinvention of the wheel, because the
> semantics of CSS are reused :-)
The idea of encoding the CSS semantics into RDF still smells like golden
hammer to me. I mean, CSS has pretty powerful selectors, but admittedly
they are XML-oriented and not RDF related... I wonder, since
"presentation" means transforming into presentation-oriented markup
(XHTML, SVG or XSL:FO) and CSS can be used directly in all of them
(well, not really in FO, but that is a classic reinvention of the
wheel), why don't we introduce CSS-selector-friendly "hooks" (ids or
classes) instead of describing the style info itself in RDF?
less work and a lot more friendly with existing CSS-creating tools.
> 2. Layer: Content-selection language
>
> Where you group properties together to views/lenses, order them and say
> how missing values are handled.
>
> ex:viewof fofPerson rdf:type disp:Lens ;
> rdfs:label "Lens for FOAF Persons" ;
> disp:useableFor foaf:Person ;
> disp:showProperties [ rdf:type rdf:Seq ;
> rdf:_1 rdf:type;
> rdf:_2 foaf:mbox;
> # Use alternative properties if
> foaf:name is missing
> rdf:_3 [ rdf:type disp:PropertySeq ;
> rdf:_1 foaf:name ;
> rdf:_2 foaf:surname ;
> rdf:_3 rdfs:label; ] ] .
Nice. Implicit conditionals, I like.
> 3. Layer: Template engine
>
> Which uses existing template engines (e.g. Velocity) to render the
> final output and add static stuff like headers and footers and
> navigation elements. The engine also chooses which lens or combination
> of lenses is used and which style is used if there are several
> (both fixed in the template or interactively chosen by the user)
Awesome.
> The potential advantages this architecture are:
>
> + You have a fully declarative style language which sperates style from
> content-selection.
I'm not sure if CSS is enough for what we need (the 'display' property
is already very powerful... but here you guys have a better
understanding of what we need and its potential limitations), but if
it's not, I would like to just use the CSS syntax and not another one.
> + You can use a lens to render different output formats (HTML, SVG),
> which you can't if you do the content selection in a Velocity template,
> which is allways bond to one output format (right?).
well, yes and no. for example, if your publishing system is
pipeline-based (as in cocoon, for example, and I plan to port Longwell
on top of cocoon since Longwell will be used for DSpace 2.0 which will
be based on cocoon) you can use the template system for the
"generation-phase" while you can adapt it other means with the
transformation phase.
In any case, I agree that it's better to have format-oriented
content-selection at the generation phase rather than at the
transformation phase (but here, not all cocoon users agree with me, as,
in fact, there are benefits in the other approach too, so normally you
end up using a mix of the two).
> + Lenses are expressed using RDF, which means that you can reuse/move
> around/publish them much better on the Web than Velocity templates.
well, as devil's advocate I could argue that velocity is used today more
than RDF, so it would be the opposite, but I see your point and I agree
that it's more elegant that way since lenses are declarative units of
data aggregation and do feel like natural meta-metadata.
> + Styles and Lenses are interactively combinable, which is an advantage
> if you are not only thinking about a domain-specific semantic portal,
> but about a more generic semantic web browser, who when finding a class
> he doesn't know anything about, starts to search the Web for Styles and
> Lenses to display the class.
Yes, this is the real advantage and I completely agree.
--
Stefano.
Received on Sun Sep 05 2004 - 16:59:33 EDT