I noticed that in general in modeling stuff using ActivityPub, and in particular in ForgeFed and in Vervis development, often comes a time to make a decision: Given a property that typically maps to multiple values, should we switch to having that property to map to a
Collection object, which then contains that list of values?
I suppose there’s some awkwardness and cumbersomeness about the additional level of indirection that using a
Collection creates, however there are clear benefits that sometimes make it clear that stuff should be a
- Instead of generic
Update, use specific
Removeactivities to change the collection’s content
- Changes to the list don’t require sending an
Updateof main object (those Updates may be costly because S2S Update sends the entire object, not specifying in a computer-language way what changed, so perhaps that implies that conceptually lists of stuff that can arbitrarily manually grow and shrink should be in Collections in separate documents)
- Can be explicitly ordered using
OrderedCollection(using an RDF list allows ordering too, but it also indeed introduces a level of indirection)
- Can put the collection in a separate document
- Can refer to the collection using its ID URI, specify access permissions to it separately from the main object (e.g. you want to lock an issue, preventing new discussion but still allow team members to add and remove dependencies, and those can be in their own Collection with an ID URI)
Proposal: Turn ticket dependencies to be a
Proposal: Turn ticket reverse-dependencies to be a
Collection paging and ordering not required, but I’d love to hear about good reasons to have them (e.g. we could order deps by time-of-adding or by time-of-ticket-creation, but, idk if there’s much value in that and it can cause confusion).
Thoughts / ideas / objections?