Re: SPARQL TC today cancelled.

On 08/02/2010 9:44 PM, Gregory Williams wrote:
> Andy,
>
> Based on this, did you have a specific preference for their inclusion in the service description work?
>
> On Feb 8, 2010, at 11:03 AM, Andy Seaborne wrote:
>
>> >  A property function shouldn't really be any different from any other piece of vocabulary supported.  But the pragmatically, people don't quite think of them in the same way as properties and sometimes for evaluation reasons it does matter.
> I'm leaning towards the idea that they*shouldn't*  be different, but they do seem to be. For one, SPARQL (1.0) explicitly talks about extension functions, but while it might allow property functions (leaving the door open for them via extended bgp matching), I don't believe it ever discusses them directly.

It doesn't - extension functions are for filters.  Property functions 
are not a feature of the spec.

> Also, I've never been totally comfortable with them as I've never seen a thorough explanation of how they're meant to work (either at the algebra level or just an intuitive description). It's possible such an explanation exists, but if so I've missed it.

They are supposed to be just properties - an engine might just happen to 
match them by some different custom code but it's (ideally) invisible. 
It's supported vocabulary really.

It's still BGP matching with simple entailment or whatever other level 
is provided - it's orthogonal to entailment)

>
>> >  With update coming along, they are different in that you typically can't assert them.
> That's an interesting point I hadn't thought of. Do systems that support property functions raise an error if you try to load data that asserts a triple with a special predicate? What of the dynamic property functions in ARQ using java: URIs?

<java:classname> is, let's face it, a rather "pragmatic" feature :-) 
They should have real http URIs.

No error is currently raised - it could only be a warning anyway.
The property function might be registered or unregistered after the data 
is added.

>
> This seems like a can of worms spec-wise were we to specifically support the idea of property functions: no formal description of their semantics (that I know of), unclear interaction with UPDATE.

The necessary semantics are no more than "I support property function 
<X>" like "I support custom function <F>".  What that means is mostly 
down to the property function itself (e.g. whether it needs argument 
bound - and what that means to execution efficiency).

It's a bit like a vocabulary of one.  There is no need to define the 
concept other than say the property function defines it itself.

	Andy

>
> Does anyone want to argue for property functions' explicit INCLUSION in service descriptions?
>
> .greg

Received on Tuesday, 9 February 2010 00:02:05 UTC