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
https://alice.example/my-cat is a media resource, which could be an image or a video.
It does have a Description Resource, to which it links via describedby link relation.
When the notification channel gets created with "topic": "https://alice.example/my-cat" there is nothing in the current notifications specification that would automatically include any of its auxiliary resources, for example, one linked via descibedby.
We could require the subscription client to discover all auxiliary resources of interest and either request a dedicated channel for each of them or add them as an additional topic along the https://alice.example/my-cat resource. (noting that we still may need to work on clarification for channels with multiple topics.
Given the nature of auxiliary resources, the server at least in theory could change IRI of any auxiliary resource at any time, it only needs to ensure that the current IRIs are advertised in the Link header of the primary resource. Since we always tie the auxiliary resource to the main resource, it might be beneficial that the topic can include a list of link relations for its auxiliary resources. This way I believe we will follow more closely how the auxiliary resources are intended to work.
Note: the use of @value is only needed due to "describedby" being a string literal and not an IRI. I'd try not to side track into that and focus on the main matter of the issue. I also made up solid:serverManagedDescription just to have another link relation which is an IRI.
The text was updated successfully, but these errors were encountered:
Let's consider a use case:
https://alice.example/my-cat
is a media resource, which could be an image or a video.describedby
link relation.When the notification channel gets created with
"topic": "https://alice.example/my-cat"
there is nothing in the current notifications specification that would automatically include any of its auxiliary resources, for example, one linked viadescibedby
.We could require the subscription client to discover all auxiliary resources of interest and either request a dedicated channel for each of them or add them as an additional
topic
along thehttps://alice.example/my-cat
resource. (noting that we still may need to work on clarification for channels with multiple topics.Given the nature of auxiliary resources, the server at least in theory could change IRI of any auxiliary resource at any time, it only needs to ensure that the current IRIs are advertised in the Link header of the primary resource. Since we always tie the auxiliary resource to the main resource, it might be beneficial that the
topic
can include a list of link relations for its auxiliary resources. This way I believe we will follow more closely how the auxiliary resources are intended to work.Modified snippet from https://solid.github.io/notifications/protocol#notification-channel-data-model
Note: the use of
@value
is only needed due to "describedby" being a string literal and not an IRI. I'd try not to side track into that and focus on the main matter of the issue. I also made upsolid:serverManagedDescription
just to have another link relation which is an IRI.The text was updated successfully, but these errors were encountered: