I think the current approach is quite good - we have interfaces so the implementation can have whatever class-hierarchy you want, e.g. a disk-based RDF store might have a common RDFTermImpl superclass containing 64-bit identifiers and on-demand loading of the long strings.
On the other hand, the implementations in commons-rdf-simple can be used as-is when they are good enough - so say you are happy with simple.LiteralImpl, then you should just use that directly, and still have your own IRIOnDiskImpl. That is - your RDFTermFactory-created instances are not required to all be from the same Java package. On 31 March 2015 at 03:55, Peter Ansell <[email protected]> wrote: > On 31 March 2015 at 05:49, Gary Gregory <[email protected]> wrote: >> I was surprised to see an interace called IRI. When I see IRI, I expect a >> class like the JRE's URI (or URL), not an interface. >> >> This interface looks more like a IRIProvider to me. > > If it was implemented as a class, then every implementation would need > to extend it to make it suit their system, or we create it as a final > class and hope it suits everyone, which doesn't work. > > It is not within our scope to dictate the internal workings of the > systems we are trying to provide interoperability for. In particular, > libraries written in non-Java-JVM languages will have different > assumptions to the Java based implementations. Although they mostly > provide interoperability with Java, the interfaces should be > applicable to them in the same way as the Java libraries. If the > entire API is written using interfaces, they have less Java-specific > details to work around. > > Cheers, > > Peter -- Stian Soiland-Reyes Apache Taverna (incubating), Apache Commons RDF (incubating) http://orcid.org/0000-0001-9842-9718
