[
https://issues.apache.org/jira/browse/COMMONSRDF-72?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16280180#comment-16280180
]
Stian Soiland-Reyes commented on COMMONSRDF-72:
-----------------------------------------------
I think this is quite difficult to expect from Commons RDF as there is no
requirement of containment.
For {{RDFTerm.getGraph}}:
* The term (perhaps except for {{BlankNode}}) can be used in any graph/dataset
in any implementation - how is it to be informed of this?
* An RDFTerm can be used in many triples/quads (which can be in many graphs and
datasets.)
* An RDFTerm can be used independent of any graph or dataset
* Keeping backlinks adds to unnecessary memory usage per RDFTerm object
* Two RDFTerms created in different ways (and even in different
implementations) with say the same IRI are {{.equals()}}. Would they return the
same list of graphs/dataset no matter how they were constructed? (How?)
{{Triple.getGraph()}} / {{Quad.getDataset()}}:
* (Same as above, e.g.)
* A Triple or Quad can be used outside a Graph/Dataset
* A Triple/Quad can be used in many Graph/Datasets across implementations
* ..
*
{{Graph.getRDF()}} / {{Dataset.getRDF()}}:
* I can see this one is useful - it could just give the preferred RDF factory
to use for efficiency reasons (which may or may not be the {{RDF}} used to make
the Graph instance).
Could you make a new ticket to suggest Graph.getRDF and Dataset.getRDF?
> Pointers to containers (Graph/RDF)
> ----------------------------------
>
> Key: COMMONSRDF-72
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-72
> Project: Apache Commons RDF
> Issue Type: New Feature
> Components: api
> Reporter: Marco Brandizi
>
> I'm writing a few utilities to ease the use of commons RDF, starting from a
> library I already have for Jena
> ([here|https://github.com/marco-brandizi/rdfutils/blob/master/rdfutils-core/src/main/java/info/marcobrandizi/rdfutils/GraphUtils.java]
> the interface).
> It would be quite useful to have container links in interfaces like Graph
> (Graph.getRDF()) or RDFTerm (RDFTerm.getGraph()). Methods that need to go
> back to their container to do something (e.g., add some property/value
> statement to a given IRI object, using the graph it comes from) wouldn't need
> to receive too many parameters (new triples would be added to
> subject.getGraph() and new IRI properties would be generated using
> subject.getGraph().getRDF() ).
> Jena uses this approach (e.g., RDFNode has getModel() ).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
