Github user ansell commented on a diff in the pull request:
https://github.com/apache/incubator-commonsrdf/pull/24#discussion_r82316729
--- Diff:
rdf4j/src/main/java/org/apache/commons/rdf/rdf4j/RDF4JGraphLike.java ---
@@ -0,0 +1,63 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.rdf.rdf4j;
+
+import java.util.Optional;
+
+import org.apache.commons.rdf.api.BlankNodeOrIRI;
+import org.apache.commons.rdf.api.GraphLike;
+import org.apache.commons.rdf.api.IRI;
+import org.apache.commons.rdf.api.RDFTerm;
+import org.apache.commons.rdf.api.TripleLike;
+import org.eclipse.rdf4j.model.Model;
+import org.eclipse.rdf4j.repository.Repository;
+
+/**
+ * Marker interface for RDF4J implementations of GraphLike.
+ *
+ * @see RDF4JGraph
+ *
+ */
+public interface RDF4JGraphLike<T extends TripleLike<BlankNodeOrIRI, IRI,
RDFTerm>>
--- End diff --
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.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
