• Add action items generated in the meeting here 


Discuss Pull requests:

Discuss Issues:

Meeting Materials


Discussion of activity order. Issue and PR

Kevin - Not sure why we care

Dave - I you go oldest to newest then harvester has to remember date of last item. In AS this might just be last page. If going newest to oldest then you remember the date again, go 'til you find something that you've already past that date. Pagination is just a minor tweak. Both are very simple. BUT, should pick one direction and stick with it consistently.

Steven - Surprised that it took so long to get to this question. Thinks that the `first` and `last` properties suggest an order though LC does the other way and AS spec doesn't mandate a direction.

Dave - As consumer have to build code for either or both, but a few lines of code. Note implication of going newest to oldest the apply on first (is latest) update, but if going oldest to newest one will possibly see multiple updates

Simeon - If one direction is recommended and the other allowed, then code still have to deal with both.

Dave - For implementer of source, likely simpler to implement oldest first and perhaps keep all old pages.

Simeon - Note that if patch is used then the whole sequence of updates is required, whichever direction they are specified in.

Kevin - LC pages are generated dynamically, would take lots of effort to understand what changes

Simeon - Suggest that activities MUST be in time order, RECOMMEND oldest to newest

Vitas - Nice to have complete record of oldest to newest changes

Dave - Complete historical record not necessary for updates, e.g. in LC example just find out last date of update

Steven - Some votes for oldest first, others think shouldn't specify preferred order on don't care

ACTION - Dave will create something about the necessity for ordering and implications for histroy. Will postpone decision on order until that is done, see whether it changes preference.

Should we also make clear the relationship between OrderCollections and the Entity Metadata Collection in 1.3.2

Steven - I think what we're saying is that in our API the Entity Metadata Collection is an implementation of the AS OrderedCollection.

Vitas - EM Collection is set the authority, but the AS Collection is the set of activities

Simeon - We define EM Collection but then we seem to define a collection of entities

Steven - Think we really should be talking about changes (activities) and not the collection of entities

Kevin - Note mismatch between current definition and use to mean collection of entities 

Dave - Would "Set" be better than "Collection" in order to distinguish from AS Collection?

Vitas - We define entities (Entity) and entity set/collection (Entity Metadata Collection

Simeon - Activity Stream is history of changes to Entities in an Entity Set provided by an Entity Metadata Provider. And in 1.3.3. perhaps Activity should be defined as “...object are used to describe an individual change in an Entity (Metadat) Set”

ACTION - Simeon to try using Entity (Metadata) Set with a PR →

Splits, Deprecate, Merge

Kevin - Would be fine with having Deprecate as an atomic operation

Steven - What advantage in grouping Create and Update in a Deprecate?

Dave - Useful to have some atomicity, the Create and Update might want to be applied together then 

Kevin - If "Deprecate" is atomic then we have a benefit of knowing what the specific update means, otherwise one would have to look into the RDF to understand this

Kevin/Dave - in AS spec likely can read "extends" as "sub-classes"

Kevin - orderItems isn't defined in the namespace, just in JSON context :

"orderedItems": {
  "@id": "as:items",
  "@type": "@id",
  "@container": "@list"

Think that creating an Activity type "Deprecate" might not be appropriate at the higher level (of Collections)

Discussion of AS semantics (not captured).

Continue with this discussion next time


  • Dave Eichmann
  • Steven Folsom
  • Kevin Ford
  • Greg Reeve
  • Vitus Tang
  • Simeon Warner 

  • No labels