[jira] [Closed] (COMMONSRDF-72) Pointers to containers (Graph/RDF)

["Stian Soiland-Reyes (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/COMMONSRDF-72?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stian Soiland-Reyes closed COMMONSRDF-72.
-----------------------------------------
    Resolution: Won't Fix

Closing as Won't Fix as the RDFTerm/Triple/Quad objects can live independent of potentially multiple graph/dataset backends.

Adding Graph.getRDF() and Dataset.getRDF() could be useful, but I think that should be a new issue.

> 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
>            Assignee: Stian Soiland-Reyes
>            Priority: Major
>
> 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
(v7.6.3#76005)