- From: Steve Harris <steve.harris@garlik.com>
- Date: Sun, 7 Mar 2010 14:38:56 +0000
- To: Lee Feigenbaum <lee@thefigtrees.net>
- Cc: Andy Seaborne <andy.seaborne@talis.com>, Paul Gearon <gearon@ieee.org>, Gregory Williams <greg@evilfunhouse.com>, SPARQL Working Group WG <public-rdf-dawg@w3.org>
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 <lee@thefigtrees.net> 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<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 14:40:15 UTC