Re: AW: catchup thoughts

From: David R. Karger <karger_at_mit.edu>
Date: Thu, 16 Jun 2005 13:57:53 -0400

   Mailing-List: contact fresnel-dev-help_at_simile.mit.edu; run by ezmlm
   X-No-Archive: yes
   Reply-To: fresnel-dev_at_simile.mit.edu
   From: "Chris Bizer" <chris_at_bizer.de>
   Date: Fri, 10 Jun 2005 12:24:20 +0200
   X-Spam-Score: 2.318
   X-Spam-Level:
   X-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00,
           MSGID_FROM_MTA_HEADER autolearn=no version=2.63
   X-LocalTest: Local Origin


   Hi David,

>
> I've spent a whole week catching up on the fresnel list archives, so
> now want to send out various thought. Probably too late to be useful,
> but just in case, here is the first:
>

   Yes, there is kind of a timing problem. There are already two Fresnel
   implementations close to being finished (Ryan in Java and Hannes in PHP) and
   I therefore think we shouldn't discuss the overall design anymore but wait
   until the implementations are finished and until we got more modelling
   experience with Fresnel. If we then find problems with the current design,
   we can still think about a redesign for Fresnel version 2.0

   We also got a fixed schedule for finishing the last open issues. There has
   been agreement on the requirements for the styling part and we will nail
   down the style vocabulary until next Wednesday.

   There might be an alternative proposal for the styling part by Ryan or we
   will stay with the current design.


> I am now of the impression that there are _three_ distinct layers in
> our ontology. Right now what we call "selection" involves both
> selection and grouping. We should separate them.

   Maybe, maybe not. Having them mixed is making modelling easier. Separating
   them is correct from the theoretical point of view.

How will emmanual make use of grouping in isaviz? Isn't he only going
to want the selection part?

   So I think we should wait for more modelling experience before we take any
   decisions.

   Chris


> The first,
> selection, should make no assumptions about grouping. Chris has said
> that this would leave selection as nothing more than a query, but I
> disagree. What remains crucial is the decision of which selection
> should be made at which time, i.e. by specifying the purpose that a
> particular selection can accomplish.
>
> It is this selection layer where I want to specify that "the summary
> information about a person is their name and email address". More
> generally I could imagine using the selection ontology to specify
> which properties are "important", "advanced", "for debugging", "useful
> for a quick browse", "keys (unique identifiers)", etc.
>
> I'm not even sure we should bother to specify a particular selection
> query language. If we do, I would focus on what useful syntactic
> sugars might capture particularly common queries in our
> application---for example, using just a list of properties to specify
> that the values of all those properties should be returned, instead of
> writing a corresponding sparql query.
>
> Selection of what I want to show should produce rdf, not a tree. Some
> devices might want to turn that rdf into hierarchical xml that can be
> styled, but I should also be able to use the selectors to, e.g.,
> decide what data to export into a database, in which case I want pure
> rdf. Also, I probably want to use this selection language to produce
> the RDF that gets fed to a graph-oriented viewing tool like isaviz.
>
> I wonder if it would be useful to associate each property with a
> "degree of detail" on some e.g. numeric scale, where 1 corresponds to
> necessary in all circumstances and 10 to only being needed in
> complete-info view?


   --
   Chris Bizer
   Freie Universität Berlin
   Phone: +49 30 838 54057
   Mail: chris_at_bizer.de
   Web: www.bizer.de
Received on Thu Jun 16 2005 - 17:55:43 EDT