commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From stain <...@git.apache.org>
Subject [GitHub] commons-rdf issue #32: COMMONSRDF-55: Handle Jena's urn:x-arq:DefaultGraph a...
Date Thu, 02 Feb 2017 18:06:57 GMT
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message