Re: Display requirements

From: David R. Karger <>
Date: Wed, 15 Sep 2004 01:16:44 -0400

   Mailing-List: contact; run by ezmlm
   X-No-Archive: yes
   Reply-To: <>
   Date: Wed, 01 Sep 2004 18:13:26 -0400
   From: Ryan Lee <>
   X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham
   X-SpamBouncer: 2.0 beta (8/20/04)
   X-SBPass: NoBounce
   X-SBClass: OK
   X-Folder: Bulk
   X-Keywords: NonJunk
   X-UID: 216

   Chris Bizer wrote:
> This mail has the following structure
> 1. Requirements
> 2. Use cases
> 3. Comparison of AnSeB and the SIMILE Ontolgy
> # -----------------------------------------------
> # 1. Requirements
> # -----------------------------------------------
>> [[[
> 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.

> 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? 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

Right now haystack is inconsistent about this. For certain types of
view there is a "change view" menu available, while for others there
is not. Sometimes I think this is a perfect place for a "meta"
key---that one should shift-click on the view in order to pull down a
menu to manipulate or change the view. Other times I think that the
decision about how to expose control of a view should be left up to
the parent of the view (in the view hierarchy), eg a particular view
of a person may have a menu that lets you change the way you view the
person's address. Drawback of this is that really the knowledge of
how the address can be viewed really belongs to the address, not to
the person view. But presumably the person view could query the
address object about its views....

> 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. 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.

depends how much power we give to the display portion. If the widget
that displays a person wants a special-case display for the case where
the person has no address available, we might have to let that widget
sort the displayed properties itself.

> 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.

In our recursive view construction, things bottom out based on the
type of view---ie, "large" views tend to embed "medium" views, which
embed "small" views, which don't embedd anything.

> 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.

careful---"company logo" is not "fixed" unless you are talking about
the logo of the company that built the display widget.

> 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.

   This fell under representation in my mind, though I didn't explicitly
   say so.

   Stefano Mazzocchi writes:
> 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.

   This feels like a different case to me. For CSS, you're styling what
   you know is there in the XHTML (so you hope). In RDF, you can't know
   for certain that foaf:fullName is going to show up anywhere. That seems
   like it's entirely pertinent to how you display it. Including
   alternates in the design for the vocabulary certainly feels like it
   would buy a lot; I recall Nick mentioning that programming Haystack
   without knowing if data was there was a major annoyance, one most RDF
   developers have encountered. Saving designers from that aggravation
   would be a win.

   How would you suggest approaching the problem instead, Stefano?

> # -----------------------------------------------
> # 2. Use Cases
> # -----------------------------------------------


> # -----------------------------------------------
> # 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. 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:PropertyDisplayType's include simile:{AsArc,AsContainer} amongst

> 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

> 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.

> 7. Handling bNodes
> Simile: ???


> 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 (
> to this discussion. He might also
> have interesting additional ideas.

   Yes, his input would be valuable.

   Ryan Lee
   W3C Research Engineer +1.617.253.5327
Received on Wed Sep 15 2004 - 05:16:44 EDT

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