Mailing-List: contact general-help_at_simile.mit.edu; run by ezmlm
X-No-Archive: yes
Reply-To: <general_at_simile.mit.edu>
Date: Wed, 01 Sep 2004 18:13:26 -0400
From: Ryan Lee <ryanlee_at_w3.org>
X-Spam-Level:
X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham
version=2.63
X-SpamBouncer: 2.0 beta (8/20/04)
X-SBPass: NoBounce
X-SBClass: OK
X-Folder: Bulk
X-Status:
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
imports).
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
> # -----------------------------------------------
Agreed.
> # -----------------------------------------------
> # 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:hasPropertyDisplayType
simile:PropertyDisplayType's include simile:{AsArc,AsContainer} amongst
others.
> 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.
> 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 Wed Sep 15 2004 - 05:16:44 EDT