On 07/04/16 14:06, Stian Soiland-Reyes wrote:
Good point about base class equality.
However we have the luxury of using interfaces and knowing existence of the
Quad interface from Triple in advance. (We don't need to support Quint or
Sixt, and implementations of T/Q can choose freely if their implementations
are subclasses or not - we have already enforced different impls to have
compatible .equals() and .hashCode().
The reason is not interface vs classes. It is a feature of value-based
equality in Java.
The contract for Triple puts the fields into the equality.
"""
Two Triples are equal if and only if their {@link #getSubject()},
{@link #getPredicate()} and {@link #getObject()} are equal.
"""
and that related to a set of triples being a graph.
We could have defined Triple.equals as a default method. Shame it can't
be final.
So we could alternatively keep Quad subclass of Triple, and modify
Triple.equals() to say that if other is a Quad, then it is only equal to
the Triple if it's .getGraph() Optional is not present. (This would make
sense as if you asked the Dataset subclass of Graph if it had the Triple,
it should match against the equivalent Quad in the default graph)
Quad is not a sub or super class of Triple in RDF. It is separate and
different. It is at best a pair (triple, term).
For getGraph() neutral comparison you would need to do
asTriple().equals(otherQuad.asTriple())
Yuk.
.equals. gets everywhere.
Triple t1 = quad1
Triple t2 = quad2
Graph g ;
g.add(t1)
g.add(t2)
Size one or two?
Set<Triple> s ;
s.add(t1)
s.add(t2)
Size one or two?
t3 = Triple(q1.s, q1.p, q1.o)
find(?,?,?).distinct() needs .equals.
Incidentally the hashCode of Optional.empty() is 0, so a Quad with the
default graph can have the same hashCode() as the equivalent Triple as long
if we add getGraph() last.
I'll prepare two competing branches and we can have a competition :))
Declined.
On 7 Apr 2016 13:32, "Andy Seaborne" <[email protected]> wrote:
On 06/04/16 18:44, Stian Soiland-Reyes wrote:
Right, different .equals.. And I don't think we would want to have
hierarchical .equals as you show, that could lead to weird collection
behaviour. Also the Quad should probably include the Graph IRI in its
.hashCode()
It's not specific to RDF. It's a Java thing when .equals is based on
fields, not object identity.
(discussions on StackOverflow)
e.g.
http://www.javapractices.com/topic/TopicAction.do?Id=17
http://stackoverflow.com/questions/13162188/java-equals-method-in-base-class-and-in-subclasses
Perhaps Quad just happens to look like Triple, without the same interface
If you mean same names of methods: getGraph, getsubject, getPredciate,
getObject then yes to that.
And an asTriple to project it to a triple.
Andy
(or a TripleLike super-interface, SubjectPredicateObject ?). Quad can have
a .asTriple() method? In which case that Triple
wotxnSafeExtendedIteratoruld .equals, even between
Q1.asTriple() and Q2.asTriple().
Sounds like Quad needs crafting out as a branch so we can see the
implications. Given the quad formats and that JSON-LD is popular (although
@graph isn't :) I think this is within scope of Commons RDF (Commons
Dataset ? ;)
How do the equivalent of Quads and Triple differ in the different
frameworks? What about Dataset and Graph?
On 6 Apr 2016 14:09, "Andy Seaborne" <[email protected]> wrote:
On 04/04/16 16:15, Stian Soiland-Reyes wrote:
This raises good questions about Quads which I think we should also
think about - e.g. if we imply make a Dataset as a subclass of Graph,
and Quad a subclass of Triple, then does .size() and .contains()
relate to only the default graph or all the quads?
Triples and Quads are different.
I think .equals brings this out: Java .equals must be transitive.
Q1: <g1> <s> <p> <o>
Q2: <g2> <s> <p> <o>
T: <s> <p> <o>
Q1 equals T . T equals Q2
but not Q1 equals Q2.
So Set<Triple> ???
Andy
