Re: ISSUE-54: Do we need (descriptions of) property functions in SD? Is this in scope for us?

On 3/5/2010 12:29 PM, Andy Seaborne wrote:
>
>
> On 05/03/2010 12:35 AM, Lee Feigenbaum wrote:
>> On 3/3/2010 10:56 AM, Paul Gearon wrote:
>>> On Tue, Mar 2, 2010 at 4:07 PM, Gregory
>>> Williams<greg@evilfunhouse.com> wrote:
>>>
>>> <snip/>
>>>
>>>> Paul, Andy, Steve,
>>>>
>>>> I'd like to try to push the property function issue forward and see
>>>> if we can't reach some sort of consensus. Andy and Paul seem to see
>>>> this as an easy thing to include that would have pragmatic benefits
>>>> while Steve is worried about not being able to define what a property
>>>> function is and not being able to defend it as in-scope. Have I got
>>>> that basically right? Is there any sort of compromise to reach here?
>>>
>>> That covers my point of view, yes.
>>
>> Paul & Andy,
>>
>> Steve & I -- at least -- are concerned that there is no useful way to
>> include service description vocabulary for property functions without
>> defining what a property function is. And I think we all agree that the
>> task of defining what a property function is is out of scope for the
>> group at this time.
>>
>> Speaking for myself, I'm concerned that any text we may come up with
>> will need to be pretty vague, and as such will not be at all testable /
>> will not really help with interoperability. Interoperable
>> implementations will require knowledge outside the spec -- it will
>> require people to know (intrinsically?) what a property function is.
>> That doesn't sound like a healthy spec. to me.
>>
>> I'd suggest that the best way forward is for a proponent of including
>> this to suggest spec. text - with concrete text, perhaps Steve and I can
>> better explain our concerns and/or withdraw our concerns if the text
>> assuages our worries. Would someone be willing to do this?
>>
>> Lee
>
> We already have sd:languageExtension, subproperty of sd:feature, which
> does not define what an "extension" is. I read that as saying deference
> the range and see what you get - it's not the general concept of an
> extension that matters but the details of each specific one. In this
> aspects, property functions are similar; what matters is the detail of
> each one and the global naming. Custom filter functions are the same -
> there we know where in a query they can be used.
>
> sd:propertyFeature rdfs:subClassOf sd:feature ;
> rdfs:domain sd:Service ;
> rdfs:label "Releates an instance of sd:Service to a resource
> representing an implemented feature to the SPARQL Query or Update
> language that is accessed by using the named property." .
>
> I choose the name sd:propertyFeature as explained below:

Andy, thanks for this. I could live with this definition and would not 
stand in the way of including it. In particular, I think that defining 
it basically as a feature that provides extended functionality and is 
driven by a predicate is a good way to approach this.

I'd like ot hear what Steve thinks, as well as anyone in the WG that 
hasn't registered an opinion on this yet to date.

Lee


> Let's look at 3 examples in
>
> rdfs:member
>
> This may be a property function or it may be inferred and loaded into
> the data - both ways of doing it make sense. The need is saying "I
> support the rdfs:member feature".
>
> list:member
>
> So this is like RDFS member except it access lists. It isn't a simple
> case of single-triple inference but it might be done and materialized or
> calculated. The need is saying "I support the list:member feature".
>
> These two are features - whether they are property functions or data is
> neither here nor there. All it says is the feature is accessible by
> using certain property.
>
> text:matches
>
> This one is tricky but it's also important - access to different index
> types. This is access to a free text index and one would expect that
> variables are being bound (else a filter function works). Variable
> binding is the key feature of the property function.
>
> If we had multi-value returns from function calls, together with
> subSELECT / assignment we could have done without them.
>
>
> So I think the key concept is a feature accessed by using a property
> that behaves like matching.
>
> Andy
>
> Aside:
>
> rdfs:domain sd:Service
>
> like filter functions, it would be nice to be able to describe
> individual graphs within a service.
>

Received on Sunday, 7 March 2010 13:25:35 UTC