Notification channel resource as URI

[csarven]

https://solid.github.io/notifications/protocol#notification-channel and https://solid.github.io/notifications/protocol#notification-channel-data-model does not constrain the notification channel resource. It could be a blank node or a URI.

The notification channel resource needs to be a URI in order to globally identify it among other channels that a subscription service offers. That would make it possible for subscription clients to update the channel parameters.

The notification channel resource needs to be an HTTP URI in order to be able to GET a representation for it and remove it with DELETE.

[elf-pavlik]

https://solid.github.io/notifications/protocol#notification-channel and https://solid.github.io/notifications/protocol#notification-channel-data-model

One id property to identify the notification channel.

https://github.com/solid/vocab/pull/85/files#diff-8e7afe3f959b877846bbb41e0987a10351a895fd8916f8783eb8ac6b801ae211

"id": "@id

https://www.w3.org/TR/json-ld11/#iris

A string is interpreted as an IRI when it is the value of a map entry with the key @id:

In other words, we already require an IRI, but probably relying on the definition of @id in JSON-LD is not the most straightforward way of doing it. Requiring an HTTP IRI would be an additional constraint.

[csarven]

You're right that information is deep down in the JSON-LD context, and so, it is at least an IRI, and that a blank node is not possible. I still think that a reader can benefit more from making that more explicit in the specification.

I created this issue because it seemed that a clarification can help to properly resolve #145 and perhaps other considerations. Some details in #145 (comment) . As it stands, only POST targeting a subscription-service with the payload referring to the IRI of the notification channel can be used to unsubscribe.