On 15/04/2021 06:09, Bögershausen, Merlin wrote:
Hi all,
Hi Merlin, good to hear from you.
At $-work, we are building an application on top of Apache Jena. After three
years, it slowly comes together, and the first role out will be soon. YAY, one
Apache Jena Business Application more! ;-)
:-)
Nevertheless, we still frequently stumble over the API. Here are two examples I
remember directly.
Graph defines contains(Triple) and contains(Node, Node, Node), same for find.
But only delete(Triple), add(Triple) and remove(Node,Node,Node). Why no comfort
variants for delete, add and remove?
contain() and remove() are pattern based - you can specify an ANY.
contains(<s>,<p>,ANY), remove (ANY,<p>,ANY)
"delete" and "add" are not.
There used to be "TripleMatch" but it turns out that distinguishing
matching from data is more trouble than it's worth when you get beyond
fine-grained Graph.find work (i.e. RDQL and now SPARQL).
The DatasetGraph API has add/delete in both quad and 4 argument forms
but it can be a mixed benefit because of ending up creating small,
temporary objects. But the JVM is better at that nowadays.
The DatasetGraph API calls "remove" "deleteAny" to be clearer as to the
potential for a lot of data disappearing.
We can add default methods for add/3 and delete/s if the consensus is to
do so.
Created:
https://issues.apache.org/jira/browse/JENA-2091
(JENA-2090 is Graph.stream)
Graph.contains work with matches because the same holds for Graph.find a "contains
exactly" question is not answerable. With exactly we mean Graph.containsExactly(t1)
is true iff the graph contains a triple t2 with t1.equals(t2). Contains works differently
compared to Set.contains, but why? See snippet-1
In a memory graph, it's value based.
Node.equals (same RDF term) vs Node.sameValueAs.
Unfortunately, other storages vary because value-based and storing
exactly as input are competing.
Canonicalizing on input is the best way for applications to deal with this.
This is now legacy - applications built on the the Model API would be
affected. if we changed the basic in-memeory graph implementation.
GraphPlain is a wrapper to put back "same term" semantics.
To be honest, we can live with a "because nobody requested it this way" :D If
so, I would like to contribute our findings for version 4.0. I would like to see Apache
Jena profit from library user view or otherwise get enlightened.
Out of curiosity, do you use the Model API?
Best Merlin
Andy
Code Snippet-1:
var o1 = NodeFactory.createLiteral("0", XSDDatatype.XSDdouble);
var o2 = NodeFactory.createLiteral("0.0", XSDDatatype.XSDdouble);
var t1 = Triple.create(s, p, o1);
var t2 = Triple.create(s, p, o2);
var graph = graph.add(t1); // GraphFactory.createDefaultGraph() omitted
t1.equals(t2); // false because o1 != o2
graph.contains(s, p, o2); // true because (s,p,o1) matches
graph.contains(t2); // true, even if t2 is not in the graph
Node.equals vs Node.sameValueAs.
