Hi Andy,
I've got the idea of projection. The bug has been fixed. I'll deliver
more tests.
Thanks!
Qihong
On Tue, Aug 11, 2015 at 4:52 PM, Andy Seaborne <a...@apache.org> wrote:
> On 11/08/15 09:11, Qihong Lin wrote:
>>
>> hi Andy,
>>
>> I'll further enrich the test data and add JUnit tests in TestAPI for
>> better coverage.
>>
>> I'm thinking of the problem you mentioned. In fact, there're 2 types
>> of query strings:
>> a) Query String without Construct Quad, e.g. "CONSTRUCT { ?s ?p ?o }
>> WHERE { ?s ?p ?o }";
>> b) Query String with Construct Quad, e.g. "CONSTRUCT { ?s ?p ?o GRAPH
>> :g1 { :s1 ?p :o1 } } WHERE { ?s ?p ?o }"
>> Also, the users can choose to execute 2 kinds of query methods:
>> 1) Iterator<Triple> execTriples()
>> 2) Iterator<Quad> execQuads()
>>
>> These make 4 cases:
>> a)+1): No problem, original ARQ construct query
>
>
> and execContructQuads returns quads with the default graph set.
> and the execContructDataset contains a dataset with triples in the default
> graph.
>
>> b)+2): No problem, new construct quad query
>
> Yes
>>
>> a)+2): The result quads are in the default graph? Or just throw
>> exception saying the query string not working with the query method?
>
>
> Quads, with graph field being for the default graph.
>
>> b)+1)(you mentioned): The result triples contain only the "?s ?p ?o"
>> part, ignoring construct "GRAPH :g1 { :s1 ?p :o1 }"? Or just throw
>> exception saying the query string not working with the query method?
>> Could you please tell me your opnions about the last 2 cases?
>
>
> The effect should be triples in the default graph (?s ?p ?o). it's a
> projection. The same happens if you parse, say TriG, into a model : just
> the default graph is seen.
>
> There is a general abstraction here (CONSTRUCT template to dataset). It's a
> matter of how to handle the two API forms that deal with a restricted form
> (triples/model). Seeing the default graph in each case is the way to deal
> with it.
>
> Andy
>
>
>>
>> regards,
>> Qihong
>>
>> On Mon, Aug 10, 2015 at 9:58 PM, Andy Seaborne <a...@apache.org> wrote:
>>>
>>> I've managed to integrate the latest updates.
>>>
>>> The scripted ones look, at first glance OK, but the data isn't very rich.
>>>
>>> Also, please can we have some API tests in "TestAPI". These are JUnit
>>> tests
>>> in java. These should be have comprehensive coverage.
>>>
>>> I also tried out execConstructTriples(), I noticed that the result is
>>> from
>>> all graphs. When just triples are asked for, only those in the default
>>> graph should be returned. Template.getTriples calls Quad.asTriple. But
>>> it
>>> needs to deal with just the default graph, and c can't rely on
>>> Quad.asTriple.
>>>
>>> Andy
>>>
>>>
>>> On 10/08/15 12:44, Qihong Lin wrote:
>>>>
>>>>
>>>> Hi,
>>>>
>>>> I've enriched the syntax tests with "short form" and "default graph"
>>>> cases.
>>>>
>>>> For execution tests, I add the test support in QueryTest for construct
>>>> quad with the scripts files and data files in TRIG (see
>>>> jena-arq/testing/ARQ/Construct/*.trig). I think construct quad should
>>>> be part of the construct of ARQ. So I add the execution tests in
>>>> jena-arq/testing/ARQ/Construct/manifest.ttl.
>>>>
>>>> The fuseki part of construct quad has been implemented (not committed
>>>> yet). I'll submit the code as soon as the PR 89 [1] being merged.
>>>> Anything to be improved for PR 89 from your reviews?
>>>>
>>>> regards,
>>>> Qihong
>>>>
>>>> [1] https://github.com/apache/jena/pull/89
>
>
