Closed albertmeronyo closed 7 years ago
Thanks for raising this.
Treating the notification URI as the graph name is one way of doing it, and the way you do it is perfectly fine. The resource itself is a graph in and of itself where it might have its description in triples or quads (multiple graphs in the resource).
Updated: https://linkedresearch.org/ldn/#receiving-inbox-contents and clarified the note here: https://linkedresearch.org/ldn/#note-request-uri-and-relative-id
How does that sound?
There's a small typo at https://linkedresearch.org/ldn/#note-request-uri-and-relative-id (repeated 'the'):
Implementations may wish to treat notification URIs as graphs which contain the the RDF from the notification payload.
The rest addresses my concerns just fine. Thanks for the update!
Great, thanks for the issue.
While I was implementing pyldn, a compliant receiver, it was a bit unclear how receivers must respond to GET requests against notification URIs.
I see this bit was added meanwhile as a receiver responsibility, which already helps:
Section 3.3.2 specifies though how a receiver should respond to GET requests against inbox URIs, but not what to do against GET requests to notification URIs. This bit
suggests that the receiver must make the notifications available, and answer HTTP 200 OK to valid notification URIs and HTTP 4xx where applicable; but I felt this wasn't specific enough in the draft. Also, I find the requirement on making notifications RDF sources a bit over constraining. Currently pyldn uses notification URIs as graph names, and stores the payloads' triples within those. It's a bit unclear whether this is compliant with the spec or not. I think it might also create issues when consumers ask for serializations that do not support quads (e.g.
curl -X GET -H'Accept: application/n-triples' http://example.org/inbox/1
)Some of these are also implied by section 3.4 Consuming, but as a receiver implementor I would expect all receiver requirements to be described in section 3.3.