Re: Display requirements - style vs. template oriented language
Hi Stefano,
some short thoughts. I will answer your mail in detail next week.
First, I agree
- that I'm a golden hammer freak
- that Velocity is a great tool.
I think there is a need for a "natively RDF friendly" template language and I will try to argue for an 3-layer architecture which could look the following:
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 :-)
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; ] ] .
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)
The potential advantages this architecture are:
+ You have a fully declarative style language which sperates style from content-selection.
+ 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?).
+ Lenses are expressed using RDF, which means that you can reuse/move around/publish them much better on the Web than Velocity templates.
+ 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.
Ehh?
Chris
> Chris Bizer wrote:
>
> > Hi Stefano,
> >
> > very interesting. Your mail really helped me to understand the differences
> > between Ryan's and my approach.
>
> Thank you. Keep up the great comments too! ;-)
>
> > It seams that:
> >
> > + you are thinking about a pure stylesheet language, that why you don't like
> > conditions and additional content.
>
> no, wait. What I'm saying is that you need two things: content and style
> and that separation of these two is critical. I think everybody agrees here.
>
> The subdle difference is that on the client side, the content is given
> to you, it's a finite resource and there is no selection going on (if
> not during dynamic user interaction but that's another story).
>
> On the server side, the 'content' is not clearly defined and, in
> general, it's a lot more than you can fit in one page (otherwise, you
> would have static pages, not a dynamic one)
>
> So, while on the client side "content/style" separation is enough, on
> the server side this changes into "content-selection/style-selection"
> separation.
>
> There are two approaches for "content-selection": type 1 and type 2 (I'm
> using the JSP terminology here, even if I dislike JSP as a technology).
>
> Type 1 is basically "pull": you define what you want and you get it.
>
> Type 2 is basically "push": the data is pushed into you and you just
> make sure you present it.
>
> an example of the first would be something like
>
> <query>select * from blah</query>
>
> and an example of the second would be something like
>
> <ul>
> #foreach $blah in $dataset {
> <li>$blah.firstname | $blah.lastname</li>
> }
> </ul>
>
> where $dataset is the container that holds the data passed to the template.
>
> Type 1 approaches are normally called 'server pages' (examples are PHP,
> ASP, JSP)
>
> Type 2 approaches are normally called 'template engines' or 'templates
> systems' (examples are Velocity, Jaxel, Jaxp)
>
> Type 2 is also referred to as the "server-side MVC" where the "view" is
> the template page, the model is the data that is passed to it and the
> controller is the logic that creates that data.
>
> Note how, for example, JSP can be used both in type 1 and type 2 and
> frameworks like Struts enforce you to use JSP *only* in type 2.
>
> Note that while I use XML in the above examples, nothing prevents you
> from using different syntaxes and semantics for the two approaches, but
> the "push vs. pull" mechanism is something that is critically different:
> type 1 has the content-selection logic built in, type 2 does not.
>
> Real life usage has shown that type 2 is better because presenation
> concerns and content-selection concerns are normally very different.
>
> What I am advocating is the need for keeping a "type 2" approach in
> Longwell, which is already based on Velocity.
>
> Now: velocity templates are "java oriented", which means that they don't
> work on the semantics of RDF but thru the Jena API (which can be seen as
> a DOM for RDF in a sense)
>
> The question in my mind is: do we need a template language that is more
> "natively RDF friendly"? or not?
>
> If so, what does it mean? how do we separate selection operations
> (iterations and conditionals) which belong to the template layer from
> presentation information (block, inline, etc..) which belongs to the
> style layer?
>
> > + I'm really thinking about a more template-oriented language, where
> > different templates/lenses are provides by different authors and the user
> > can choose which templates or template combinations he likes to use for
> > displaying an resource.
>
> I've been involved in the cration of publishing system for a long time
> and I've been part of the JSP working group, create the XSP
> specification myself and witness the creation of basically every
> server-side framework for java that exists and I'm very much concerned
> that writing a template system for RDF in RDF means repeating the
> "golden hammer" anti-pattern, which is: when you have a hammer in your
> hands, everything looks like a nail (haystack for example, suffers from
> this a great deal).
>
> The use of RDF to describe an template for RDF seems overkill to me,
> much like the use of XML to describe templates for XML ended up being
> flawed (and since I was the proponent of that concept, I totally
> understand where you are coming from!)
>
> I agree that RDF might be perfect for presentational meta-metadata, but
> for data-selection (which requires some scriptability) I have very
> strong doubts.
>
> But, as I said, I've been wrong many times in the past too, so I'm very
> interested in hearing your opinions on this.
>
> > + Ryan seams to think about something in between. His ideas about
> > granularity are stylesheet-oriented. Having conditions and ordering by
> > predicates is more template-oriented.
> >
> > This difference also explains why Ryan and I are approaching the problem
> > from different sides in our vocabularies. In Ryan's vocab you start with
> > ConfiguredClasses and use additional conditions to define the
> > DisplayStyle/Part type of properties. In my vocab you start with a lens,
> > which contains a number of parts/display styles and the properties are
> > attached to these parts.
>
> Makes sense. I had the same perception. Also, keep in mind that Longwell
> is already using Velocity templates and therefore I think both Ryan and
> I are oriented toward a presentational meta-metadata ontology because
> Longwell served us well so far.
>
> Note: even the SWAD-E portal implemented by the Jena team is using
> Velocity templates and they reported similar happyness with the
> approach. [of course, this doesn't mean it can't be improved, but it
> does mean that it cannot be more complex than this or it won't be adopted]
>
> > Now the interesting question is, which approach is:
> > 1. more flexible
> > 2. easier to use for authors
> > 3. produces output that fulfils the expectations of the end users
> > 4. better suited for distributed environments
> >
> > A first guess:
> >
> > 1. I think flexibility depends on the use case, but Ryan's cascading
> > approach is definitively more elegant :-)
>
> The declarative nature of presentational metadata is, in fact, the
> beauty of CSS (which is not reflected in XSLT, being half-declerative
> and half-procedural)
>
> It also resulted in being a lot easier to understand for graphic designers.
>
> > 2. I think it easier to write down directly what you want to have displayed
> > in which order, than to use a cascading hierarchy of styles, that are
> > combined afterwards. Proof: People easily understand HTML as a straight
> > forward way to write down what should be displayed in which order. Much less
> > use CSS really in a cascading way. Even less understand XSLT's recursive
> > template mechanism (this is at least my experience with my Students here at
> > the University).
>
> Very true, but keep in mind that we might be talking about different
> things: for content selection and templating, I agree that a procedural
> approach is better, but for styling, I think that a purely declerative
> approach is king. XHMTL+CSS shows this very very well. XSLT, in fact,
> has nothing to do with style, but it's a tree transformation language
> with first-class recursive tree querying capabilities and FO is an
> utterly complex way to do XHTML+CSS without separation (which is why it
> never took off).
>
> > 3. If you expect the end uses to want something that looks and feels like a
> > normal HTML-page, conditions and additional content are important. Using a
> > template-oriented language it's easier to define sensible display
> > blocks/views. If you don't have conditions you output explodes if you are
> > having more instances or let's say more than 100 property values per
> > resource (reasonable with foaf).
>
> Agreed. But we already have that: velocity templates have iterations and
> conditionals. Why do you see the need for something else?
>
> > 4. I think it is easier to exchange/reuse display information if it is all
> > included in an compact unit.
> > So I can send somebody my foaf profile together with two proposals how to
> > display it. He will decide if he uses them or prefers to use the display
> > proposal of somebody else or a combination of both. This is more difficult
> > if the display information is spread over a cascading hirarchy of style
> > instances.
>
> Well, this is like saying that having <font> in HTML is better than
> having style moved into CSS because it's more explicit and easier to
> move around.
>
> I strongly disagree, if this is the case. And basically every web
> designer on the planet disagrees too.
>
> >>hold it! This is where I have a problem: I think you want a template
> >>language for RDF in RDF.
> >>
> >>What I would like to have is a declarative visual ontology but
> >>definately *NOT* a procedural template language since there are already
> >>so many out there.
> >
> > Which? Can you please send me some links?
> > The only RDF-data-model-based template language I know is Haystacks display
> > ontology.
>
> There are many template systems out there (see above) but none of the
> ones I was thinking of treats RDF as a first-class citizen, but use an
> object model provided by some APIs.
>
> >>The fact is that foaf:person cannot be visualized because there is no
> >>visual information (therefore, you cannot decide how to present this).
> >>
> >>You said "cascading RDF stylesheets" and that hits the nail on the head,
> >>but when you say "you must also have the company logo", that freaks me
> >
> > out.
> >
> >>one thing is to have "content" in the CSS level (very useful in :before
> >>and :after CSS selectors), because, for example, "Warning: " before a
> >><warning>...</warning> element is style, not content.
> >>
> >>But a company logo, a header, a footer, they are al content, not style
> >>and content should be dealt with a template language, not a stylesheet
> >>language and I really think that writing a template language in RDF that
> >>would be abstracted from the actual presentation markup would be
> >>*waaaaay* abusive (and would reinvent half a dozen wheels)
> >
> > Why? Which wheels?
>
> template languages' for one, either reinvent wheels or fall into the
> same mistakes that took a decade to get uncovered for HTML and friends.
>
> >>>11. Handling of Missing Values
> >>>
> >>>It should be possible to specify alternatives for missing values e.g.
> >>>display foaf:firstname and foaf:last name if foaf:name is missing. Or
> >>>display dc:title if rdfs:label is missing.
> >>
> >>Again, same thing: conditionals are not part of style because
> >>conditionals are procedural not declarative.
> >>
> >>It is not up to the 'display ontology' to indicate "what" information
> >>should be there, but "how" the information present should be displayed.
> >
> >
> > I disagree here. If you are thinking of resources with lots of properties
> > and lots of different types and lots of different vocabularies used for
> > describing them, it is very reasonable to define what should be displayed in
> > a certain situation. Otherwise you end up with exploding SVGs and long
> > scroll-bars on your browser. Both not very user friendly. That's also the
> > reason why I like Haystack's lenses a interactive filtering mechanism.
>
> I did not say that those things are not important. I totally agree with
> you that you need an abilityt to do "content-selection" on the server
> side and the easier you can do it, the better.
>
> What I'm questioning is the fact that we are thinking about "one"
> ontology for both things, content selection and content presentation.
>
> I think we need two different ones, at the very least.
>
> >>Mixing these concerns is just like repeating the <font> HTML tag mistake
> >>over again.
> >>
> >
> > Brainstorming: Might it be an idea to have two different layers: One style
> > layer and a separate filtering and ordering layer?
>
> exactly ;-)
>
> --
> 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 Sat Sep 04 2004 - 08:42:57 EDT
This archive was generated by hypermail 2.3.0
: Thu Aug 09 2012 - 16:39:17 EDT