Details
-
Wish
-
Status: Open
-
Major
-
Resolution: Unresolved
-
0.3.0
-
None
-
None
Description
Peter Ansell commented on COMMONSRDF-35:
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.