I'll see if I can replicate the sparql tests locally, those did not run by the run_tests script on my machine

Coverage increased (+0.1%) to 75.632% when pulling d509036 on oohlaf:identifier-as-context into e004802 on RDFLib:master.

One build failure remains on python 3.4. Could use some help with that one.

Nah, this is weird. I finally managed to get Python3.4 to compile on my system to run the failing test case. And guess what, it does not fail. I can't replicate the build failure. Now what?

I'm very keen to see progress on this: it annoys me greatly not being able to identify graphs with a URI, as I think they should be. @ashleysommer any thoughts on the Python 3.4 oddity? I also don't get any errors running locally so perhaps we just need to rerun Travis?

my 2c is get rid of py3.4 compatability - 3.6 and up only! :D

Closing and re-opening to re-trigger Travis

Hi @oohlaf, @ashleysommer and I have looked at this PR and we're going to discuss it further with others later tonight. We think a little more discussion is still needed so we're going to push this to a 6.0.0 release (a few months off) and not include it in a 5.0.0 release (shortly).

Well get back to you shortly (a few days) with our discussion.

What's the status of the discussion? Amenable to a new PR?
I rebased this rebase as branch identifier-as-context of my fork, all tests passing according to GHActions

I've added some comments on a couple of new test failures (conditionally skipped) and an implementation note.

I just discussed this with one of the co-maintainers on the phone today (@ashleysommer) and we are keen to make a proper move on this front. The recent PR that I put up for HexTuples was harder than it should have been due to this issue remaining unsolved.

I think we should be able to refer to contexts by URIRef, str of the URI or by context object (for backwards comparability). Also we should not have to set the publicID for ConjunctiveGraphs / Datasets manually when parsing multi graph data, e.g Trig, to get the default graph to work properly.

So I think we need a rather large set of changes here - or perhaps better worded and far reaching since the code changes may not be large - and they are possibly breaking unless reference by context object can still continue also. So this may be an RDFlib 7.0.0 thing.

I will put out a 6.1.0 shortly as master now contains much improved tests (pytest, coverage etc) and will be ready for PRs on this issue after that, so by some time next week.

Happy to help with this too if you lead as this issue must be finally dealt with: the current context referencing is just to unintuitive!

I just discussed this with one of the co-maintainers on the phone today (@ashleysommer) and we are keen to make a proper move on this front.

Okay, now that the principle has been established, I'll reply substantively once I've organised my thoughts. Happy to shepherd this through.

Perhaps just type checking for a Graph, URIRef or str and then comparing that with context, context.identifier and str(context.identifier) is all that’s needed in graph.py and then a whole lot of work to ensure that it’s applied consistently in all other code? It backwards comparability is maintained with the context object option then I suppose the application across legacy code can proceed with no rush as it will keep working. Is there more to it than that? Iterating through cg.contexts() issues perhaps??

Changes in the RDFLib codebase since gromgull's original PR unfortunately render this an incomplete implementation.