Emmanuel Pietriga wrote:
> 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.
I think the documentation exists to clarify these terse term names. Any
arrangement of the component words in any term is going to be
susceptible to misinterpretation, and I don't think one is really better
than another. I could assume a lensInstanceDomain was the 'domain of a
lens-instance' or that lensDomainInstance was an 'instance of a
lens-domain.' You'd look at the schema or the documentation to
understand what I meant.
As it is getting late in the game (partly due to the lateness of my
reply - sorry), I suggest we keep with what we have, only because it's
what we already have amongst options that appear equal to my eyes.
>> 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...
--
Ryan Lee ryanlee_at_w3.org
W3C Research Engineer +1.617.253.5327
http://simile.mit.edu/
Received on Thu Jul 21 2005 - 03:06:35 EDT