No; that defeats a lot of the purpose. UUIDs should be made for unique entities, and even then they might have useful IRIs, eg
Schema (the predicates) should be well-formed and well-named IRIs.
Objects are other related concepts (perhaps a UUID) or literals.
Most graph-y sorts of situations look like:
https://rdf.cayley.io/subgraphA/2347908234af292f rdf:name "oren"
https://rdf.cayley.io/subgraphA/2347908234af292f foaf:knows https://rdf.cayley.io/subgraphA/7ab3c34734309673
https://rdf.cayley.io/subgraphA/7ab3c34734309673 rdf:name "barakmich"
– for this simple graph I generated some UUIDs by smashing the keyboard in a vaguely hex fashion These are perfectly reasonable, as long as
subgraphA is willing to maintain their lifecycle.
encoding/hex ought to do the trick. Honestly any sufficiently entropic hex string can be what we use; a SHA of something useful (datetime + mac address?) ought to do the trick. If you prefer, you can even just make them incrementing numbers.
Perhaps UUID is an overzealous standard. It need not be universal, just unique to the graph’s namespace (eg, it’s IRI should be unique to the subgraph)
I’d rather not do it the Mongo way if Cayley is generating them, even if you append it to the path. There’s nothing, per-se, wrong with it (it’s 12 bytes, less some entropy) but I’d rather not have any comparison. These are entities, not documents.
That said, within your own domain, you can make use of this fact, and have something like:
https://rdf.cayley.io/subgraphA/mongo/502838296713 rdf:name "some-document"
Where all entities under /mongo also utilize the mongo IDs, or something.