= Problems with RDFContainer =

= Solution: own in-mem sail? =

Leo: How about making our own in-memory sail, that does not support transactions, context, etc.
It is just needed to ship RDF from the DataAccessor to the CrawlerHandler.
The CrawlerHandler then has to read it again and copy all the triples to another repository

Then, the default RDFContainer (in-mem sesame) must not contain "context" anymore. Context is only used when creating the RDFContainer via the factory methods of CrawlerHandler.

 * pro: for 80% of the use cases, it gets simpler (extracting data to things like gnowsis or Lucene)
 * pro: for the 20% of the use cases where the DataAccessor directly streams into the RDFContainer (=the sesame database), the CrawlerHandler can provide a context-aware RDFContainer.
 * con: we have to write it.

=  Problem autocommit =

When you use a SesameRDFContainer, its Repository typically has its 
auto-commit mode switched off for performance reasons. However, this 
breaks the contract of RDFContainer's API. The reason is that statements 
in the repository are not visible until a commit is performed. So when 
you do a put() for a certain property and you later do a put() for the 
same property with a different value, you expect that the latter put() 
overwrites the former value. However, when the repository hasn't been 
committed yet, replaceInternal won't see the first value. Likewise, the 
get methods will not return a value for that property. When you finally 
commit, you end up with both values being stored, leading to a 
MultipleValuesException upon retrieval.

My example classes are already crowded with commit's to make sure 
certain put and get methods work correctly. There is something to say 
for this as these classes also provide the CrawlerHandler implementation 
that manage the repository. However, I now had to add Sesame-specific 
code in WebCrawler as it depends on the overwriting capability of the 
put method.

This is a problem with the SesameRDFContainer but I can imagine that 
other implementations working with persistence storage facilities will 
have similar issues.

Although I still like the simplicity of the RDFContainer API, this is 
another item on the list of problems I've had with it. Does anyone see a 
simple solution for this? Other that adding a commit() method to 
RDFContainer or using the Repository's auto-commit mode (hurts 
performance badly)?

= Problem BlankNodes = 

For many datasources it is nescessary to create some blank nodes to express more complicated meta-data. 

For instance, in the ImapCrawler we create the following: 

{{{

myimapsource:Blah-1 a :Message ; to [ a :Person ; :email "bob@bob.com@ ].

}}}

(hope everyone reads N3 :) 

Here we need an ID for the node representing bob. Currently each crawler makes up this node id, but this is tricky, because blanknode IDs must conform to XML names, which are not trivial to define... (the specs are pretty much unreadable). 
To get around this Chris and Gunnar have discussing adding a createBNode() method to the RDFContainer, which returns a bnode guaranteed unique within this store/repository/whatever. Good plan?

LeoSauermann: For exactly the same problem we have had in gnowsis, we decided to switch to '''no blank nodes''' anymore. It is better for everyone to have some kind of uri there. So we thought of just taking the e-mail address of the recipient as mailto:uri. The advantage of that is that during smushing, there are much less triples and that the different names of a person get aggregated automatically. (which is ok for me)
If the ambiguity is an issue, it might be good to say that each blank node gets a constructed URI like e-mail-uri+':to:+e-mail-address-of-recipient