W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > January to March 2010

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

From: Andy Seaborne <andy.seaborne@talis.com>
Date: Fri, 05 Mar 2010 17:29:35 +0000
Message-ID: <4B913F7F.60603@talis.com>
To: Lee Feigenbaum <lee@thefigtrees.net>
CC: Paul Gearon <gearon@ieee.org>, Gregory Williams <greg@evilfunhouse.com>, Steve Harris <steve.harris@garlik.com>, SPARQL Working Group WG <public-rdf-dawg@w3.org>

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


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".


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.


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.



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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:59 UTC