Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for auxiliary resources of topics #177

Open
elf-pavlik opened this issue May 22, 2023 · 0 comments
Open

Support for auxiliary resources of topics #177

elf-pavlik opened this issue May 22, 2023 · 0 comments

Comments

@elf-pavlik
Copy link
Member

Let's consider a use case:

  • 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.

Modified snippet from https://solid.github.io/notifications/protocol#notification-channel-data-model

{
  "@context": [
    "https://www.w3.org/ns/solid/notifications-context/v1"
  ],
  "id": "https://channel.example/ac748712",
  "type": "WebSocketChannel2023",
  "topic": {
    "id": "https://alice.example/my-cat",
    "auxiliary": [
      { "@value": "describedby" },
     "solid:serverManagedDescription"
    ]
  },
  "receiveFrom": "wss://websocket.example/d4cf3f19",
  "startAt": "2023-01-01T07:00:00.000Z",
  "endAt": "2023-01-01T09:00:00.000Z",
  "rate": "PT5M",
  "state": "e75-TFJH"
}

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant