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

Yes, I'm ok with this too.

Minor point: I'm not convinced that there's any reason to have a  
separate sub property, unless the same URI is sometimes used as a  
property, and sometimes as a function?

- Steve

Sent on the move.

On 7 Mar 2010, at 13:24, Lee Feigenbaum <> wrote:

> 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<> 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 14:40:15 UTC