Github user stain commented on the issue:
https://github.com/apache/commons-rdf/pull/32
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:
```java
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("http://example.com/";);
Quad q1 = jena.createQuad(defaultS, ex, ex, ex);
assertFalse(q1.getGraphName().isPresent());
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](https://github.com/apache/commons-rdf/blob/0.3.0-incubating/api/src/main/java/org/apache/commons/rdf/api/RDF.java#L234)
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 [email protected] or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
