On Thu, Jan 15, 2015 at 9:01 AM, Minto van der Sluis <mi...@xup.nl <mailto:mi...@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.
"Subject" might be backing into a corner. A: IRI < BlankNodeOrIri and it can occur in the object or predicate positions. B: Literals as subjects are only blocked in RDF because of the peculiarities or the RDF/XML syntax. They are arise naturally in rules (and to some extent query). None of the APIs are generalised APIs (see the github discussions on that https://github.com/commons-rdf/commons-rdf/issues/1 which is fine.
4) Why does GraphEvent only has one triple? What if you remove/add a large number triples?
Yes - the experience from Jena and Jena users supports this. The graph level/triple action event mechanism is one point on a continuum. Example 1: Adding a foaf:Person (says, 5-10 triples) to a graph. - Want to know when that start and finishes, regardless of triple count and order. Just triples does indicate when it's finished without a convention on "last" triple. - less interesting to see part data : indeed it is positively bad. Example 2: Bulk addition: reading in a new file into a graph has natural start/finish boundaries that can be of interest. An event on every triple of X million is not. The event parts can be separate from the Graph interface - advantage, other objects types can share the event mechanism (caution point: references to objects in events can lead to GC fun and games). Triple events can happen be added aspects on a interface - then the application does not incur the event system costs if it does not use it.
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.
+1 Use cases I'm interested in include graphs across multiple machines and persistence data.
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
--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
