Atomic Data subjects are HTTP(S) URLs that resolve. However, there are situations where we don't want to or can't generate a fully resolvable URL:
Error messages that are not linked to a specific URL
data created on a client that does not know where (or even if) the data will be hosted
Allow resources without an @id, as long as they have a local-id
In the summer of 2022, we added the /import endpoint which allows users to add JSON-AD without @id fields, but with local-id.
This works pretty well, but the situation still begs questions:
How should stores internally store these resources without a subject? All my current implementations store resources using their @id, so if there is none, we can't store them.
Use the @id field with a custom local: scheme
Instead of relying on an extra property, we could re-use the @id field, but just use local: instead of http:
Atomic Data
subjectsare HTTP(S) URLs that resolve. However, there are situations where we don't want to or can't generate a fully resolvable URL:Allow resources without an
@id, as long as they have alocal-idIn the summer of 2022, we added the
/importendpoint which allows users to addJSON-ADwithout@idfields, but withlocal-id.This works pretty well, but the situation still begs questions:
@id, so if there is none, we can't store them.Use the
@idfield with a customlocal:schemeInstead of relying on an extra property, we could re-use the
@idfield, but just uselocal:instead ofhttp: