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.
> 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).
> 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.
> :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?
> 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?
> 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.
> On the other hand, the idea of using most specific subclass makes
> sense, because that is clearly a more specific lens.
>
> I'm of two minds about using :defaultLens over others. It goes
> _against_ the idea of using most specific lens. But it is probably
> safer.
>
> I also don't think browsers should issue a (user visible) warning when
> they can't decide. This is just a bad idea from a user interface
> perspective. Logging the problem would be reasonable of course.
Yes, we discussed that a few days ago and came to the same conclusion
(log the warning but don't show it to the end user; he doesn't care!)
> 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
> 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.
> What happens if various :sublenses invoke each other with different
> :depth arguments? Is the semantics that depth is a global variable and
> a sublens doesn't apply if the depth exceeds the depth specified for
> that sublens? if so, is there any way to specify a "base case", eg
> what is going to happen if the sublens cannot be invoked because of
> the depth constraint?
I have to think about that. Coming back to it later.
> the embedded example with fresnel:use doesn't demonstrate/explain to us
> anything about the predicate. I followed the link to the full
> example and still couldn't understand :groups.
I don't remember who wrote that part. Chris?
> in general, perhaps examples would be helped if, in addition to
> showing the lenses, you showed the output (to some standard format
> like html) of using them?
We should definitely do that. I guess we are waiting for Ryan's
implementation; this should ease the work.
Emmanuel
--
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 Fri Jul 08 2005 - 15:15:44 EDT