@albaker: I’ve had similar thoughts about curies/qnames — but I think for SPARQL and consumers the problem is that the edge cases where a prefix for a URI in the database doesn’t exist kill the viability/utility. i.e. I think for those scenarios you need to validate that all data in the endpoint on ingestion has a prefix associated with its URI, as you’re building a syntactic dependency on the exact shorthand names (or risking collisions).

This kind of thing would also make mapping to graphql schemas a lot easier.

I like JSON-LD but it really opened the floodgates on URIs no longer just being opaque semantic identifiers, but there also being a syntactic representation that consumers can depend on. Another example of this trend is the CSVW vocabulary; built on JSON-LD it isn’t just interpretable as an RDF vocabulary, but also as a syntactic/structural JSON vocabulary. This meant that then the standard for CSVW isn’t really JSON-LD; it’s just a subset of it as it necessarily imposes limitations on the use of JSON-LD contexts etc, and also had to standardise interpretation of the format by essentially inlining chunks of the JSON-LD spec in the CSVW, so it could impose those dialect restrictions.