This is what I understand from reading Secs. 2 and 4 of "Named Graphs, Provenance and Trust" . I might well have missed something or got something wrong.
The paper extends the abstract syntax of RDF  and the model-theoretic semantics of RDF  to take the notion of Named Graphs into account. From now on, whenever I talk about RDF, I mean it in this extended form, not in the original form.
Semantically, a Named Graph g is some resource in the universe of discourse with two specific features: a name (URI) and an associated RDF graph (set of RDF triples). So you can, as always, use an interpretation function I to interpret a name in an RDF graph by such a Named Graph resource. It is then possible to define what it means that an RDF graph containing Named Graphs (now seen as syntactic parts of the original graph, of course) is /satisfied/ by an interpretation I and a universe U, using a vocabulary V. Let's take your example RDF graph and call it G. G consists of three (syntactic) Named Graphs g1, g2 and g3. An interpretation I satisfies G, if:
the vocabulary V of I contains the three names (URIs) "g1", "g2" and "g3";
the universe U of I contains three named graphs ng1, ng2 and ng3
- having "g1", "g2" and "g3" as their names, respectively,
- and having the content graphs of g1, g2 and g3 as their associated RDF graphs (!!! NOTE: this last point is NOT said in the paper, but it is my own assumption, because it looks to me that this condition is accidentally missing !!!);
I maps the name "g1" to ng1, and likewise for the other Named Graphs.
Of course, the interpretation I has also to satisfy all additional semantic conditions of the respective entailment regime (e.g. RDFS). The above is just meant as the "diff" to the original notion(s) of satisfaction, as defined in the RDF Semantics .
Once the notion of graph satisfaction is defined, the standard notions of /consistency/ of a graph G ("there exists some satisfying interpretation for G"), and that a graph G1 /entails/ another graph G2 ("G2 is satisfied whenever G1 is satisfied") can then be defined in the traditional way.
Up to now, all we can say for your example graph G is that is is clearly satisfiable, since it is obviously possible to construct a universe containing the three named graphs g1, g2 and g3 as resources, and there are no other statements in G which might become a "thread" to consistency. I don't see anything interesting being entailed that would be a conclusion mainly due to the contained named graphs, though.
What we certainly want is making non-trivial assertions about the RDF graphs associated with the three Named Graphs. However, in the current state, all we can do is treating Named Graphs as resources, i.e. having their names occur in property assertions (triples with custom predicates) or class assertions (triples with rdf:type as predicate). The situation here is similar as for classes in RDFS: classes are regular resources in the first place, and in order to refer to their associated sets (their "class extensions"), one needs specially interpreted vocabulary terms. For classes, there is "rdf:type" (relates a resource to the set of a class) and "rdfs:subClassOf" (relates the sets of two classes). In , there is "rdfg:subGraphOf" to relate the RDF graphs of two Named Graphs. So you could add the following triple to your graph G:
g1 rdfg:subGraphOf g2 .
This would make your graph G inconsistent, since the triples in g1 do not build a subset of the triples in g2, and so there cannot be any interpretation which would satisfy your graph.
"rdfg:subGraphOf" obviously makes assertions on a /syntactic/ level of Named Graphs: it is about the relationship of triple sets, not about the semantic meaning of these triple sets. I could imagine other syntactic relationships not mentioned in , such as one for telling that a graph is ground, i.e. does not contain blank nodes ("g rdf:type rdfg:GroundGraph"; this statement would be true for all of your three Named Graphs), or that one graph is the merge of two others ("g rdfg:mergeOf (g1 g2)"), etc.
I could even imagine terms for expressing /semantic/ relationships, such as consistency of the associated RDF graph of a Named Graph ("g rdf:type rdfg:ConsistentGraph"), or entailment between the associated RDF graphs of two Named Graphs ("g1 rdfg:entailsGraph g2"). In this case, one would have to distinguish between the different entailment regimes of the RDF Semantics (Simple, RDF, RDFS, D; and probably taking Named Graph semantics into account there as well). So it would actually be something like "g1 rdf:type rdfg:RDFSConsistentGraph" and "g1 rdfg:RDFSEntailsGraph g2", etc.
This can all be formally specified, I guess. However, at least for the semantic relationships, I would not propose to introduce them without an in-depth analysis of their ramifications.