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: Fri, 08 Jul 2005 17:15:48 +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
Hello David,
David R. Karger wrote:
> I've started working through the manual. Here are my notes on the
> core lens vocabulary.
>
> You say that FSL exprs and SPARQL queries should always use
> fresnel:instanceLensDomain. Isn't it possible that I might want to
> isse a complex query that returns a type (or a set of types) to which
> I want the lens to apply? This would be the natural semantics if I
> used :classLensDomain with a complex selector.
We could, but I find it confusing as you can say that directly in the
FSL expression itself:
# (A) lens applies to resource whose URI is ex:aClass
ex:lens rdf:type fresnel:Lens ;
fresnel:instanceLensDomain "*[uri(.) =
'ex:aClass']"^^fresnel:selector .
# (B) lens applies to instances of class ex:aClass
ex:lens rdf:type fresnel:Lens ;
fresnel:instanceLensDomain "ex:aClass"^^fresnel:selector .
You could use classLensDomain with the same expressions, and you would get:
# (C) lens applies to instances of class ex:aClass
ex:lens rdf:type fresnel:Lens ;
fresnel:classLensDomain "*[uri(.) =
'ex:aClass']"^^fresnel:selector .
# (D) lens applies to resources whose rdf:type is a resource which is an
instance of ex:aClass
ex:lens rdf:type fresnel:Lens ;
fresnel:classLensDomain "ex:aClass"^^fresnel:selector .
In the end, (C) is the same as (B) => redundancy but with different
fresnel domain properties which is confusing, and (D) does not really
make sense. So I'd rather forbid classLensDomain in conjunction with FSL.
the point I was making was the equivalence of (B) and (C). I could
imagine a (more complex) query in C that returns a set of classes, as
a way to say that this lens applies to anything in that set of classes.
> 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.
> unclear whether :showProperties or :hideProperties "dominates" (or
> whether it is order dependent). eg what if my lens says
> :showProperties :a :hideProperties :a (I could imagine this happening
> if the lens gets programmatically assembled).
This is incoherent, but nothing forbids somebody from saying it. If this
happens, showProperties should prevail.
While no person will say it, it might arise if the lens is constructed
dynamically.
> :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"
> I didn't understand the fresnel:member usage.
Yes. I think we need to clarify this with a few examples and description.
> 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.
> 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.
> 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.
> 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.
Received on Sun Jul 10 2005 - 06:19:42 EDT