FEP-34c1: Collection Filtering using TREE Hypermedia Vocabulary

[trwnh]

@aschrijver

we tend to mash everything into the ActivityStreams vocabulary. @trwnh in separate discussion mentioned how we are afraid to define our own extensions.

as:Collection is already carrying a heavy burden, where it facilitates core protocol capabilities and at the same time is used to model app designs with various overloaded semantics and additional bells and whistles requirements.

Instead of “Collection filtering” this FEP may be “Filtered collections” and introduce FilteredCollection or something like that. It might even have a CollectionFilter object as a property, so you can easily switch filter strategies and mechanisms.

there isn’t strictly a problem with using Collection; the problem is with using only Collection and nothing else, for things that are more specific than a Collection. example: imagine if OrderedCollection didn’t exist, and collections that were “ordered” were indistinguishable from “unordered” ones.

---

i haven’t spent much time reading this fep yet, but a few things stand out to me as weird:

“special casing” as:following and as:followers to mean not the collection but the collection’s items feels like a violation of TREE. the root issue is that collections are indirections for sets of items, but the collection is not the set of items – it is a reification of it. because there is special processing involved with collections, you do not want to use it with tree:path and tree:value. what you should be doing instead is defining a special property which is inherently checking the collection items (paginated or unpaginated). something like _:inCollectionItems maybe.

but with that said… doesn’t TREE already do this?!! you have tree:Collection and tree:member which already exist and make me wonder why you bother specifying the “return type” as as:OrderedCollectionPage… which is itself a little weird because you’re saying it is a “page” that is as:partOf some other collection but it’s somehow not linked to any other pages. this implies paged collections whose pages are unreachable, which is a very discomforting stretch when we already have issues with a lack of clarity regarding paging in the first place.

the TREE solution is to use SHACL shape nodes for this kind of member extraction. we see that SHACL defines property paths for this kind of usage.

{
  "@context": {
    "as": "https://www.w3.org/ns/activitystreams#",
    "sh": "http://www.w3.org/ns/shacl#"
  },
  "sh:path": {
    "@list": [
      {"@id": "as:followers"},
      {"@id": "as:items"}
    ]
  }
}

this [sh:path (as:followers as:items);] form is equivalent to SPARQL path as:followers/as:items. the shortcoming here is that this only works for unpaged followers collections – dealing with paging in predicate paths is a bit more complex. this is a weakness of the as:Collection model where as:items of a as:CollectionPage are assumed to be as:items of the as:Collection that it is as:partOf. you could try to represent it as something like this:

{
  "@context": {
    "as": "https://www.w3.org/ns/activitystreams#",
    "sh": "http://www.w3.org/ns/shacl#"
  },
  "sh:alternativePath": {
    "@list": [
      "@list": [
        {"@id": "as:followers"},
        {"@id": "as:items"}
      ],
      "@list": [
        {"@id": "as:followers"},
        {"@id": "as:first"},
        {"sh:zeroOrMorePath": {"@id": "as:next"}},
        {"@id": "as:items"}
      ],
      "@list": [
        {"@id": "as:followers"},
        {"@id": "as:last"},
        {"sh:zeroOrMorePath": {"@id": "as:prev"}},
        {"@id": "as:items"}
      ]
    ]
  }
}

…with arbitrary complexity due to the paging of the as:Collection, which could go both ways. (this kind of exercise really highlights a lot of the problems with as:Collection as it stands…)