You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
The text was updated successfully, but these errors were encountered:
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:Allow resources without an
@id
, as long as they have alocal-id
In the summer of 2022, we added the
/import
endpoint which allows users to addJSON-AD
without@id
fields, 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
@id
field with a customlocal:
schemeInstead of relying on an extra property, we could re-use the
@id
field, but just uselocal:
instead ofhttp:
The text was updated successfully, but these errors were encountered: