[
https://issues.apache.org/jira/browse/COMMONSRDF-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stian Soiland-Reyes updated COMMONSRDF-42:
------------------------------------------
Reporter: Peter Ansell (was: Stian Soiland-Reyes)
> 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
> 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)
