Re: Display requirements - style vs. template oriented language

From: Chris Bizer <chris_at_bizer.de>
Date: Tue, 7 Sep 2004 16:12:33 +0200

Hi Stefano and Ryan,

it seams that we have agreed on an architecture outline, or?
Ryan, what is your opinion on Stefano's and my mails?

Some additional comments below:

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

I'm totally flexible on hooks vs. rdf-syntax, because its only an encoding
question. I was using hooks in my first draft, so maybe we can build on
this.

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

Another interesting thing could be property bags, meaning that all values
from properties from different vocabularies with the same or similar
semantic should be displayed together, e.g.

rdf:_4 [ rdf:type disp:PropertyBag ;
           rdf:_1 foaf:mbox ;
           rdf:_2 vCard:EMAIL ]

....

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

I was waiting for this argument, knowing that Stefano is engaged with cocoon
:-)
And I agree with him that a Velocity-template => Cocoon-transformation
approach would end up with too may steps.

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

So what are our next steps?

Should we keep on collecting requirements?
Or are we already in the stage of joining/reformulating our drafts?

Chris


> --
> Stefano.
>
>
Received on Tue Sep 07 2004 - 14:12:07 EDT