IIIF/iiif-stories

Activity Streams 'moved' activity

mixterj opened this issue · 4 comments

mixterj commented

Description

In the current 0.3 Change Discovery specifications, the only types of Activities are 'Create', 'Update', and 'Delete'. OCLC's CONTENTdm has a use case where a 'Move' Activity might be helpful. In this use case a CONTENTdm customer stops using CONTENTdm and migrates all of their data to a new platform that also supports IIIF Change Discovery API. We would like to indicate that the Activity Stream or individual Manifests have 'moved' elsewhere so harvesters can continue to track 'Update', 'Create', and 'Delete' activities

Variation(s)

Right now if a CONTENTdm Site or Collection moves locations we can produce 'Delete' Activities for all of the Manifests but that does not help crawlers track where they went. While semantically correct it is also somewhat misleading.

Proposed Solutions

Allow for a 'Move' type activity that can be used to point to where a Manifests is now located

Additional Background

This 'Move' activity type could also be used for items drifting in and out of permanent collections at the same institution.

aisaac commented

This seems like a useful case for avoiding broken references.
I'm wondering however whether this use could extend to more simple situations, where say, the first path of a URI changes because of some infrastructure or information design change even though the hosting (ContentDM or other) would still be the same. This is also a typical situation where references break. But I am not sure this is a practice that we want to encourage (by somehow alleviating its consequences).

mixterj commented

Yes, I totally agree about the internal change in URI pattern as a use case for the 'Move' Activity.

zimeon commented

The thing that always makes me a little uncomfortable with higher-order operations like "move" is that every client/harvester has to implement "move", otherwise those that don't would miss the change. This would actually be an argument in favor of including this in v1.0 rather than later, because then the first set of clients/harvesters would implement it and there wouldn't be an awkward upgrade problem