EntityManagerImpl.find doesn't generally work with NamedGraph annotated classes

[delocalizer]

If MyClass is annotated with @NamedGraph (Static or Instance type doesn't matter) and an instance of the class lives in the database, EntityManagerImpl.find(MyClass, itsKey) won't find it.

See https://groups.google.com/forum/#!topic/empire-rdf/BKu0f5uItec

Unfortunately the fix is not as simple as calling
DataSourceUtil.exists(getDataSource(), theObj)

in EntityManagerImpl.find because theObj passed into find and thence to DataSourceUtil.exists is often (as in this case) just an RdfKey or similar key-like identifier with no annotations.

The problem is that EntityManager.find does (and should) accept a broad range of types as "theObj", where for instances of naked key types the additional NamedGraph information on where to find them lives only in separately-supplied "theClass" parameter, while the code that actually does the finding — DataSourceUtil.exists(DataSource theDataSource, Object theObj) — expects all the info to be available in theObj instance.

More broadly EmpireUtil.hasNamedGraphSpecified(Object theObj) and EmpireUtil.getNamedGraph(Object theObj) expect that information on the instance too.

[mhgrove]

I had originally thought that maybe RdfKey would be a pair of the key value and the iri of the named graph. I wanted to avoid coupling those together, but, that might be a nice simplification that would resolve this issue.

Having urn:foo be a different entity when it's in named graph urn:g vs when it's in urn:g1 seems like it's probably what users would expect

[delocalizer]

Yeah, having the graph be part of the key seems nice from a practical pov. I think it's also kosher from a RDF theory pov, not that I am an expert. My understanding that the intended usefulness of named graphs is for store-based operations, and RdfKey is the key to find the entity in the store.