Hi Ryan,
> > 1. Class-Instance Oriented
> >
> >> There are several ways to present a triple-based graph; this
> >> display vocabulary is oriented about using an instance of a glass
> >> as the basic building block of the user-agent's actual display. For
> >> instance, a dataset with one person's FOAF records would probably
> >> use each foaf:Person as a discrete unit in displaying the entire
> >> dataset.
> >
> > I also think the central display paradigm should be the instance. But
> > in addition it should also be possible to define which related
> > instances should be displayed together, e.g. foaf:Person, together
> > with their projects and publications.
>
> I agree; I don't think you can entirely specify this using my
> vocabulary, though you can come close with simile:showProperties. Being
> able to constrain the properties to certain classes might be
> appropriate. Or being able to say which configured classes can be
> displayed along with an instance may be even more appropriate.
>
Which is also an argument for having different view/lenses for one class.
For example the foaf explorer uses on lens to display the current
foaf:Person with a lot of details and another lens for displaying related
foaf:Persons with less details in the blue box.
See:
http://xml.mfd-consult.dk/foaf/explorer/?foaf=http://swordfish.rdfweb.org/people/libby/rdfweb/webwho.xrdf
> > 2. Filtering
> >
> >> There can be an overbundance of data that is not useful to users in
> >> a dataset. The ontology must provide a way to filter out extraneous
> >> or user-irrelevant data for presentation. Mechanisms that work on
> >> explicitly showing or explicitly hiding specific resources should
> >> be provided.
> >
> > Yes, and we should also deal with the case of different filters for
> > one class. People might want to display different aspects of a
> > resource, e.g. only the work related information about a person or
> > information concerning certain activities. The different filters
> > could interactively be chosen in the browser (Haystack lenses) or set
> > in the browser configuration. We should also think about different
> > people providing filters for the same class.
>
> Interesting point; I hadn't thought about on-the-fly modification. Do
> you think this is something that should be part of the vocabulary or
> something the browser controls?
Definitively something the browser controls.
> I'm thinking of Mozilla's interface for
> changing stylesheets - something the browser does that isn't especially
> designed into CSS, besides assuming one configuration per file (and its
> imports).
>
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.
> > 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.
> 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.
>
> > 7. Handling bNodes
> >
> >> Blank nodes (or bNodes, or anonymous nodes) are not identified by a
> >> URI; some closure for a graph including bNodes is often necessary.
> >> Mechanisms for artificial closure conditions or actual closure
> >> should be provided.
> >>
> >
> > Yes, but isn't this a task for the underlying data integration
> > architecture? I think we should concentrate on displaying one
> > *virtual* graph and leave aggregating information from different
> > sources/graphs including the necessary trust decisons to other
> > architecture layers.
>
> This may be naive of me, but if you have a configuration that says a
> foaf:Person can show its foaf:knows foaf:Person relationships and that
> it applies recursively, then you could run into infinite loops, which is
> only a product of how you specified the data should be displayed.
> Perhaps it should be the application's job to say when is enough, though.
>
Ok. Now I got it :-)
> > But first two additional requirement
> >
> > 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".
>
> I agree that being able to specify fixed data is important (i.e.,
> replace property-object pairs with just one set string or image
> depending on the pair value), but not particularly for whole parts of
> the output.
>
Hmm. See other mail. One good thing about RDF is that we don't have to
totally agree but can also move parts of the functionality to a
sub-vocabulary :-)
>
> > # -----------------------------------------------
> > # 3. Comparison of AnSeB and the SIMILE Ontolgy
> > # -----------------------------------------------
> >
> > An initial comparison how our vocabularies deal with the requirements
> > and my try to understand your vocab.
>
> I had half-written something that looked like this. The similarities
> between our assessments of the vocabularies' similarities are kind of
> amusing, but I digress.
Yes :-) but it's also interesting to understand the differences.
See other mail about style vs. template oriented language.
> I agree with the assessment and provided a
> little commentary to explain more.
>
> > The following classes are similar:
> >
> > anseb:lens and simile:ConfiguredClass
>
> and simile:Template
>
> > anseb:Part and simile:DisplayType
> >
> > 1. Class-Instance Oriented
> >
> > This is the paradigm of both approaches.
> >
> > anseb:Lens anseb:usableFor rdfs:Class
> > rdfs:Class rdf:type simile:ConfiguredClass
> >
> > Display related instances:
> >
> > simile:depthLimit ???
>
> for artificial bNode closure
>
> simile:(show|hide)Properties is a manner of specifying which related
> instances to display, along with being a filtering mechanism.
>
> > anseb:PropertySubLens
> > anseb:PropertyTable
> > anseb:ContainerParts
> >
> > 2. Filtering
> >
> > Choose which properties to display:
> > simile:defaultPropertyVisibility and hide/show properties
> >
> > anseb:Lens anseb:parts rdf:Seq
> >
> > Additional constrainsts:
> > simile:Constraint
> > anseb:PropertyCondition
> >
> > 3. Relational Specification
> >
> > Simile:???
> > Anseb:???
>
> simile:hasPropertyDisplayType
>
> simile:PropertyDisplayType's include simile:{AsArc,AsContainer} amongst
> others.
OK. Then anseb:ValuePart and anseb:ContainerPart
>
> > 4. Representation
> >
> > simile:DisplayType
> > anseb:valueParts
> > anseb:containerParts
>
> (see 11)
>
> > 5. Granularity
> >
> > Simile: ???
> > Anseb: Not supported yet
>
> Granularity for filtering is accomplished by allowing the visibility and
> show/hide properties to be used on the entire configuration or just a
> class. I suppose it could be used as-is on a specific property-object
> pair, too.
>
> Granularity for representation and relational specification is also
> accomplished by allowing their respective properties to be used at the
> global level, the class level, or a specific property or property-object
> level.
>
> > 6. Organization
> >
> > simile: ???
> > Display style anseb:sortASC anseb:sortDESC
>
> The ordering of the rdf:Seq is important if specified for
> simile:showProperties. If not, no deterministic ordering is imposed,
> though it may be reasonable to default to alphabetically increasing.
>
It also interesting to see, that I define ordering and display type in the
same rdf:Seq. You define it at separate places using a rdf:Seq for ordering
and constrains for the display types.
Really interesting discussion, form which I think we are both getting good
new ideas :-)
I'm looking forward to your comments ...
Chris
> > 7. Handling bNodes
> >
> > Simile: ???
>
> simile:depthLimit
>
> > Anseb: Not supported.
> >
> > 8. Not Presentational
> >
> > Simile: Yes
> > Anseb: Not supported yet
> >
> > 9. Translation Hooks
> >
> > Simile: ???
>
> None; currently, that thought translated to being entirely on the Java
> interpreter's end. I'm not quite sure how it would look in RDF right now.
>
> > Anseb: Not supported yet
> >
> > 10. Additional Fixed Display Elements
> >
> > Simile: Not supported yet.
>
> According to my interpretation as substitutions for statements, I didn't
> quite finish here, but there is a simile:ClassDisplayType of
> simile:AsSubstitution which I imagine could be an image, text, etc.
> None of that is yet specified.
>
> > anseb:fixedParts
> >
> > 11. Handling of Missing Values
> >
> > Simile: ???
>
> I didn't provide a clear way to do that except with simile:classSummary,
> which is how an instance of a class looks in brief, leaving out any
> other information attached to it. Otherwise, if something isn't there,
> then it doesn't show at all; there's no indication the property was
> configured by showing it as an empty field or anything. That probably
> needs some work.
>
> > Anseb: anseb:PropertyBag anseb:PropertySeq
> >
> > What do you think about also inviting Damian Steer (
> > http://brownsauce.sourceforge.net/) to this discussion. He might also
> > have interesting additional ideas.
>
> Yes, his input would be valuable.
>
> --
> Ryan Lee ryanlee_at_w3.org
> W3C Research Engineer +1.617.253.5327
> http://simile.mit.edu/
>
Received on Fri Sep 03 2004 - 11:22:51 EDT