Eric Hanson wrote:
> Hi all,
>
> Just found the Simile project, and want to first say that I am
> happy to have found this project, I think you guys are working
> on some very interesting issues, and they resonate with me
> pretty generally. I think visualization and user interface is
> one of the biggest hurdles between us and the SW, and I think
> you've got some great ideas going here.
>
> I've got some thoughts that might be construed as disagreement,
> but like someone else recently said, for each diagreement there
> are at probably 10 points of resonance and, honestly, jealousy
> that you guys are working on something so cool. And I'm just
> happy to have found some folks to disagree with. :-)
Welcome on board!
> Ok, so I think Lenses are exactly the right place to start
> associating user interface components.
> Here's my question. How is a Lense different from a named query
> or what we call a "view" in the relational world? It seems like
> they are the same notion.
Yes, conceptually I think they are more or less the same thing. A lens
applies to a given set of RDF resources (identified by common
caracteristics such as their class, or them having the same property,
e.g. foaf:name "Doe"). For each resource in this set, the lens tells you
what properties related to the resource should be selected for display
(and maybe in what order they should be presented). But it also tells you:
- what properties to select in case the one you want is not available
(alternate properties)
- one properties should be presented together (properties to be "merged"
or grouped as a single property in the representation)
> Lenses have uses that extends beyond
> user interface. For example, security. You could use a lense
> for a public view of a repository that would exclude triples not
> meant for public consumption, stuff like the user base or
> administrative metadata.
>
> So I guess I'm arguing that lenses are valuable and you're using
> them totally right, but you might save some work and make them
> more generally useful by just defining them as RDF
> serializations of queries, be it SPARQL or other languages.
I'm not sure I really understand what you mean by "define them as RDF
serializations of SPARQL queries". We do not want to represent queries
as RDF models. I did that for GSS selectors [1], and I should never have.
What could be considered is using more generic terms than
{show,hide}Properties that would make sense outside the scope of RDF
presentation. Or you could just choose to use other "equivalent"
properties defined in your own Fresnel-based vocabulary.
[1]
http://www.w3.org/2001/11/IsaViz/gss/gssmanual.html#selectors
--
Emmanuel Pietriga
INRIA Futurs - Projet In Situ tel : +33 1 69 15 34 66
Bat 490, Université Paris-Sud fax : +33 1 69 15 65 86
91405 ORSAY Cedex http://www.lri.fr/~pietriga
Received on Mon Apr 25 2005 - 06:52:39 EDT