Can you explain a little about why this is the fix, @escowles ? (Actually, maybe an in-line comment or two would be good...?)

@ajs6f The predicates for testing whether triples are server-managed, and the logic for including various kinds of triples based on Prefer headers is already in ContentExposingResource, so it seemed like the logical place to implement the decision that server-managed triples should never be included for hash URI resources. I could definitely add a comment that we never want server-managed triples for hash URI resources, even if we want them for containers.

The other approach I considered was doing the filtering in the triple generating machinery. But I'm wary of over-complicating that already somewhat baroque code, and the logic of the decision seemed to fit better in the HTTP layer.

No, I'm sorry, @escowles , I meant at the micro-level: why does -rdfStream.concat(filter(getTriples(HashRdfContext.class), tripleFilter::test)); +rdfStream.concat(filter(getTriples(HashRdfContext.class), IS_MANAGED_TRIPLE.negate()::test));

do the job?

Oh, I see: we are avoiding the logic surrounding the server-managed triple Prefer header and always rejecting them. I'll add a comment to that effect.

Right, right. Thanks!

@ajs6f Anything else, or is this ready to merge?

No, I'm grruvy. Want me to merge?

Yes, please!