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
Date: Mon, 11 Jul 2005 09:05:32 +0200
From: Emmanuel Pietriga <Emmanuel.Pietriga_at_lri.fr>
X-Virus-Scanned: by amavisd-new at lri.fr
X-Spam-Score: 0.541
X-Spam-Level:
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=2.63
X-LocalTest: Local Origin
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".
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
> > :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"?
> > I think the specification for browsers of how to pick a label lens
> > might be a bit too specific. I might say that browsers _could_ do
> > this rather than _should_?
>
> What section of the manual are you refering to?
>
> section 2.3, end---rules for picking a label lens.
Isn't it better to have a "standardized behaviour" for this? What is
bothering you with this behaviour?
I'm all in favor of standardized behavior when we are confident that
there is only one right behavior and we know what it is. My concern
is that we are creating a specification here that may or may not be
right; it is too early in the game to tell. We could discover later
that our specification _prevents_ a tool from doing the right thing in
some circumstances. I'm even more concerned about this with regard to
query specificity (next comment).
> > I also question the specificity of preferring sparql lenses to fsl
> > etc. This is certainly a reasonable strategy, but I could think of
> > many others---eg to use the most recent creation date, or the one from
> > the namespace I like best, or the one that was parsed last (or first),
> > etc. I think that you rare trying to get at which lens is most
> > "specific" in that you can write queries in sparql that will return
> > very narrow subsets, but there is no guarantee that every sparql query
> > will have this characteristc.
>
> Yes indeed, I fully agree. But still, it is very likely that SPARQL/FSL
> selectors will be more specific than simple selectors. Otherwise, what
> is the point of using them. And we have to make a choice in case of
> conflict. Suggestions welcome.
>
> I'm not sure we have to make a choice in case of conflict. Why not
> let each developer make their own choice? Note that a conflict is a
> sign that the lens developer(s) didn't think of a differentiation
> between the lenses. so perhaps both are just as good. or perhaps the
> browser has a clever way of deciding which is better, that would
> disagree with our instructions.
Just to be sure we are talking about the same thing, are you just
questioning the specificity of prefering SPARQL to FSL to simple
selectors? Or the entire idea of a specificity function, even when all
conflicting lenses have their domains expressed with the same language
(e.g. FSL)?
I am entirely in favor of saying "any tool should attempt to apply the
most specific lens." My concern as noted above is about jumping to
conclusions, based on no particular experience, about which lenses
will be more specific. Note the it might be theoretically possible to
_compute_ which lens is most specific (by determining all items to
which each lens applies) and we should perhaps hold this out as the
ideal, but recognize that it will be computationally intractable to do
so, and leave it to different tools to figure out their best
heuristics.
> > In 2.5 Using Sublenses example, suppose I did NOT specify
> > fresnel:subLens :foafPersonDefaultLens. Would that lens be used
> > anyway because that is the defualt lens for objects of type person?
> > What happens when foaf:knows points to someone who is not a person?
> > Using the :foafPersonDefaultLens would be a bad idea!
>
> "Multiple Sublenses for Mixed Content" in [1] addresses that issue.
>
> [1]
> http://simile.mit.edu/repository/fresnel/trunk/docs/manual/FresnelVocabulary.htm#sublenses
>
> Yes, but this only works if the lens developer thinks of all the types
> that might arise as the value for foaf:knows. If I leave out one type
> X, then type X is going to end up with a bad presentation, even if in
> the outer context, there is a perfectly good lens for displaying type
> X.
>
> If the intent is that the lens developer has in mind that certain
> types should be displayed certain ways, then we should make that
> explicit (by nesting instructions like :defaultLens and
> :instanceLensDomain inside the mbox) instead of listing only the
> lenses we want to use and not listing the types to which they should
> apply. I think there is something wrong with our having inconsistent
> language at the top level and inside the mbox. ie at the top level we
> assign lenses based on types, but inside the mbox we do not.
Good point. Chris, Ryan, opinions (also on the following)?
Perhaps we should allow people to use all the syntax from the top
level, and just say that stuff in the mbox "overrides" whatever syntax
was present at a higher level.
> > It seems to me that what foaf:subLens is trying to do is to push a new
> > "stack frame" in which one can modify the specifications about which
> > lenses should be used for which types of objects. It is unclear to me
> > that we should have separate syntax for this---eg, why not just reuse
> > things like :defaultLens and :purpose? Should this idea be taken
> > further? Ie should foaf:mbox push a new stack frame where you can
> > nowassert any kind of lens or styling instructions that apply only to
> > that frame?
>
> We could also have decided not to have any fresnel:sublens and rely on
> fresnel:*LensDomain and fresnel:purpose to select the lens. I think that
> the current solution is some kind of compromise between this and your
> "new stack frame" suggestion. I would be in favour of keeping sublenses
> for now, play with Fresnel and based on our experience decide whether we
> want to leave it that way or explore one of the two other solutions.
>
> See above---I'm not too attached to the stack frame idea, but I am
> concerned that the present sublens syntax does not reflect the
> approach to presentation that motivated us to define the top level of
> fresnel the way we did. If we think that way is right, we should use
> it consistently.
--
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 11 2005 - 15:54:04 EDT