For the past couple of months, I've been working intently on integrating
my Fresnel code [1] into the Longwell 2.x codebase [2]. Here are some
things I've picked up during the process; some may be valid feedback for
refining Fresnel, others, common pitfalls implementers should avoid, and
still others just my error. I'll leave it to the community to decide
which is which.
1.
http://simile.mit.edu/repository/fresnel/trunk/
2.
http://simile.mit.edu/repository/longwell/trunk/
== Resource vs. Graph ==
As Reto pointed out in an earlier message to this list, the Fresnel
manual may be more appropriate in claiming that it renders a resource at
a time since a number of issues surrounding rendering the entire graph
make it a little disingenuous to claim otherwise. There isn't anything
in the vocabulary for graph result layout, ordering, or paging, quite
key to displaying the whole thing.
Longwell implements one resource at a time rendering. I thought that
might change, but now I'm not sure.
== rdf:type ==
Knowing the rdf:type of a resource is vital to lens matching and format
matching. Either it should always be selected for every lens and
managed through formats to disappear if not wanted or it should be part
of the subsystem's job to know the type(s) of every resource and carry
it through each stage as needed. I missed this until rather late in the
process and hacked around my error to ensure formats were matched by
adding rdf:type to all the lenses.
== Hash sets ==
There are a large number of hash sets to assist in matching lenses and
formats, probably too many. I'll step back and look and what I thought
I needed and what I used to figure out which ones should stay and which
should not. There were two ways I saw to do the actual matching - one
was to apply every domain to the data graph and record matches, then
choose which one to use at rendering time. The other was to take each
resource in the data graph and look up which lenses/formats it would
match. There are hash sets for both.
== FSL and SPARQL =
I'm unclear on how to fit FSL and SPARQL could fit into the hash lookup
described above. Off hand, it seems each expression would have to be
executed fully against the data graph.
As Chris Murphy has brought up, there are ambiguities in using FSL and
SPARQL expressions - for instance, which property label is used in a
multi-step path?
== Uninformed group choice ==
Without an explicit group of lenses and formats to rely on, one
heuristic for choosing a group may be to look at its primaryClasses for
matching a resource's type to a relevant group. Or otherwise using all
of the classes listed within all of the group's lens class domains to
find a match.
== Unintegrated ==
There are still some places where Fresnel and Longwell aren't talking
where they really should be. The two major points are in display facet
values (Longwell uses the generic algorithm of looking rdfs:label, using
URI fragments, etc.) and in ordering (again, Longwell is looking at its
own interpretation of labels and the like).
The facet value question is ultimately a vocabulary extension matter,
but both it and the ordering question in my mind bolster a case for
claiming resource level rendering.
I haven't done any error reporting from Fresnel, which I imagine would
be very useful for debugging in the future.
== Bugs ==
There are probably still bugs to be found. I know { [ ] fresnel:label
fresnel:none } doesn't work correctly. If you find any others, please
log them in our issue tracker under Longwell.
http://simile.mit.edu/issues/
--
Ryan Lee ryanlee_at_w3.org
W3C Research Engineer +1.617.253.5327
http://simile.mit.edu/
Received on Thu Mar 02 2006 - 01:48:35 EST