David Karger wrote:
> My point was that we should think carefully about what a "legitimate"
> fresnel intepreter MUST do versus what it SHOULD do. I want to be
> careful that we do not force to many inference requirements into the
> must category, because that will make it much harder to actually build
> interpreters. Working from the example below, I think it is fine to
> state subtype relationships, but it is ok for certain fresnel
> interpreters to ignore them. I presume most will follow. On the other
> hand, probably fewer will pay attention to eg "equivalence" links.
I entirely agree. w.r.t must vs. should. I do not expect all Fresnel
processors to take into accont subtype/subclass relationships, so this
definitely falls in the should category. I will update the FSL working
draft to reflect this.
As far as "equivalence" is concerned, I've thought about adding
awareness of this in FSL, but right now we do not support any such
notion. That would be interesting though, but againthis would fall (even
more) in the "should" category. What are the opinions on supporting
"equivalence" in FSL?
> Emmanuel Pietriga wrote:
>
>>
>>> How about we instead maintain the standard semantic web perspective
>>> that inference is desirable but never guaranteed---namely, when
>>> someone writes into fresnel that the lens applies to a type, the
>>> proper inference is that it also applies to subtypes, but since
>>> inference is never guaranteed to work, there may be some
>>> implementations that will fail to "notice" that a given subtype
>>> relationship applies.
>>
>>
>>
>> I am not sure I understand your position. Are you questioning the
>> whole idea of allowing Fresnel programmers to explicitly say whether a
>> type test matches subclasses/subproperties or not? Or are you just
>> questioning which behavior should be the default?
>>
>>
>>
>>
>>
>>
>>
>>> Emmanuel Pietriga wrote:
>>>
>>>> Emmanuel Pietriga wrote:
>>>>
>>>>> Ryan Lee wrote:
>>>>> > Chris Bizer wrote:
>>>>> >
>>>>> >> Hi Emmanuel,
>>>>> >>
>>>>> >> I think this is definitively useful behaviour. The question
>>>>> which is
>>>>> >> coming
>>>>> >> to my mind is, what should be the default behaviour?
>>>>> >>
>>>>> >> Should the query engine by default use subproperty and subclass
>>>>> >> relationships, which I guess will slow it significantly down?
>>>>>
>>>>> It will slow it down, but I'm not sure to what extent (this will
>>>>> partially depend on the complexity of class and property hierarchies).
>>>>> But I would say that the language's expressive power and ease of
>>>>> use is
>>>>> more important than implementation/performance issues (though these of
>>>>> course have to be taken into account).
>>>>>
>>>>>
>>>>>
>>>>> >> My understanding is that Fresnel is about visualizing
>>>>> materialized RDF
>>>>> >> graphs and inferencing (if needed) is done on a lower layer before
>>>>> >> Fresnel
>>>>> >> gets involved.
>>>>>
>>>>> Yes indeed. But if you think about the Fresnel presentation
>>>>> designer, it
>>>>> can be very convenient to write a single lens that will apply to a
>>>>> class
>>>>> and all its subclasses. If you don't have subclass/subproperty
>>>>> inferencing at the FSL level, you have to define as many lens
>>>>> domains as
>>>>> there are subclasses. And the lens won't apply to subclasses that the
>>>>> stylesheet designer did not know of (or forgot).
>>>>>
>>>>>
>>>>> > This is the same approach SPARQL is also taking.
>>>>> >>
>>>>> >> Thus I think (if at all) you should tell the engine explicitly
>>>>> to do
>>>>> >> inferencing using '!' and the none-inferencing case should be the
>>>>> >> default.
>>>>> >
>>>>> >
>>>>> > Agreed.
>>>>>
>>>>> Ok, so we all seem to agree that this is a useful feature. We only
>>>>> disagree on whether this should be the default behaviour and on the
>>>>> syntax.
>>>>>
>>>>> I'm okay witht the idea of having the subclass/subproperty-unaware
>>>>> version the default, but then I'm not sure I like "!" as the notation
>>>>> for the subclass/subproperty-aware version. I can live with it, that's
>>>>> mostly a question of personal taste, but if anybody has another
>>>>> idea for
>>>>> how to convey this, please submit it. Unless everybody's happy with
>>>>> the
>>>>> ! notation, in which case we'll leave it as such.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Coming back to this issue after a while, here's what I am about to do:
>>>>
>>>> - default type tests will be subclass/subproperty-unaware
>>>> - symbol ^ will be used as a type test prefix to denote a
>>>> subclass/subproperty-aware type test.
>>>>
>>>> So:
>>>>
>>>> */ex:prop1/*
>>>>
>>>> would only select paths that go through ex:prop1 properties, but not
>>>> subproperties of ex:prop1,
>>>>
>>>> while:
>>>>
>>>> */^ex:prop1/*
>>>>
>>>> would select paths that go through ex:prop1 properties or
>>>> subproperties of it.
>>>>
>>>>
>>>>
>>
>>
>
--
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 Wed Nov 16 2005 - 07:04:14 EST