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.
>>>>
>>>
>>>Yes.
>>
>>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 ryanlee_at_w3.org
W3C Research Engineer +1.617.253.5327
http://simile.mit.edu/
Received on Tue Sep 07 2004 - 20:50:29 EDT