Re: AW: FSL and subclass/subproperty relationships

From: David Karger <karger_at_mit.edu>
Date: Sun, 30 Oct 2005 01:39:33 -0400

"Exposing" subtyping to the user to decide whether to use it or not
seems strange to me. Also good source of bugs when people try to use
other lenses recursively. 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.

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 Sun Oct 30 2005 - 05:34:14 EST