Establish conventions for use and documentation of named graphs

[baskaufs]

When multiple users are loading data, it's going to be important to know who is responsible for them (e.g. stale, too large, etc.). I think the best way to do that is to require that data be loaded as part of named graphs rather than into the default graph. I suppose for testing purposes, people could load data into the default graph, but they should know it's not necessarily going to be persistent and may get cleaned out periodically.

[baskaufs]

Actually, for reference purposes, I'm not sure how one could clean out triples from the default graph that weren't part of named graphs. According to this post, Neptune uses the inclusive assumption, which means that the default graph includes not only triples not assigned to named graphs, but all of the triples in all of the named graphs as well.

[baskaufs]

This page makes it clear that all triples are part of some graph. When no graph is specified in an Update operation, the graph IRI http://aws.amazon.com/neptune/vocab/v01/DefaultNamedGraph is used as a fallback.

[baskaufs]

I'm basing the graph management on the [SPARQL 1.1 Service Description Recommendation](), which models named graphs like this:

The uploader script automatically handles generating the links between the nodes as new graphs are added or graph descriptions (objects of sd:graph triples) are changed. So as long as the loader script is used, graph management is automatic.

The underlying metadata are controlled by this table, which describes properties of the named graphs and this table, which describes the properties of the graph descriptions (RDF datasets) that are loaded into the named graphs.

The parties responsible for maintaining the named graphs are indicated by triples like:

<http://rs.tdwg.org/> dc:publisher "Vanderbilt Heard Libraries";
                                   a sd:NamedGraph.