commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reto Gmür <r...@apache.org>
Subject Re: Updated Commons-RDF
Date Wed, 14 Jan 2015 18:34:09 GMT
There has been an indirect reply here:
https://github.com/commons-rdf/commons-rdf/issues/43, as the issue point to
this thread I though to add a back-link but I would prefer to have a
discussion here and to discuss about concrete code proposals

According to Sergio the proposal is "a wrapper implementation instead of
commons interface". As the proposal doesn't contain any wrapper, this might
refer to the question on when to define classes and when to define
interfaces.

The API proposal has the following interfaces and classes (without .events)

Interfaces:

   - BlankNodeOrIri.java
   <http://svn.apache.org/repos/asf/commons/sandbox/rdf/trunk/src/main/java/org/apache/commons/rdf/BlankNodeOrIri.java>


   - Graph.java
   <http://svn.apache.org/repos/asf/commons/sandbox/rdf/trunk/src/main/java/org/apache/commons/rdf/Graph.java>


   - ImmutableGraph.java
   <http://svn.apache.org/repos/asf/commons/sandbox/rdf/trunk/src/main/java/org/apache/commons/rdf/ImmutableGraph.java>


   - RdfTerm.java
   <http://svn.apache.org/repos/asf/commons/sandbox/rdf/trunk/src/main/java/org/apache/commons/rdf/RdfTerm.java>


   - Triple.java
   <http://svn.apache.org/repos/asf/commons/sandbox/rdf/trunk/src/main/java/org/apache/commons/rdf/Triple.java>
   - Literal.java
   <http://svn.apache.org/repos/asf/commons/sandbox/rdf/trunk/src/main/java/org/apache/commons/rdf/Literal.java>


Classes:

   - Language.java
   <http://svn.apache.org/repos/asf/commons/sandbox/rdf/trunk/src/main/java/org/apache/commons/rdf/Language.java>


   - Iri.java
   <http://svn.apache.org/repos/asf/commons/sandbox/rdf/trunk/src/main/java/org/apache/commons/rdf/Iri.java>
   - BlankNode.java
   <http://svn.apache.org/repos/asf/commons/sandbox/rdf/trunk/src/main/java/org/apache/commons/rdf/BlankNode.java>


The reason why Language and Iri are classes rather than interfaces is
because the additional work for service providers exposing the API to
implement the interfaces themselves seems to outweigh the benefits of the
possibility to provide an own implementation without inheriting the
overhead of an additional String per instance (the classes are not final,
so implementation can still provide an Iri implementation that stores all
the lengthy IRIs on disk, in this case there is just an empty and unused
string field for the JIT to optimize away).

The reason why BlankNode is a class and not an interface is to discourage
polymorphism. If an instance is more than just a BNode user will be more
likely to expect to get the very same instance back, but as described in
the Readme there is no such guarantee. Typically implementations will
replace BlankNode objects with instances of their own subclass of BlankNode
as soon as they can (i.e. as soon as originally added instance becomes
eligible for garbage collection).


Cheers,

Reto

On Tue, Jan 13, 2015 at 7:30 AM, Reto Gmür <reto@apache.org> wrote:

> Hi all,
>
> I've just committed a new version to
>
> http://svn.apache.org/viewvc/commons/sandbox/rdf/trunk/
>
> The most obvious change if that instead of having TripleCollection, MGraph
> and Graph there is now Graph and ImmutableGraph. With this change the usage
> of the term "graph" is a bit closer to the colloquial usage (at the price
> of being a bit more distant to the usage in the specs).
>
> I've also added some questions and answers to the Readme highlighting the
> points where the API offers advantages compared with other APIs and API
> proposals.
>
> The API goes beyond the most minimalistic API by allowing for graph
> listeners to be notified when a graph is changed. This is a popular feature
> that cannot easily be added on top of the core API so it is included.
>
> I've added the getLock method to the main Graph interface. API notes
> describe how implementation can easily provide such a lock and what to do
> in situation where no such lock is needed. In clerezza we have been using a
> subinterface LockableMGraph to provide this feature. Experience has shown
> however that this approach makes it unnecessary difficult to write generic
> code, for example generic methods processing a Graph often had to check the
> type and downcast to do the locking on graphs than can be locked.
>
>
> Please let me know about what you think about this proposal.
>
> Cheers,
> Reto
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message