Hi Sebastian, from my experience: - using sesame2 as inspiration is the right way to go. try to ignore Jena. Dunno about virtuoso. - use exactly the names you suggested, do use RepositoryFactory - this is correct, stick with it - your uml has a typo: the "Repositoy" is too good to be true.
what needs to be considered: * close/disconnect/dispose (however you put it). A repository connection must be explicitly closed. * dirty reads - the repositoryconnection must support dirty reads of its own changes in the listStatement AND SPARQL implementations - this is a major issue in nepomuk-java which I implemented in ClientSession and diffmodelset, and having dirty reads on your connection-aware changes with SPARQL support is the best way to go, although the hardest to achieve. It allows to build nice guis showing the results "as if commited" while not having commited yet. Note, that dirty reads are very unlikely to work for text indexing. * thread-safety: sesame2 leaves a lot to be desired here. My wish is: many many threads realized by multiple RepositoryConnections. Read/write must be possible for multiple connectsions without blocking. For one RepositoryConnection, single-thread safety is a good tradeoff. * writing to the repository should not invalidate open readers and queries. It sucks hard when RDF apis suddenly "fail" in a half-iterated query result when you concurrently do changes. An iterator should be valid from start to end, despite doing changes to the same repositoryconnection while the iterator is open. If this is not supported, it pushes a lot of hassle to the individual developer * listening to changes based on configurable filters - I interpret the "statementAdded" and "statementRemoved" methods as triggering events, I implemented something like "addStatementListener(listener, filter)". To push the filtering/notification optimisation to the store * I would remove all these super/sub interfaces (Filter*) and just have one interface of each part, let the implementation throw excpeitons if it doesn't undestand each method, nobody will bother checking the interfaces anyway, its a hassle * Desire: Inference must mark inferred statements as inferred. Thus, the statement interface may add another bit "inferred". Even better would be to have an explanation attached to each inferred statement leading from the inferred statement to the original statement, this is very important for GUIs and for editing data. something such as Statement.getInferenceCause - returns some human-readable and machine-understandable explanation pointing to 1..n source statements and the number of the RDFS/NRL rule that was executed to come from source to result. (something like this... but this is science fiction) so, thats all I have to say. For each point: it will make things better, and will cause trouble if not done right. I have no time for discussions, please take the input as is. best Leo It was Sebastian Trüg who said at the right time 13.10.2009 16:57 the following words: > Hello, > > Soprano 2 IMHO has a nice design. Backend, Model, and FilterModel suited my > needs very well and were nice to use. But now it slowly reaches its limits. > > With Virtuoso the introduction of transactions become very important. I tried > to stack them on top of Model as you can see in the experimental branch[1] > but > the resulting design is flawed and cannot be any different since we need to > stay binary compatible for KDE. > > Thus, it is time for a redesign and also time for you to state your needs and > ideas. > > Attached you find a preliminary design in the form of a crude UML diagram. It > is based on the sesame2 idea of Respository vs. RespositoryConnection. > > A few words of explanation: > - Model is split into two classes Repository and RepositoryConnection. > Each RespositoryConnection represents its own transaction object, i.e. > can perform multiple transactions. > - A Repository can create an arbitrary number of RespositoryConnection > objects. > - Backend is now RepositoryFactoy (better name welcome). It is used to > create StorageRepositories which replace StorageModel and have settings > like storage dir and the like. > - FilterRepository and FilterRepositoryConnection replace the current > FilterModel. > A FilterRepository would need to create its own connections which carry > as a member a parent connection created by the parent Repository. > > This is the basis I would like to start the discussion from. > Another issue is inference which I would like to integrate deeper into > Soprano. The straight forward design would be to add a flags parameter to > method like query() and listStatements() which can for example be > EnableInference. > > Please discuss. > > Cheers, > Sebastian > _______________________________________________ > Nepomuk mailing list > [email protected] > https://mail.kde.org/mailman/listinfo/nepomuk > -- _____________________________________________________ Dr. Leo Sauermann http://www.dfki.de/~sauermann Deutsches Forschungszentrum fuer Kuenstliche Intelligenz DFKI GmbH Trippstadter Strasse 122 P.O. Box 2080 Fon: +43 6991 gnowsis D-67663 Kaiserslautern Fax: +49 631 20575-102 Germany Mail: [email protected] Geschaeftsfuehrung: Prof.Dr.Dr.h.c.mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes Amtsgericht Kaiserslautern, HRB 2313 _____________________________________________________ _______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
