Rename `subscription resource`

[uvdsl]

Although it seems to me that subscription resource is a long used and pretty set in stone term, I would like point out that the naming may be confusing:

From the term alone, one could get the idea that a subscription resource is a resource whose representation describes a subscription. Especially, when modelling the resource where requests are submitted to as a container (#36), or even more, when considering materializing requests for subscriptions in such a container.

In my mind, what is currently referred to as a subscription resource is a resource whose representation describes a service that provides the subscription/notification functionalities. (independent of that resource being also a container or can be POSTed to)

Thus, I would like to propose the terms subscription service resource which is described by its subscription service representation.

[csarven]

The notion of container is not part of Solid Notifications Protocol. "Resources" all the way down.

The subscription request (POST) and the response representations use the notification-channel-data-model and relevant notification-channel-types data model.

I don't have a strong opinion on re-naming, i.e., whether to use subscription resource or subscription service or subscription service resource. I would just say that the spec currently uses:

• topic resource
• description resource
• subscription resource
• notification channel

I find "resource" to be sufficient/simple. Notification channel may need to be referred as the notification channel resource, where applicable. Or, as you suggest, change subscription resource to subscription service resource.

Do others have thoughts/suggestions on this? We can still change / have more consistency.

[uvdsl]

Just to clearify, I do not take issue in the usage of the term resource but the ambiguity of the term subscription resource as it may be confused with a resource representing a subscription.

As the current notion of subscription resource refers to a resource where one can create/register a subscription via HTTP POST, I feel we could be more precise in terms of naming here.

[CxRes]

I would second @uvdsl here. Furthermore, if we were to go down the container (containing resources for a subscription) route in the future, we would have the term "subscription resource" available to us.

[CxRes]

My preference is "Subscription Service", which might then also be referred to as "Subscription Service Resource" where we need to make it explicit that we are referring to an HTTP resource.

[csarven]

I'd welcome renaming to "subscription service", but I propose an alternative view that can potentially tie up some loose ends:

The behaviour of subscription resource/service resembles a specialisation of LDN inbox with a particular data model. The inbox accepts subscription requests with optional features about a topic.

The request can be further specified with particular activity types (or shapes, see activityType proposal in https://github.com/solid/notifications/pull/147 ).

The inbox can contain accepted subscriptions. Subscriptions can be modified or removed (TBD with https://github.com/solid/notifications/issues/145 ).

While the minimal implementation of a Subscription Service need not have subscription resource be an inbox, it can certainly be extended in that way (re ldn-channel-2023). So, from ldn-channel-2023's point of view, the subscription resource/service thing is really a subscription inbox. notify:subscription need not be defined as a rdfs:subPropertyOf ldp:inbox either. Whether it is called service or inbox is perhaps minor/bikeshedding in the end.

If we introduce the notion where subscriptions (active notification channels) are identifiable units where they can be modified or removed for some (all?) channel types, there is not a whole lot difference from regular container/inbox behaviour. I think this actually ties up a bunch of our considerations, including https://github.com/solid/notifications/issues/36 .

[CxRes]

I am ok with "Subscription Inbox", though it is weird to subscribe to an Inbox because Inboxes accept mail not generates a letter on a request for a mail.

To @udvsl's original point, subscription resource is too generic, can imply many things and is confusing. Alternatives that show the thing dispenses subscriptions are acceptable.

[csarven]

Renaming Subscription Resource to Subscription Service works for me me.

I'd like to know what @elf-pavlik @acoburn thinks about this proposal or have other thoughts.

[csarven]

https://github.com/solid/notifications/commit/edd6c91cea26af4547bfe7e23dbc7a4b7fa1aa3e closed this issue by renaming subscription resource to subscription service as per https://github.com/solid/notifications-panel/blob/main/meetings/2023-02-02.md#rename-subscription-resource-to-subscription-service .