This issue is to collect to discussion of dataset vs. conjunctive graph from: #301, #302, #303 and friends.

Similarities between ConjunctiveGraph and DataSet:

• Both allow you to group triples into separate graphs. You can either look at it as "quads" (with a fourth context element), or as a collection of graphs, each containing triples, the two views are interchangeable.
• Both should have quad methods, like addN, add_quad, remove_quad, quads, etc.
• Both should have graph methods, like get_context (or get_graph), listing, deleting, etc.

The difference between ConjuctiveGraph and DataSet:

• ConjunctiveGraph allows (as the named implies) querying the conjunction (union) of all graphs
• ConjunctiveGraph has a named default graph, implicitly named with a bnode if nothing else is given.
• DataSet has the concept of a default graph, but the exact definition is open.
• DataSet tracks the existence of empty graphs, a ConjuctiveGraph only contains the graphs that contain triples

Some more concerns:

• Our Store API support (somewhat implicitly) that idea of union of graphs if no context is specified. I would rather not change the store API at this point, i.e. I would not like to have a solution that requires stores to change to accemodate yet-another-graph class
• For SPARQL, it is often interesting to on-the-fly define a new DataSet, i.e. selecting some subset of graphs from another DataSet, or even from several datasets. It would be nice to be able to do this without copying all the triples.

I suggest:

• Add a new class ContextAwareGraph, that has flags for union_default_graph and track_empty_graphs. This class also provides quads/graph methods.
• Let ConjunctiveGraph and DataSet extend this class, each setting the flags the way they want.

Not clear to me just now:

• How are the empty graphs of a DataSet persisted? Looking at the current code I would say they are not. I.e. if I open a DataSet on a Sleepycat store, create some graphs, exit my program. Next time I open, only graphs that contained triples will exists.
• What about python operators on Context-aware graphs? __sub__, __contains__, etc. This is Think about __iadd__, __isub__ etc. for ConjunctiveGraph #225.