commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From stain <>
Subject [GitHub] commons-rdf issue #32: COMMONSRDF-55: Handle Jena's urn:x-arq:DefaultGraph a...
Date Mon, 06 Feb 2017 15:08:33 GMT
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.

If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at or file a JIRA ticket
with INFRA.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message