David R. Karger wrote:
> David R. Karger wrote:
>
> > > note that x:classLensDomain is actually redundant syntactic sugar
> > > since you could always take whatever selector identifies the class,
> > > wrap it in a "instances of this class" selector and use
> > > :instanceLensDomain instead.
> >
> > Yes, exactly, (B) is the same as (C).
> >
> > Yes, B and C are same. My point was that we might want both---nice
> > syntactic sugar---for the same reason that we have classLensDomain as
> > syntactic sugar for certain instanceLensDomain constructs.
>
> classLensDomain is not exactly syntactic sugar. If it were just that, I
> would have been strongly opposed to it. It was introduced because when
> considering only simple selectors, Chris wanted to be able to express
> domains as "instances of a class whose URI is ..." (most common use
> case) but also as "instance whose URI us ...".
>
> Something you can do easily with FSL without having to disambiguate the
> expression's intepretation by using different terms
> ({instance,class}LensDomain), but which is impossible with simple
> selectors. That's why this class vs. instance domain distinction was
> introduced.
>
> I still think it is confusing and making Fresnel more difficult to
> understand, but I also appreciate the fact that we need it, though we
> need it only because browsers are not required to support FSL, but only
> simple selectors.
>
> this is a helpful clarification. it does suggest to me that the
> naming is not quite write: as it stands, it reads as "this is an
> instance lens whose domain is..." whereas, from above I think what you
> want to say is "this lens applies to the following instances".
Yes indeed. I am not fluent enough in English to debate about this
issue. But if it really sounds like the 1st sentence ("instance lens
whose domain is...") then we really have a problem. It is misleading:
there is no notion of an instance lens or a class lens. All lenses are
equal (but their domain is defined by an expression that can be either
interpreted as a class of resources or as instances that meet
constraints such as having the given URI).
Ryan? What do you think? I know we've been discussing this again and
again, but this is truly important.
> Probably too late to be talking about names, but how about
>
> appliesToInstanceOf or forInstanceOf or appliesToResource or forResource
> appliesToClass of forClass
>
> Less mathematical sounding, but probably easier to remember
Yes. I like the idea of having "domain" in it, but I am willing to drop
it for the sake of clarity.
I still find your proposal ambiguous: I consider both appliesToClass and
appliesToInstancesOf to take a "class" as their value. I don't have any
great proposal, though...
> > > :allProperties is a predefined list.
> >
> > More or less. Its "value" (i.e., to what properties it refers) is
> > computed dynamically and depends on each resource to which the lens applies.
> >
> > > Can I also define other lists
> > > and put them into the :showProperties argument? Do such lists get
> > > concatenated? Or can I only list individual properties?
> >
> > I'm not sure I understand our question. Would you like to be able to put
> > a set of properties in an rdf:Seq and then give this rdf:Seq as one of
> > the elements of the showProperties sequence of properties to show? If
> > so, I guess we could do that, but it is not yet the case. What's the use
> > case?
> >
> > Can I use a query that returns a set of properties? ie,
> > ":showproperties all properties that have a label"
>
> There is no predefined term for "all properties that have a label". You
> can use FSL expressions as values of showProperties. However, the
> current FSL draft does not allow you to say "all properties that have a
> label", because this involves RDFS schema knowledge. You could do that
> with XPR though (an extension of FSL I am working on outside the context
> of Fresnel, more complex, but with more expressive power).
>
> I don't understand this. Isn't it possible to use FSL to say
> something like "x In allproperties and x :label y and y not null"?
The problem is that "x :label y and y not null" is schema information
that involves checking that property x, as a resource, has a :label
property (e.g. rdfs:label). This means that property x must be "reified"
as the schema resource that represents it, so that it can be used as a
location step on a subpath. This can be done in XPR, but not in FSL, and
it requires that the schema associated with property x is available at
runtime.
--
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 FRANCE http://www.lri.fr/~pietriga
Received on Mon Jul 18 2005 - 08:12:57 EDT