commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (COMMONSRDF-55) Stream of Jena quads use wrong IRI for default graph
Date Mon, 06 Feb 2017 15:08:41 GMT


ASF GitHub Bot commented on COMMONSRDF-55:

Github user stain commented on the issue:
    I guess it's a question of where we put the "inconsistency" barrier. We can probably assume
that in the odd case that `urn:x-arq:DefaultGraph` appear literally in a non-Jena `IRI` or
a non-Jena `Quad` then it must have leaked out of Jena somehow, and will be treated as a real
IRI. It  would magically become the default graph only if such a quad is added to a Jena dataset.
    That would mean we let Commons RDF construction by component of a Jena-based quad preserve
`g` just as in other implementations. 
    With option **(2)** above we would add JenaRDF-specific recognition of the magic IRI if
it happens to be backed by a Jena `Node` (which might even be because it was made from a string).

    It would probably cleaner in Commons RDF for a Quad to magically change only on insertion
to a Jena-backed Dataset, than when making the Quad with a particular back-end - e.g. you
add one quad, but a slightly different one comes back out, which will not be `.equals()` the
inserted one.  This is not very different from stores with inferred rules or blank-node adaptions.
 (Commons RDF Graph/Dataset contracts do not require the exact triple/quad to be returned
back again)
    So I think that would be the semantically cleanest solution, where each `RDF` implementation
behaves the same, but each `Dataset` have slight variation.
    However, it is not given that a `Quad` made with `JenaRDF` will be added to a Jena-based
`Dataset`, but that is probably most likely. It is not given that a `Node` that is `urn:x-arq:DefaultGraph`
was picked from the constant `Node.defaultNode`, but it is likely. It is not given that a
literal Graph IRI `urn:x-arq:DefaultGraph` has leaked from Jena's `Node.defaultNode, but it
is likely.
    Therefore the most pragmatic for Commons RDF users, if semantically slightly unclean,
would be the option (2) as @ajs6f says. It means there would be only this inconsistency barrier:
    RDF simple = new SimpleRDF();
    RDF jena = new JenaRDF();
    IRI defaultS = simple.createIRI("urn:x-arq:DefaultGraph")
    IRI defaultJ = jena.createIRI("urn:x-arq:DefaultGraph") // or jena.asRDFTerm(Node.defaultGraph)
    assertEquals(defaultS, defaultJ);
    IRI ex = jena.createIRI("");
    Quad q1 = jena.createQuad(defaultS, ex, ex, ex);
    assertEquals(defaultS, q1.getGraphName().get()); // as-s
    Quad q2 = jena.createQuad(defaultJ, ex, ex, ex);
    assertFalse(q2.getGraphName().isPresent()); // INCONSISTENT with q1
    assertFalse(q1.equals(q2)); // INCONSISTENT
    (Adding either `q1` or `q2` to a Jena-backed Dataset would both be transferred to q2-form
with `Optional.empty()` on retrieving -- adding them to any non-Jena Dataset implementation
would look like two different quads).
    This will technically break the [SHOULD contract](
of `RDF.createQuad()` which says the parameters should be preserved. 
    >      * The returned Quad SHOULD have a {@link Quad#getGraphName()} that is equal
    >     * to the provided graphName, a {@link Quad#getSubject()} that is equal to
    >     * the provided subject, a {@link Quad#getPredicate()} that is equal to the
    >     * provided predicate, and a {@link Quad#getObject()} that is equal to the
    >     * provided object.
    but I think this is a valid breaking of SHOULD, particularly if we do it only on "our
own" Jena-backed IRIs.

> Stream of Jena quads use wrong IRI for default graph
> ----------------------------------------------------
>                 Key: COMMONSRDF-55
>                 URL:
>             Project: Apache Commons RDF
>          Issue Type: Bug
>          Components: jena
>    Affects Versions: 0.3.0
>            Reporter: Stian Soiland-Reyes
>            Assignee: Stian Soiland-Reyes
>             Fix For: 1.0.0
> See
> {code}
> org.apache.commons.rdf.jena.DatasetJenaTest
> streamLanguageTagsCaseInsensitive(org.apache.commons.rdf.jena.DatasetJenaTest)  Time
elapsed: 0.012 sec  <<< FAILURE!
> java.lang.AssertionError: expected:<<> <>
"Hello"@EN-GB <urn:x-arq:DefaultGraph>.> but was:<<>
<> "Hello"@en-GB .>
> {code}
> Jena uses the IRI `<urn:x-arq:DefaultGraph>` internally to represent the default
graph within datasets - we need to recognize that on the way out of a ``
and possibly in the `asQuad(JenaQuad)` converter and replace it with `Optional.empty()` so
the default graph appears the same across implementations.
> The `AbstractDatasetTest`  should be augmented to do more tests on the default graph,
including `.stream()`, `.iterate()`, `.contains()` and `.remove()`1.

This message was sent by Atlassian JIRA

View raw message