Github user stain commented on the issue:
https://github.com/apache/commons-rdf/pull/32
The Commons RDF marker for the default graph (as of today) is
`Optional.empty()` and not an `RDFNode` (and thus can only be used in the
`Quad.getGraphName()` position).
There are four boundaries that can create Commons RDF Quad instances from
Jena:
* **Retrieving:**
[Dataset.stream()](https://commons.apache.org/proper/commons-rdf/apidocs/org/apache/commons/rdf/api/Dataset.html#stream--),
`.iterate()` and friends
* **Adapting:**
[JenaRDF.asQuad(jenaQuad)](https://commons.apache.org/proper/commons-rdf/apidocs/org/apache/commons/rdf/jena/JenaRDF.html#asQuad-org.apache.jena.sparql.core.Quad-)
* **Creating:**
[JenaRDF](https://commons.apache.org/proper/commons-rdf/apidocs/org/apache/commons/rdf/jena/JenaRDF.html#createQuad-org.apache.commons.rdf.api.BlankNodeOrIRI-org.apache.commons.rdf.api.BlankNodeOrIRI-org.apache.commons.rdf.api.IRI-org.apache.commons.rdf.api.RDFTerm-)
with a graph `IRI` adapted from a Node using
[JenaRDF.asRDFTerm(Quad.defaultGraph)](https://commons.apache.org/proper/commons-rdf/apidocs/org/apache/commons/rdf/jena/JenaRDF.html#asRDFTerm-org.apache.jena.graph.Node-)
* ..in worst case, `IRI` from `RDF.createIRI("urn:x-arq:DefaultGraph")
* **Parsing:** JenaRDFParser - which uses JenaRDF.asQuad (experimental)
I think we MUST do the _Retrieving_ - triples in the default graph
according to the RDF 1.1 should still be in the default graph according to
[org.apache.commons.rdf.api.Quad](https://commons.apache.org/proper/commons-rdf/apidocs/org/apache/commons/rdf/api/Quad.html)
- importantly it must be `.equals()` an equivalent quad statement in a
different implementation. I think we all agree on this.
Similarly _Parsing_ we MUST handle - at least when it's no longer
experimental.
The question is how helpful we should be in the other cases. If someone is
_adapting_ a Jena Quad, then I think it also MUST convert to `Optional.empty()`
although it keeps the original Jena quad underneath, which can distinguish
between the two default variants, if needed.
Now that leaves _creating_ which is a bit more speculative - we don't know
where the graph `IRI` comes from, and other `RDF` implementations do of course
not do anything special with `urn:x-arq:DefaultGraph`. However it is unlikely
that such an IRI would be used in a non-Jena context.
So here are three options for what `RDF.createQuad(g,s,p,o) should do if g
is `urn:x-arq:DefaultGraph` or `urn:x-arq:DefaultGraphNode`:
1) Always recognize `urn:x-arq:DefaultGraph` and friends (either by
comparing of IRI string against the `Quad.defaultGraph` and
`Quad.defaultGraphNode` constants (this PR), or adapting/unwrapping to the
equivalent Jena `Node` and then checking with `Quad.isDefaultGraph(Node)`
(might be less efficient)
2) Only recognize if it is a `org.apache.commons.rdf.jena.JenaIRI` instance
by using `Quad.isDefaultGraph(iri.asJenaNode())`
3) Never recognize it, IRI will be left as-is. Insertion of such a `Quad`
to a Jena-backed Dataset will then have different semantics then in other
`Dataset`s
I think it's an edge-case with people creating it by hand from the IRI
string with `RDF.createIRI()` - particularly with a non-Jena `RDF` instance,
although that could be the case in queries against the union graph. (but that
would only be in SPARQL world, right?).
However it might be conceivable that `Node` from `Quad.defaultGraph` is
used in Jena-centric code that adds Commons RDF at the edge.
Boundaries from Commons RDF to Jena are simpler, as we just always use
`urn:x-arq:DefaultGraph` (not `null`!) except where there's a pre-existing Jena
`Quad` which is left as-is.
---
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
