[
https://issues.apache.org/jira/browse/COMMONSRDF-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15575202#comment-15575202
]
Stian Soiland-Reyes edited comment on COMMONSRDF-42 at 10/14/16 12:33 PM:
--------------------------------------------------------------------------
I agree on removing the generics of TripleLike and did so - I couldn't remove
it completely from QuadLike as it needs it for the {{Optional<G> graphName}}.
If we're going for a 0.3.0 release now - which is set to introduce
TripleLike/QuadLike/Quad - now is the time to rethink the name of those
{{Like}} interfaces. So I think from Peter's suggestion is that we call them
{{Generalized}} instead:
* GeneralizedTriple
* GeneralizedQuad extends GeneralizedTriple
* Triple extends GeneralizedTriple
* Quad extends GeneralizedQuad,GeneralizedTriple
Views? Personally my favourite is TripleLike, QuadLike - as it highlights that
it doesn't have to actually be a triple that can be added to a graph. So being
able to represent for instance a SPARQL triple pattern with variables could
certainly be "TripleLike", but not really a "GeneralizedTriple".
I don't feel at this stage making {{Quad extends Triple}} is good as it means
we have to add considerations of Quad into {{Triple.equals()}} and it would
raise ambiguity if adding a "Quad-Triple" to a Graph would come out again as a
"Quad-Triple" (equivalent to RDF4J's Statement which would then preserve the
graph name) or as just a "Triple".
You would then get weird equality issues.. where for instance a graph could
claim to contain(quad) (it has a triple with the same s/p/o) - but where you
can't come to the same conclusion if you iterate over it's triples and use
.equals() (as in a HashMap).
Commons RDF can be opinionated on this - having two clear, but distinct views
on graphname-less Triples (in a Graph) and graph-full Quads (in a Dataset) is I
think less confusing that having some fluid distinction.
However, as this project now "own" the core implementations we are somewhat
free to relax Triple.equals in the following version and then introduce Triple
extends Quad - if we so want to.
was (Author: stain):
I agree on removing the generics of TripleLike and did so - I couldn't remove
it completely from QuadLike as it needs it for the {{Optional<G> graphName}}.
If we're going for a 0.3.0 release now - which is set to introduce
TripleLike/QuadLike/Quad - now is the time to rethink the name of those *Like
thing. So I think from Peter's suggestion is that we call them Generalized*
instead:
* GeneralizedTriple
* GeneralizedQuad extends GeneralizedTriple
* Triple extends GeneralizedTriple
* Quad extends GeneralizedQuad,GeneralizedTriple
Views? Personally my favourite is TripleLike, QuadLike - as it highlights that
it doesn't have to actually be a triple that can be added to a graph. So being
able to represent for instance a SPARQL triple pattern with variables could
certainly be "TripleLike", but not really a "GeneralizedTriple".
I don't feel at this stage making {{Quad extends Triple}} is good as it means
we have to add considerations of Quad into {{Triple.equals()}} and it would
raise ambiguity if adding a "Quad-Triple" to a Graph would come out again as a
"Quad-Triple" (equivalent to RDF4J's Statement which would then preserve the
graph name) or as just a "Triple".
You would then get weird equality issues.. where for instance a graph could
claim to contain(quad) (it has a triple with the same s/p/o) - but where you
can't come to the same conclusion if you iterate over it's triples and use
.equals() (as in a HashMap).
Commons RDF can be opinionated on this - having two clear, but distinct views
on graphname-less Triples (in a Graph) and graph-full Quads (in a Dataset) is I
think less confusing that having some fluid distinction.
However, as this project now "own" the core implementations we are somewhat
free to relax Triple.equals in the following version and then introduce Triple
extends Quad - if we so want to.
> Add GeneralizedTriple/Quad interfaces to api (and avoid TripleLike)?
> --------------------------------------------------------------------
>
> Key: COMMONSRDF-42
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-42
> Project: Apache Commons RDF
> Issue Type: Wish
> Components: api
> Affects Versions: 0.3.0
> Reporter: Peter Ansell
>
> Peter Ansell
> [commented|https://github.com/apache/incubator-commonsrdf/pull/24#discussion_r82316729]
> on COMMONSRDF-35:
> {quote}
> How about adding the following interfaces to Commons RDF API, rather than
> experimenting inside of the integration modules that is unhelpful in the long
> term for reuse of similar patterns. (Note that the appropriate generics type
> declarations such as "T extends RDFTerm" have not been added to the
> signatures below but they would be necessary in practice):
> * GeneralisedTriple<RDFTerm, RDFTerm, RDFTerm>
> * GeneralisedQuad<BlankNodeOrIRI, RDFTerm, RDFTerm, RDFTerm> implements
> GeneralisedTriple<RDFTerm, RDFTerm, RDFTerm>
> * Triple implements GeneralisedTriple<BlankNodeOrIRI, IRI, RDFTerm>
> * Quad implements Triple, GeneralisedQuad<BlankNodeOrIRI, BlankNodeOrIRI,
> IRI, RDFTerm>
> * GeneralisedGraph<GeneralisedTriple, RDFTerm, RDFTerm, RDFTerm> (need the
> copied generic types for methods that don't just accept GeneralisedTriple)
> * GeneralisedDataset<GeneralisedQuad, BlankNodeOrIRI, RDFTerm, RDFTerm,
> RDFTerm>
> * Graph implements GeneralisedGraph<Triple, BlankNodeOrIRI, IRI, RDFTerm>
> * Dataset implements GeneralisedDataset<Quad, BlankNodeOrIRI, BlankNodeOrIRI,
> IRI, RDFTerm>
> The key is that the commonly reused interfaces Triple/Quad/Graph/Dataset now
> do not have the confusing "Like" suffix, and they have no generics arguments
> to remove an extra barrier to reuse. All implementations of Triple will be
> specialised subsets of GeneralisedTriple, so it doesn't seem to be an issue
> to uptake to represent the APIs this way.
> Inheriting Quad from Triple and other similar instances isn't a design issue
> IMO, as correct code should be written to check instanceof Quad before it
> checks instanceof Triple if the user wants to preserve the dataset reference.
> Even though Quad is not defined in terms of RDF-1.1, there will be no simple
> way to integrate with RDF4J without some version of it. It is also a commonly
> used term in the community, even if it didn't make it into the RDF-1.1
> specification so it doesn't introduce new issues for understandability.
> Implementing a Triple-level integration for RDF4J would not be a useful
> pursuit IMO given the background of the RDF4J Statement interface always
> having had a getContext method. I would prefer if this integration went just
> for Quad<->Statement translation in its initial versions to get it completed
> sooner rather than later.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
