Re: Display requirements - answer to Ryan's mail

From: Ryan Lee <>
Date: Tue, 07 Sep 2004 16:50:30 -0400

Hi Chris,

I hope I'm not too out of synch on these - I moved last week and over
the weekend, and we had a US holiday. With no internet access at the
new home, I've been kind of out of touch, so now I'm playing catch up :)

> Yes, I'm having something similar in mind. I would say, that there are
> different
> views/lenses/filters/styles/ConfiguredClass (don't know an appropriate name,
> any suggestions?) for a class and the
> browser can decide if the wants to display all, only one or a combination of
> views or leave the decision to the user.
> BTW: We also have to keep in mind that a resource might be an instance of
> different classes.
> That's why I think we have a 1-to-many relationship between Resource and
> views/lenses/filters/styles/ConfiguredClass.

Agreed, though being able (at whatever level is appropriate) to declare
which class an instance should be displayed as might be a useful
feature, in addition to browser-based manipulation, perhaps as yet more
ranking, with a rdf:Seq of preferred class displays.

>>>6. Organization
>>>>The order of information can be instrumental in conveying its
>>>>content. Mechanisms for sorting predicates and objects in a
>>>>layout-independent manner should be provided.
>>Allow me to clear that up, what I meant was specifying exactly which
>>order the predicates of an instance would show up in.
> Yes, ordering the predicates is essential. But I see a problem concerning
> requirement "5. Granularity".
> How do we combine predicate orders defined on different levels? e.g.
> rdf:Resource: showProperties 1. rdf:Type, 2. rdfs:label and foaf:Person
> showProperties 1. foaf:name 2. foaf:mbox.
> A possible solution could be to show the more "local" properties first and
> move up the hirarchy afterwards, meaning
> 1. foaf:name
> 2. foaf:mbox
> 3. rdf:Type
> 4. rdfs:label
> We should also think about mechanism that prevent the output to
> explode, if we are having an instance with 100 properties. See
> other mail.

This overlaps slightly with the above issue. As you mention, there is a
scaling issue with doing things this way; perhaps a different way to
approach it is to only allow one view per instance to be displayed at a
time, but provide a way to change to another view. Combining views
seems like it might be visually confusing tactic.

>> I don't mean to
>>say anything about sort or order-by of the data itself, actions I think
>> are better suited to a different application. That starts to get into
>>manipulating the RDF, which I take back from one of my original emails
>>as poor phrasing (I guess what I meant then was that the application had
>>to be RDF-aware beyond being able to parse its XML syntax).
>>I think the data that arrives for display should have any ordering or
>>sorting done beforehand.
> On abstract syntax level, there is no order defined for the triples in an
> RDF graph. Thus I think it should be possible to say that the multiple
> values of foaf:knows should be ordered alphabetically by foaf:name.

Yes, though rdf:Seq can be interpreted as having ordering. I suppose
most data arriving for display is probably not going to have been
processed with an rdf:Seq form in mind though. As I scanned briefly in
later emails, it seems like this belongs in the content selection layer.

Ryan Lee       
W3C Research Engineer    +1.617.253.5327
Received on Tue Sep 07 2004 - 20:50:29 EDT

This archive was generated by hypermail 2.3.0 : Thu Aug 09 2012 - 16:39:17 EDT