Re: AW: FSL and subclass/subproperty relationships

From: David Karger <karger_at_mit.edu>
Date: Tue, 15 Nov 2005 13:58:17 -0500

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.

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.
>>>
>>>
>>>
>
>
Received on Tue Nov 15 2005 - 20:07:00 EST