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 Thu, 02 Feb 2017 18:07:51 GMT

    [ https://issues.apache.org/jira/browse/COMMONSRDF-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15850251#comment-15850251
] 

ASF GitHub Bot commented on COMMONSRDF-55:
------------------------------------------

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.


> 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