commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Minto van der Sluis <mi...@xup.nl>
Subject Re: your opinion on commons-rdf proposal
Date Thu, 15 Jan 2015 09:36:11 GMT
Sure!

Reto Gmür schreef op 15-1-2015 om 10:06:
> Hi Minto,
>
> Thanks a lot for your valuable comments. Would you mind reposting to
> the mailing list as to have tis discussion public?
>
> Cheers,
> Reto
>
> On Thu, Jan 15, 2015 at 9:01 AM, Minto van der Sluis <minto@xup.nl
> <mailto:minto@xup.nl>> wrote:
>
>     Hi Reto,
>
>     Thanks for showing interest in my opinion.
>
>     First of all the whole discussion around commons-rdf involves way to
>     much religion. Religion as in: my implemention should be reference
>     implementation. IMO commons-rdf should be about designing the best RDF
>     API and not about making some implementation fit that API.
>
>     On the API itself:
>     1) I am glad you chose to derive from Collections. This opens up the
>     possibility to use Java 8 streams to improve performance especially in
>     the filter() method.
>     2) Hmm, is filter() still required if we can use java 8 streams
>     (collection.stream().filter())?
>     3) I dislike BlankNodeOrIri interface name. Judging from the
>     github:commons-rdf comments the name should be Subject. Taking your
>     comments Resource might be a better name. BTW, the comments for this
>     interface differ between your sandbox and the github commons-rdf.
>     4) Why does GraphEvent only has one triple? What if you remove/add a
>     large number triples?
>     5) Events are not ready for extension. AddEvent accually is something
>     like AddedTriple(s)Event. Same for remove. The (s) depends on the
>     outcome of the previous point. See next point for additional events.
>     6) The API misses facilities to access/create/query graphs. If
>     this gets
>     included you probably also end up with events like AddedGraphEvent
>     ditto
>     for remove. For this I envision something along the lines of JDBC and
>     DataSources.
>     7) Also the whole event mechanism might be extremely difficult to
>     realise. Of course from within the implementation it is easy, but
>     think
>     distributed here. Take for instance a sparql endpoints. It is
>     relativily
>     straightforward to create an implementation for this except for the
>     eventing part. I wouldn't know how to implement eventing without
>     polling
>     the sparql endpoint every so often. Shouldn't events be something
>     additional/optional.
>
>     So far for quickly scanning things.
>
>     Personally I'd also like to see a pure in memory based
>     implementation it
>     not only makes testing things easier for the API users, but also
>     helps focus
>     on what is best for a clean/clear API. Like I mentioned before,
>     the API
>     should be leading NOT the implementation. Also a test
>     compatibility kit
>     (TCK) might come in handy to ensure other implementations work as
>     expected.
>
>     And if we get this far we might as well try to make it a standard by
>     submitting a JSR ;-)
>
>     Regards,
>
>     Minto
>
>
>     Reto Gmür schreef op 14-1-2015 om 15:15:
>     > Hi Minto
>     >
>     > I would be very interested to learn abou your opinion on the
>     > commons-rdf proposal I recently committed.
>     >
>     > Cheers,
>     > Reto
>

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