@steve I found your idea for extending OrderedCollection absolutely wild. I don't think any of us considered it when making the spec. What's the use case?
@evan I was thinking about it from the perspective of creating a generic test suite and being able to automatically determine the subtype. With an OWL ontology, I could do that, but a JSON-LD context isn't enough to know the type relationships. However, I can imagine that someone might extend the AP OrderedCollection to include the sort criteria, for example. It's reverse chrono, but the key is not specified (receive time?, send time?, authors birthday? ;-)).
@evan I've also been wondering about the feasibility of having multiple inboxes with filtered OrderedCollections (just brainstorming). The OrderedCollection subtype would include the filtering criteria that a sender could use to select the proper inbox. This seems like it would be spec-compliant since inbox is not a functional property.
@steve perfectly reasonable to add other properties for other views on that collection.
With pump.io, for example, we have "major" and "minor" inboxes, so you can see the important stuff (creating new image) and filter out the unimportant stuff (likes, shares, follows, unfollows).
I think it'd be interesting to add some additional properties for other streams.
In general, if you want to do new things, make new properties. Fucking around with existing properties is a bad idea.
@evan Just curious, why did AP restrict the AS2 OrderedCollection to be *only* reverse chrono? The AS2 type seems more useful since collections might be ordered by priority, popularity, alphabetically or whatever.
@steve I guess I need a more concrete example, because I'm not following your motivation.
When someone is posting to an inbox or outbox, it doesn't seem to be important how the stuff that's already there is sorted.
Sorting seems more important when you're reading a collection. "Give me the latest Activity for each person in my Family list, in alphabetical order by name."
But everything should go in through the main inbox.
@evan I mentioned the sender in the context of the inbox filtering/routing (and maybe for the outbox in C2S?). This is similar to what you described for pump.io. It's a good question related to the ordering criteria. The collection consumer (vs the sender) might not care *how* a collection is ordered, just that it is.
@steve so, you're reading the requirement that OrderedCollection objects in AP have to be reverse chronological order applies not only to the properties defined in the AP spec, but to **all** properties in any document used in AP, even if they're defined as an extension?
That seems like an incorrect reading of the intent of the spec.
@evan Yes, I agree. It would be more important when reading a collection. I’m sorry that I wasn’t communicating clearly.
Your family list example is interesting. Given the AP reverse chrono ordering restriction on OrderedCollection, it seems like a different subtype of ordered Collection would be needed to return an alphabetically sorted collection.
Otherwise, it would really stifle any kind of experimentation. I might want to put an OrderedCollection of my top ten favourite movies as a property of my Person object. It would be unreasonable for AP to require that it be in reverse chronological order.
@evan Maybe so. So AP only requires the reverse chrono ordering for OrderedCollections used specifically for the inbox and outbox? Maybe I did misread that. I’ll go back and review it. Thanks for the clarification.
@evan However, I didn’t understand your statement about all properties in any AP document. I am thinking the reverse chrono ordering applies to Object ordering in an OrderedCollection. The property or properties used for sorting keys aren’t specified. Also from Section 5, “What property is used to determine the reverse chronological order is intentionally left as an implementation detail.”
@evan I was thinking all AP OrderedCollections have the reverse chrono ordering restriction because Section 5 states “An OrderedCollection MUST be presented consistently in reverse chronological order.” This is in the general context of collections rather than specifically for the inbox or outbox.
@evan@steve@cwebber@erincandescent@tsyesika Having re-read the spec, I agree that's ambiguous and could be tightened up. I definitely don't think applying that rule to all OrderedCollections was intended though.
@evan I like the priorityInbox example. Those objects would still need the OrderedCollection "type" property, right?
Now that I've learned reverse chrono is not a blanket requirement for AP OrderedCollection, it opens up many possibilities (and makes more sense, in general).