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.
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.
3. Relational Specification
>
> The form of a triple - particularly the predicate portion of a triple -
> may be better expressed in ways other than a plain text label, such as a
> node-and-arc or containment layout. Terms for expressing different
> relationships for particular predicates should be provided.
>
Yes.
4. Representation
>
> Certain types of data are better represented graphically or in some
> manner other than plain text, and certain classes of data are better
> summarized by using something other than its label or title. Mechanisms
> for specifying alternate expressions of a triple, perhaps by
> substituting graphics or the like, should be provided.
>
Yes, definitively.
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 :-)
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.
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.
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 ....
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.
> ]]]
>
# -----------------------------------------------
# 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
# -----------------------------------------------
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
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
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 Wed Sep 01 2004 - 11:35:00 EDT