[Nepomuk] Refactoring for Soprano 3

Sebastian Trüg trueg at kde.org
Tue Oct 20 12:57:51 CEST 2009


On Sunday 18 October 2009 09:51:02 Hari krishna Anandhan wrote:
> in the RDFModel interface, i think there should be another query
> method having just the query string, without queryLang. As people
> mostly use just SPARQL, it makes life easier.

That is an easy thing to do.
 
> For inferencing, i think that EnableInference should be member of
> RepositoryConnection, instead of adding it for each query. It is
> ideally set per connection and can always be disabled by the setting
> the member temporarily

I thought having flags in the query and the listStatements methods would allow 
to have more options in there. But I have to admit that ATM I would not know 
any flags other than inference.

> Though the RepositoryConnection can be closed in the destructor, i
> think having an explicit Close/ Dispose method makes sense.

But why? Other than that it looks nice I can see no reason. Don't get me 
wrong. I would probably also add one but then again I see no real need.
 
> As inference is planned to be integrated deep, i think
> Soprano::Statement should be changed to incorporate 2 things
> 1. inferred flag - whether the statement has been inferred or is new

This is something Leo suggested, too. I think it is a good idea. I am simply 
not sure if any backend can pull that off.

> 2. referenceStatements - for inferred statements , this list contains
> all the parent statement from which the inference was reached. For
> others , this is null

Again a very nice idea but here I am sure that nothing does support it. And 
the question is: does it make sense to already add it although there will be 
no support for it by any backend?

> And, regarding the "dirty reads" proposed by Leo, I am not sure
> whether i understand their significance. I suppose transactions cover
> "what if" scenarios sufficiently
> Let me try to understand the nice guis showing the results "as if
> commited" that Leo was suggesting...
> Consider an app which shows a list of customers who have balance less
> than zero and an inference which shows defaulted customers (with
> balance < 0).... you can just start a transaction, change some
> balances and see how the inference changes on the fly. if you are
> satisfied, you then commit, else just close the app and it
> automatically rolls back. Am I missing something ?

but I think that is exactly what Leo meant: a connection/transaction will 
return query results including the non-commited statements.

Cheers,
Sebastian


More information about the Nepomuk mailing list