commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stian Soiland-Reyes (JIRA)" <>
Subject [jira] [Commented] (COMMONSRDF-72) Pointers to containers (Graph/RDF)
Date Wed, 06 Dec 2017 13:34:00 GMT


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:
>             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|]
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

View raw message