David R. Karger wrote:
> I'm trying to continue to catch up on this discussion.
>
> Reading this particular mail, I'm hobbled by my weakness at reading
> raw n3. Is there a tool for switching it to e.g. a circles and arrows
> diagram with labels/descriptions in the circles?
Have you tried Emmanuel's IsaViz? I'm sure there is a GSS somewhere for
RDFS.
http://www.w3.org/2001/11/IsaViz/
> However, one particular question does come to mind. Chris vocabulary
> at least appears to build-in the assumption that the target output of
> the display vocabulary is html. I don't know if I'm comfortable with
> this.
> Does it mean I'm going to need a whole different vocabulary to
> produce output for a rich client like Haystack (eg, one that will be
> used to manipulate the data and not just look at it, so needs support
> for rich graphical interaction like drag and drop)?
> I would prefer to factor out the portion of lenses that are "output
> format independent" at least to some extent. For example, which
> properties to display in a lens can clearly be talked about in a
> format independent way. Which properties of a given class can be
> thought of as a "title" for objects of the class can too. Even
> notions of rows and columns in a table seem more general than just
> html.
> As a sound bite, I'd argue for separate ontologies of _what_ to show
> and _how_ to show it.
Very much agreed.
> I also have a sense that e.g. FOAFLenses.n3 is repeating a feature of
> Haystack that I think may have been mistaken, of trying to describe
> the intended output html in RDF, when it is probably a lot easier on
> the developer to define the html in html---e.g., to use some kind of
> scripting with fill-in-the-blanks for rdf values.
Hmmm, I'm not sure here. The 'declarative fallback' nature of lenses
would be trivial to write in a scripted template, but it would be very
hard to reuse it across various ones, so I see value in their existance.
On the other hand, I agree that defining an HTML-like ontology for
presentation is not only reinventing the wheel, but potentially harmful
(given the fact that HTML/XHTML are much easier to write and read than
triples, especially when scripting is intermixed)
I still don't see a real reason (beside golden hammerish) why the
template part of the system should not be something like velocity with
special RDFPath/RDQL querying capabilities on the submodel passed to the
template.
--
Stefano Mazzocchi
Research Scientist Digital Libraries Research Group
Massachusetts Institute of Technology location: E25-131C
77 Massachusetts Ave telephone: +1 (617) 253-1096
Cambridge, MA 02139-4307 email: stefanom at mit . edu
-------------------------------------------------------------------
Received on Thu Sep 23 2004 - 13:54:18 EDT