- From: Steve Harris <steve.harris@garlik.com>
- Date: Wed, 25 Apr 2012 19:54:40 +0100
- To: Sandro Hawke <sandro@w3.org>
- Cc: public-rdf-wg WG <public-rdf-wg@w3.org>
On 25 Apr 2012, at 19:49, Sandro Hawke wrote: > On Wed, 2012-04-25 at 19:36 +0100, Steve Harris wrote: >> On 25 Apr 2012, at 14:28, Sandro Hawke wrote: >> ... >>>> Hm. I am not sure I understand this restriction. It forces the user to come up with a URI or a blank node for no good reason. Why is it a problem to say that if I say: >>>> >>>> >>>> @union . >>>> { a b c } >>>> d { e f g } >>>> h { i j k } >>>> >>>> then the default graph is >>>> >>>> { a b c . >>>> e f g . >>>> i j k . >>>> } >>>> >>>> What is wrong with that? It is only a shorthand... >>> >>> Yeah, I suppose it's probably okay. I was thinking of union datasets >>> as a somewhat different kind of dataset. >>> >>> If you loaded that into 4store, it would have to make up a graph name, >>> but maybe that's fine. >> >> It has to anyway, it's a quad store*. > > Good point. > >> But in any case, the idea of @union is antithetical to the way these systems are used, see my other mail on the subject. > > Please note the meeting minutes or my summary -- as clarified during the > meeting, @union is just syntactic sugar in TriG, shorthand for having to > repeat all the triples in all the named graphs. > > Does that change your mind about it, at all? Not really. The implication of that would be that if I see @union I have to disable an optimisation that's designed specifically to handle that (common) case. I don't see how it makes ay sense to allow a data format to specify that behaviour, it should normally be up to the query author. - Steve -- Steve Harris, CTO Garlik, a part of Experian 1-3 Halford Road, Richmond, TW10 6AW, UK +44 20 8439 8203 http://www.garlik.com/ Registered in England and Wales 653331 VAT # 887 1335 93 Registered office: Landmark House, Experian Way, NG2 Business Park, Nottingham, Nottinghamshire, England NG80 1ZZ
Received on Wednesday, 25 April 2012 18:55:12 UTC