Changes between Version 17 and Version 18 of ApertureRDF

Timestamp:

10/27/05 11:45:53 (19 years ago)

Author:

anonymous

Comment:

--

ApertureRDF

@@ -66 +66 @@
 Since the Repository is specified as a parameter to the Extractor, starting and committing any transactions is the responsibility of the integrator. In case of the memory store, this can even be omitted.
 
+Clarification by Jeen: the Repository by default works in an 'autoCommit' mode. This means that the user does not have to worry about starting and stopping transactions, every action (such as adding a property, or a file) is automatically a single transaction. It is possible (but not necessary) to switch this off or to use transactions explicitly, in order to bundle operations together in batches. This can give better performance but of course requires more responsibility from the user who has to make sure transactions are started and committed properly. 
+
 = Conclusion Leo =
 
 Since the sesame2 repository api provides less usability than Leo wishes to provide for developers, I would suggest to stick to the RDFMap idea and provide about 10-20 methods there that "do the trick". In the methods I would mix resource-based and model based methods, for ease of implementation. Although it would be fine to have a real "abstract" layer, I still hesitate to use rdf2go, because it is java 1.5 and not adapted to sesame2 yet. Will ask Max though, if he can do these two things.
+
+Comment by Jeen: although there is always a careful balance to be struck here between ease of use and performance, I can understand the need to provide a 'simple' API that offers the set of most common operations on RDF to the user. I would however always allow a back door to be built in, and to keep in mind that you may need to extend this interface later: the Sesame API is not as large as it is because we happen to like it that way, these methods serve real purposes and offer various ways around performance issues, complex querying questions, dealing with various RDF serializations, etc. Making your wrapper too simple will inevitably result in bumping into such issues all over again. Implementing such a wrapper (once the set of methods it should offer has been determined) is a minor task, it shouldn't take longer than a few days.