Hi Stefano,
very interesting. Your mail really helped me to understand the differences
between Ryan's and my approach.
It seams that:
+ you are thinking about a pure stylesheet language, that why you don't like
conditions and additional content.
+ 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.
+ 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.
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 :-)
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).
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).
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.
I'm not insisting that any of the above is true and I'm looking forward to
Ryan's reply :-)
> Chris Bizer wrote:
>
> [snip 'cause nothing significant to add]
>
> > 10. Additional fixed display elements
> >
> > It should be possible to specify additional fixed, data intependent
display
> > elements like headers and footers, company logo, explanations to certain
> > sections, e.g. "This is a list of all projects for which the person is
> > currently working".
>
> 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.
>
> 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?
>
> > 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.
> 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?
Chris
> > # -----------------------------------------------
> > # 2. Use Cases
> > # -----------------------------------------------
> >
> > Potential use cases for a RDF display ontology.
> >
> > 1. Display RDF local data with a text-/graphic- and resource-oriented
> > browser
> > (like LongWell, Haystack, AnSeB) using one application-specific
ontology
> > and one
> > set of style sheets.
> >
> > 2. Display RDF distributed data with a text-/graphic- and
resource-oriented
> > browser
> > (like LongWell, Haystack, AnSeB) using different application-specific
> > ontologies and
> > multiple sets of style sheets provided by different authors.
> > 3. Render RDF data as a text-oriented report (e.g. PDF)
> > 4. Render RDF data as a graph (e.g. SVG, like IsaViz)
>
> > 5. Edit an RDF graph
> >
> > I'm mostly interested in use case 1 and 2. But it would be nice if
> > our ontology would also fit for the other use cases or at least
> > would be extensible for the other use cases.
> > Maybe we should rule editing out of scope for the first version.
>
> Agreed, 5 is overkill at this point.
>
> [snip]
>
> > What do you think about also inviting Damian Steer (
> > http://brownsauce.sourceforge.net/) to this discussion. He might also
have
> > interesting additional ideas.
>
> Totally. Damian is fully aware of longwell and might have good input for
us.
>
> --
> 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 Fri Sep 03 2004 - 11:22:54 EDT