David R. Karger wrote:
> 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.
You could do this easily in FSL by just using a disjunction:
fresnel:instanceLensDomain "path_expr1 | path_expr 2 |..."^^fresnel:selector
> > 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.
> > :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 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 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)?
> > 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)?
> > 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 - 07:05:05 EDT