- From: Andy Seaborne <andy.seaborne@talis.com>
- Date: Fri, 05 Mar 2010 17:29:35 +0000
- 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 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