Filter feature

[csarven]

Follows https://github.com/solid/notifications-panel/blob/main/meetings/2023-02-02.md#add-ldn-channel-2023-ed to introduce a feature to allow fine-grained notification filtering, e.g., activity types, activities involving particular actors, tags.

It is based on a general requirement as suggested in solid/notifications-panel#1 (comment) :

Mechanism for actors to make a request to be notified about particular activities.

An example model is mentioned/proposed in #147 (comment) , where a filter property would have an object detailing the information to filter on:

{
    "filter": {
       "type": "Add",
       "actor": "https://csarven.ca/#i"
    }
}

And it is an easy jump to see how something like this can work too (if I'm not messing up the syntax here -- simplified here without JSON-LD context):

{
    "filter": {
       "target": {
         "type": "oa:Annotation",
         "oa:hasTarget": "https://csarven.ca/archives/linked-research-decentralised-web/ce36de40-64a7-4d57-a189-f47c364daa74#abstract",
         "dcterms:rights": "https://creativecommons.org/licenses/by/4.0/"
       },
       "type": "Add",
       "actor": "https://csarven.ca/#i"
    }
}

[CxRes]

This is a general point about features: Could we move them out of the spec or at least to an appendix? This way we can release them independently of the main spec (and not tie it to milestones).

[csarven]

A milestone generally includes all kinds of new features, and so tied in that respect to a release.

I think it'd be important to keep the core features in the Notifications Protocol because they'd need to be supported by all implementations. Similar to e.g., subscription/channel data models. And features that are unique to notification-channel-types can be in their respective specifications, and so released independently. This was the approach for filter/activityType which originally proposed for LDNChannel2023, but then deemed to be useful for all notification-channel-types.

Having said that, whether a particular feature (for example filter) should be in 0.3 (or whenever ready) is something we can be flexible and decide.

[damooo]

Though simple filter object works in most cases, and are sufficient, it may be good to consider acp like matcher+policy mechanism.

That would allow us to express more general filter(-or-for-any-other) policy over a context composed of activity info, object info, etc. It may allow any-of/all-of/none-of combinatrics of simple match graphs. But whether such general and powerful mechanism is required is a question.

[damooo]

And acp matchers and policy seems solves much of the semantics for me to express complex predicate graphs. It allows even custom extension points in most useful way.

For example, i want a server side robot be notified when ever operation is any of Add, Delete, Update on an object whose representation content-type(where-applied) is an image/*, so that it can proceed to manage associated iiif image tiles that it manages.

[csarven]

I'm not sure about the complexity and the actual use cases for different matchers / universal quantifiers. I'd strongly suggest that we solve the simple and most obvious use case first, and go from there.

Correct me if I'm wrong but I think what we have is "any of" as opposed to "all of" as the common use case. Depending on our perspective, I'm not sure if "all of" makes sense. That is, request to be notified about activities matching a particular shape (but not negation) - which may include any one or more AS2 Activities ( https://solid.github.io/notifications/protocol#notification-message-data-model ). To be absolutely clear, I can see a SubscriptionClient being interested in notifications specifically about Add, Delete, Update, Create, or something else.

"None of" may be generally useful to have, but I don't think it would cover common use cases.

Would it make sense to use a SHACL shape as the value of notify:filter? ( Possibly related: https://www.w3.org/TR/shacl-af/#node-expressions-filter-shape ?)

[damooo]

Indeed. the complexity seems not desired. With broad range of activity types and filtering on object target, metadata seems fine. But one more feature desired is to notify-on-nested-resource.

As many of applications serializes a complex application level structure into a container (like chat, etc...), it is desired to be notified on change to any of the nested resources of a container while subscribing only to the container. How best is to model that?

Correct me if I'm wrong but I think what we have is "any of" as opposed to "all of" as the common use case.

In acp quantifiers are not for values of an attribute, but over matchers of a policy. I.e it is higher structure over few matchers(A matcher corresponds to plain BGP like above filter object.). That is to say, it is not about specifying quantifiers for attribute values in a single query, but about quantifiers over queries themselves. (Match this query and that query, match this query or that query etc. While each query being a plain bgp.)

[damooo]

Shape constraints or bgps seems works fine. Only concern is that they are tied to the structure of notification than to semantics of event. It is not always possible to express complete semantics of an event in the graph, so as to match against filter. Some times non declarative matchers may be required as allowed in acp for extensions. But that's too far.

[csarven]

Wouldn't "notify-on-nested-resource" be covered by topic being the container? Solid Notifications Protocol in and of itself doesn't yet have the notion of container but certainly would when coupled with the Solid Protocol. In the Solid Protocol, there is no knowledge about the changes beyond one depth level 1, i.e., we only know what changed directly given a container's membership, but not nested further down. I want to come back to the possibility of notifications for nested resources, for example, whether we need something like depth (see related e.g., solid/specification#132 (comment) using Depth towards deleting a container)

It may be worthwhile to classify filtering in two ways: 1) activity-centric, 2) shape-centric, and of course they can be combined.

Activity-centric

Here is a (snippet) subscription request to get notifications when a resource gets added or removed from the topic. The semantics of what gets added or removed depends on the context (e.g., origin as per AS2 being the collection (which is our topic here), or container with LDP/Solid Protocol).

{
  "topic": "https://example.org/guinan/annotations/"
  "filter": {
     "type": ["Add", "Remove"]
   }
  }
}

Shape-centric

Here is a (snippet) subscription request .. where the resource (which is our target here) is of type oa:Annotation.

{
  "topic": "https://example.org/guinan/annotations/"
  "filter": {
     "target": {
       "type": "oa:Annotation"
     }
   }
  }
}

I use the term shape liberally here. I'd imagine that a good sample of cases would be covered by describing the metadata as you've said, and that SHACL or something alike may not be necessary. Considering that the implementers need to have some understanding of AS2 with as per the notification-message-data-model, I'd presume that they can easily re-use that knowledge for filtering.

[damooo]

For shape-centric filtering the BGP matching / schacl matching works.

Only issue on Activity-centric filtering is that matching the metadata is not always sufficient.

For example the use case, "Notify to my ldn inbox, if there is an article/feed from any member-agent of team-my-fav-authors". Or notify any change made by pod-owner's children(mebers of Some children team) to pod owner.

In such cases, activity metadata can at-max contain only metadata about agent who caused change. But cannot contain members of the children/fav-authors team to match using a pattern. If custom-matcher extensions are allowed (I mentioned acp as an example. Not for it's vocab), then extensions for agents/teams can be added to servers that wanted them.

But that concern may be too imaginary. A reciever can always further filter imperatively on it's side for imperative filter-refinements. Only thing we need to provide are triggers with sufficient granularity so as not to bombard with notifications. In this context simple bgp using AS2 mechanisms should suffice.