[
https://issues.apache.org/jira/browse/COMMONSRDF-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15854070#comment-15854070
]
ASF GitHub Bot commented on COMMONSRDF-55:
------------------------------------------
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).
> Stream of Jena quads use wrong IRI for default graph
> ----------------------------------------------------
>
> Key: COMMONSRDF-55
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-55
> Project: Apache Commons RDF
> Issue Type: Bug
> Components: jena
> Affects Versions: 0.3.0
> Reporter: Stian Soiland-Reyes
> Assignee: Stian Soiland-Reyes
> Fix For: 1.0.0
>
>
> See https://travis-ci.org/apache/commons-rdf/builds/195548479
> {code}
> org.apache.commons.rdf.jena.DatasetJenaTest
> streamLanguageTagsCaseInsensitive(org.apache.commons.rdf.jena.DatasetJenaTest)
> Time elapsed: 0.012 sec <<< FAILURE!
> java.lang.AssertionError: expected:<<http://example.com/s1>
> <http://example.com/greeting> "Hello"@EN-GB <urn:x-arq:DefaultGraph>.> but
> was:<<http://example.com/s1> <http://example.com/greeting> "Hello"@en-GB .>
> {code}
> Jena uses the IRI `<urn:x-arq:DefaultGraph>` internally to represent the
> default graph within datasets - we need to recognize that on the way out of a
> `JenaDatasetImpl.stream()` and possibly in the `asQuad(JenaQuad)` converter
> and replace it with `Optional.empty()` so the default graph appears the same
> across implementations.
> The `AbstractDatasetTest` should be augmented to do more tests on the
> default graph, including `.stream()`, `.iterate()`, `.contains()` and
> `.remove()`1.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
