I'm coming somewhat late to this discussion, but have various
opinions. I'm going to post them in place, instead of aggregating
them at the end.
By way of introduction, I run haystack, which uses a general view/lens
architecture for all its display work. The basic approach is
recursive: rules have the form "to display foo in a big box, display
foo's author in a small box, foo's address in a medium box, and so
on".
Mailing-List: contact general-help_at_simile.mit.edu; run by ezmlm
X-No-Archive: yes
Reply-To: <general_at_simile.mit.edu>
From: "Chris Bizer" <chris_at_bizer.de>
Date: Wed, 1 Sep 2004 13:35:21 +0200
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-SBNote: Bulk Email (From_Daemon/Listserv/Resent/Precedence)
X-SBScore: 0 (Spam Threshold: 20) (Block Threshold: 5)
X-SBClass: Bulk
X-Status:
X-Keywords: NonJunk
X-UID: 173
Hi Ryan and all,
some additional brainstorming about the requirements, some use cases and a
first comparison of our approaches.
> Chris Bizer, Stefano, and I have been discussing an ontology for
> displaying RDF with an eye on implementing one for use in Longwell. One
> of our recent side objectives for SIMILE was to also use a common
> display ontology in Longwell and Haystack and hopefully generate broader
> community support for it.
>
> As it turns out, Chris and I had both drafted vocabularies, which seem
> pretty similar at a glance, so we're going to proceed by first
> exchanging requirements and use cases. I'd already started to write a
> little bit on my work. Here's an excerpt of the requirements I thought
> up on what the vocabulary should cover (characteristics of the
> vocabulary should include simplicity and ease of reuse):
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.
There are two separate concepts to consider here. In one case, we
want a rule/method for displaying people. It is perfectly reasonable
to define a rule for displaying people that requires one to display
their friends or their projects. So this is covered in the concept of
views. In a second case, one might want to define what we call a
workspace, in which a number of distinct items are displayed
simultaneously for some purpose. In this case one might simply
specify that the workspace should display a given person, and also
display a list of projects. Really, this workspace is a special
purpose view of a collection (of items that you want to see together).
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.
Minor, detail, but I think "filtering" puts the wrong spin on it.
Much more common than wanting to block certain data is wanting to
select out only a small subset of what's there.
5. Granularity
>
> The scope of action for certain mechanisms should be applicable at the
> broadest level, for every resource in a dataset, and the most specific
> level, for specific subject - property - object combinations. These
> mechanisms include filtering, relational specification, and
representation.
>
Yes, didn't think about this yet. Which will mean that we end up with
cascading RDF style sheets (CRSS :-)
We are trying to separate notions of "what is shown" from "how it is
decorated". The former clearly includes things like which properties
of the given object should be (recursively) shown. The latter
includes things like fonts. Unfortunately we haven't yet been able to
firm up the separation. One thing that plays an important role is the
notion of an "environment". Since most of the views are hierarchical
(view of person contains view of name, view of address, etc) a lot of
our views inherit various values (eg the current object, the current
font size) from the containing view and use it to style themselves.
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.
We generally focus sorting on our "collection" views (views for
viewing collections). For these it is natural to sort. I'm not sure
one ever sees a good motivation for sorting without having a
collection at hand.
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.
Agreed---we ignore bnodes in haystack (never create them).
8. Not Presentational
>
> The vocabulary does not deal with the specifics of presentation; i.e.,
> coloring or margins. This is handled better by the specific user-agent,
> and technologies already exist for handling such details. For instance,
> an XHTML rendering of RDF using the display vocabulary could use CSS to
> handle color coordination and certain layout issues.
>
Yes. Maybe we could have different low-level style class instances for the
different output formats attached to a high-level style, e.g. an instance
using CSS, one using FO and so one ...
9. Translation Hooks
>
> The vocabulary should be mostly independent of output syntax, so
> XHTML+CSS, SVG, or plain text could be derived from the same RDF and
> configuration, if someone wrote the code for their desired output format.
Yes, which leads to the use cases ....
I've been starting to think about the connection between views as
discussed above and data export. I wonder if it might make sense to
use the same approach for "present in (export to) html" as for "export
to bibtex format". In both cases, it seems like some sort of
scripting language is appropriate, where one uses the target language
to define the output template but uses various escapes to access
fields of the rdf object(s) being displayed.
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".
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.
Not clear that fill-in of missing values is truly the job of a
display-level vocabulary. It might better be delegated to the
inference layer of the data model.
At the same time, we have taken steps to deal with this problem in
haystack. As an example of current use, haystack uses a
"titlePredicate" property to specify, for a given type of object, what
properties can be used appropriately as a "name" for the object when
it is displayed on screen (example: "dc:document hs:titlePredicate
dc:title"). Right now there are just a couple of special-case
predicates for this, but we are trying to generalize what is going
on. There seem to be certain "vaguely similar" predicates over
different types that should get used in similar ways in display---eg,
the title of a document, the subject of a mail message, the name of a
person. We certainly don't want to declare these properties
equivalent in the data model, but we would like to tag the
corresponding properties in all types. (This is one of the uses to
which we want to put what we call "VOWL", since it can stand both for
"view ontology web language" and "vague ontology web language", both
of which are appropriate.)
As another example of this kind of vagueness/property blending,
consider a calendar view. When we feed a collection to a calendar
view, we would like to see the items laid out by date. But which
date? An email message about a seminar has a creation date, a
received data, and a seminar date. We can specify that these are all
reasonable dates to use, but probably also want a way to say which is
the best default (and a way for the user to override it).
There's a whole additional family of requirements that you haven't
touched on, perhaps because a tool like longwell is primarily seen as
a (read-only) data viewer. But haystack worries also about
manipulating/editing/modifying the data, so we need a view
specification language that can talk about the manipulations---eg,
what are the consequences when object a is drag-and-dropped onto
object b?
> ]]]
>
# -----------------------------------------------
# 2. Use Cases
# -----------------------------------------------
Potential use cases for a RDF display ontology.
1. Display RDF local data with a text-/graphic- and resource-oriented
browser
(like LongWell, Haystack, AnSeB) using one application-specific ontology
and one
set of style sheets.
2. Display RDF distributed data with a text-/graphic- and resource-oriented
browser
(like LongWell, Haystack, AnSeB) using different application-specific
ontologies and
multiple sets of style sheets provided by different authors.
3. Render RDF data as a text-oriented report (e.g. PDF)
4. Render RDF data as a graph (e.g. SVG, like IsaViz)
5. Edit an RDF graph
I'm mostly interested in use case 1 and 2. But it would be nice if
our ontology would also fit for the other use cases or at least
would be extensible for the other use cases.
Maybe we should rule editing out of scope for the first version.
# -----------------------------------------------
# 3. Comparison of AnSeB and the SIMILE Ontolgy
# -----------------------------------------------
I'm shaky on the actual details of what my students have been writing,
but I'll add haystack approximations:
An initial comparison how our vocabularies deal with the requirements
and my try to understand your vocab.
The following classes are similar:
anseb:lens and simile:ConfiguredClass
anseb:Part and simile:DisplayType
hs:viewDomain (view hs:viewDomain typeName)
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 ???
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
We don't take this approach. Each lens explicitly describes all
properties that are shown (and their layout)
Additional constrainsts:
simile:Constraint
anseb:PropertyCondition
3. Relational Specification
Simile:???
Anseb:???
4. Representation
simile:DisplayType
anseb:valueParts
anseb:containerParts
5. Granularity
Simile: ???
Anseb: Not supported yet
6. Organization
simile: ???
Display style anseb:sortASC anseb:sortDESC
7. Handling bNodes
Simile: ???
Anseb: Not supported.
8. Not Presentational
Simile: Yes
Anseb: Not supported yet
9. Translation Hooks
Simile: ???
Anseb: Not supported yet
10. Additional Fixed Display Elements
Simile: Not supported yet.
anseb:fixedParts
11. Handling of Missing Values
Simile: ???
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.
Chris
Received on Mon Sep 13 2004 - 22:37:12 EDT