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

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:


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 Friday, 5 March 2010 17:29:57 UTC