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 Mon, 06 Feb 2017 14:22:49 GMT
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 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