Stian Soiland-Reyes created COMMONSRDF-42:
---------------------------------------------
Summary: 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: Stian Soiland-Reyes
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)
