commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (COMMONSRDF-55) Stream of Jena quads use wrong IRI for default graph
Date Mon, 06 Feb 2017 14:23:42 GMT

    [ 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)

Mime
View raw message