Github user stain commented on the issue:
https://github.com/apache/commons-rdf/pull/32
The thing is a Commons RDF `JenaQuad` has in a way two feet into Jena - the
underlying Jena `Quad` as well as the underlying `Node` instances (which would
be wrapped as `RDFTerm` instances).
So the challenge is that it's also possible to make a Commons RDF
`JenaQuad` using both adapting a quad from Jena (as when being retrieved from
the Dataset), as well as composed from `RDFTerm` instances with the
`JenaRDF.createQuad(g,s,p,o)` method -- such constructing will currently keep
fields for the Commons RDF wrappers of the `RDFTerm`s optional(g),s,p,o, and
only make the underlying Jena-backed `Quad` on-demand on first call to
[asJenaQuad](https://github.com/apache/commons-rdf/blob/0.3.0-incubating/jena/src/main/java/org/apache/commons/rdf/jena/impl/AbstractQuadLike.java#L92).
Commons RDF methods like `.equals()` and `.hashCode()` then use the
individual graph/subject/predicate/object `RDFTerm` fields which are always
initialized - thus from the Commons RDF side in a way the Quad object is
ready-already, while it's Jena-nature might be incomplete until needed (e.g.
being added to a Dataset).
Currently the constructor from a JenaQuad will unwrap to create the
[RDFTerm
g/s/p/o](https://github.com/apache/commons-rdf/blob/0.3.0-incubating/jena/src/main/java/org/apache/commons/rdf/jena/impl/AbstractQuadLike.java#L74)
-- with this PR this would check Quad.isDefaultGraph() before unwrapping the
graph name.
It could in theory be done the other way, to keep the Jena-backed
org.apache.jena.sparql.core.Quad as the master backend field, and rather
generate the `RDFTerm` wrappers on demand, in which case first call to
`getGraphName()` would simply check `isDefaultGraph()` -- but it would make it
trickier to keep `AbstractQuadLike` common for both `Quad` and `Triple`, as
Jena's `Quad` does not have a common superclass with Jena's `Triple`, there
would be two alternate fields for the master (or a more complicated abstract
class hierarchy).
---
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
