-
Notifications
You must be signed in to change notification settings - Fork 7
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
Filter feature #159
Comments
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). |
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 Having said that, whether a particular feature (for example |
Though simple filter object works in most cases, and are sufficient, it may be good to consider 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. |
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 |
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 |
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?
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.) |
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. |
Wouldn't "notify-on-nested-resource" be covered by It may be worthwhile to classify filtering in two ways: 1) activity-centric, 2) shape-centric, and of course they can be combined. Activity-centricHere is a (snippet) subscription request to get notifications when a resource gets added or removed from the
Shape-centricHere is a (snippet) subscription request .. where the resource (which is our
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. |
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 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. |
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) :
An example model is mentioned/proposed in #147 (comment) , where a
filter
property would have an object detailing the information to filter on: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):
The text was updated successfully, but these errors were encountered: