- 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