search

IIIF / iiif-stories

Community repository for documenting stories and use cases related to uses of the International Image Interoperability Framework.
21 stars 0 forks source link

Activity Streams 'moved' activity #110

Open mixterj opened 4 years ago

mixterj commented 4 years ago

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 4 years ago

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 4 years ago

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

zimeon commented 4 years ago

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

azaroth42 commented 4 years ago

Reference to 0.1 note about Move: https://github.com/IIIF/discovery/blob/master/source/api/harvest/0.1/activities.md#rename--move