Update notification-channel-conformance

[csarven]

Resolves https://github.com/solid/notifications/issues/71 .

The proposal is based on agreement in https://github.com/solid/notifications-panel/blob/21a7048ab9b4a1b1a2a7025f063da73dc4fbcd92/meetings/2022-12-08.md#interchangeable-use-of-notification-channel-type-and-subscription-type

[elf-pavlik]

Looking at the example snippet

{
  "@context": [
    "https://www.w3.org/ns/solid/notification/v1"
  ],
  "notificationChannel": [{
    "subscriptionType": "WebSocketSubscription2021",
    "subscription": "https://websocket.example/subscription",
    "feature": ["state", "rate", "endTime"]
  }]
}

IMO we don't need to introduce concept of Notification Channel, we only need predicate which relates the resource which will be used as topic https://example.org/guinan/profile to the Subscription Resource https://websocket.example/subscription. I think in lines:

{
  "@context": [
    "https://www.w3.org/ns/solid/notification/v1"
  ],
  "@id": "https://example.org/guinan/profile"
  "notificationSubscription": [
    {
      "@id": "https://websocket.example/subscription",
      "subscriptionType": "WebSocketSubscription2021",
      "feature": ["state", "rate", "endTime"]
    }, {
      "@id": "https://webhook.example/subscription",
      "subscriptionType": "WebHookSubscription2021",
      "feature": ["state", "rate", "endTime"]
    }
  ]
}

In this case GET the Subscription Resource https://websocket.example/subscription will respond with the same information

{
  "@context": [
    "https://www.w3.org/ns/solid/notification/v1"
  ],
{
    "@id": "https://websocket.example/subscription",
    "subscriptionType": "WebSocketSubscription2021",
    "feature": ["state", "rate", "endTime"]
  }
}

[csarven]

Pavlik, I like the simplification and would just point at that it resembles the simplifications/clarifications we were after in https://github.com/solid/notifications/issues/71#issuecomment-1177789571 and https://github.com/solid/notifications/issues/71#issuecomment-1227244863 .

I don't have an objection to it but would like us to go through these considerations:

---

We don't need the concept of a notification channel resource per se - it was a term to refer to a resource that makes the channel/subscriptions/service information available. I'm okay to drop that and reuse/paraphrase the current definition of notification channel resource throughout the document, e.g., "resource including information about the capabilities and features of a notification service."

---

Whether we want to require the resource server or the subscription server (with notification channel resource and subscription resource respectively) to materialise statements with the topic as the subject resource. It is not strictly self-describing and I worry about the potential notification subscription information leaking into the description of the topic resource / somewhere and somehow. If the service that's being offered uses a different subject URI, it'd potentially avoid that issue (with data merge).

---

I'm trying to see whether we can have the right amount of abstraction so that a notification service that a resource has available can be extended without needing to revisit Notification Protocol.

Would it be meaningful to say that the subscription resource describes a subscription service? Is the following meaningful:

{
  "@context": [
    "https://www.w3.org/ns/solid/notification/v1"
  ],
  "id": "https://example.org/guinan/profile"
  "service": [
    {
      "id": "https://websocket.example/subscription",
      "type": ["WebSocketSubscription2021", "Service"],
      "feature": ["state", "rate", "endTime"]
    }, {
      "id": "https://webhook.example/subscription",
      "type": ["WebHookSubscription2021", "Service"],
      "feature": ["state", "rate", "endTime"]
    }
  ]
}

(or notificationService and NotificationService/SubscriptionService or whatever..)

So, WebSocketSubscription2021 would be a subClassOf Service - I left it in the example but it would not be required in payloads.

I can see the counter-argument that the subscription resource is not necessarily the service but that it is just a way to get to the notification service. Then again, it is not entirely clear whether we are talking about the subscription server or the notification sender as the service or both.

---

Similar to above:

Would the above model/example work out even if we used notificationSubscription and still using type in favour of subscriptionType?

[elf-pavlik]

It is not strictly self-describing and I worry about the potential notification subscription information leaking into the description of the topic resource / somewhere and somehow.

My example didn't mention being specific for `rel="describedby" path of discovery. In that case we get Description Resource. If the topic is a Non-RDFSource, this would actually be the RDF description for it. The information about where to subscribe to notification IMO describes the resource acting as the topic. I think the issue here comes from the statement being a server managed one. I don't want to get into sever vs client managed statements in this PR, though we might need to take it into consideration (e.g. adding to list of protected statements).

For rel="http://www.w3.org/ns/solid#storageDescription" path of discovery, there is no specific topic. In that case I think the storage would be used as subject in the statement. BTW can storage itself also have rel="describedby", in that case would it be the same storage description?

---

Would the above model/example work out even if we used notificationSubscription and still using type in favour of subscriptionType?

I think we should take a close look at instances of subscriptions and how we use subscription types. Currently we use them on subscription request and subscription response. We have related issue #36 where we discuss creating resources based on subscription request. Even if we don't create resource, I still think the subscription request and subscription response are correctly modeled as instances rdf:type of specific subscription type . Calling the endpoint used for the interaction as Subscription Resource IMO brings confusion. We could call that endpoint Subscription Service or Subscription Issueror something else. In that case I don't think we should use subscription types directly as rdf:type since I don't consider that service/issuer/endpoint an instance of an actual subscription.

[csarven]

BTW can storage itself also have rel="describedby", in that case would it be the same storage description?

Right.. I thought so in https://github.com/solid/specification/issues/355#issuecomment-1140508784

---

If we move the subscription type to subscriptionType then we should change subscription-request-data-model and subscription-response-data-model as well to use that property (currently it is type that indicates the subscription type). Solid Notification JSON-LD context's target (used in subscription-request) is also conflicting with AS2's target. We can reuse AS2's target instead but then we'll need to reconsider what the payload in the subscription request is trying to convey.

We may have to do this https://github.com/solid/notifications/issues/62#issuecomment-1332663243 :

The semantics of AS2's object is not particularly accurate in the case of a subscription request - unless we introduce SubscriptionRequest as a type of as:Activity.

Argh.

[csarven]

This PR is superseded by https://github.com/solid/notifications/pull/131