- From: Gregory Williams <greg@evilfunhouse.com>
- Date: Mon, 8 Feb 2010 16:44:07 -0500
- To: Andy Seaborne <andy.seaborne@talis.com>
- Cc: SPARQL Working Group <public-rdf-dawg@w3.org>
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. 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. > 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? 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. Does anyone want to argue for property functions' explicit INCLUSION in service descriptions? .greg
Received on Monday, 8 February 2010 21:44:40 UTC