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 infrastruct...@apache.org or file a JIRA ticket with INFRA. --- --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org