What does delete mean?
Closed this issue · 9 comments
This is related to the discussion on the possibility of having the same item appear in two activity streams. In the example given in IIIF/registry#1, if we had a painting of a dinosaur from NGA it could be in two activity streams; an activity stream aggregating dinosaur related material from a dinosaur aggregator and the NGA paintings activity stream.
If there was a delete event in the dinosaur activity stream what does this mean? Does it mean:
- The dinosaur painting is removed from the dinosaur activity stream
- or the dinosaur painting has been deleted and so is no longer accessible.
The delete activity is on the manifest, not the entry in the stream, so I believe that the answer is the latter -- that the dinosaur painting has been deleted.
We don't have meta-level stream information, but it could be added using Remove as an activity type, and the URI of the stream as the origin
of the activity. E.g. I removed "dinosaur painting" from this collection.
@azaroth42 mentioning these two things next to each other makes me realize that it could help if we specify a general "scope" for understanding the activities:
- "absolute", i.e. it's only about the resource itself, as defined and maintained by its publisher
- "relative", i.e. there's some "context" resource (like a collection by an aggregator) that one should consider when interpreting the activities.
Your interpretation of Delete
would hint that we opt for the "absolute" approach, and I think this would be my prefered one.
I guess this is also compatible with the Remove
idea - though I would have used target
for the (IIIF) Collection from which the object
is removed (but I must say I'm not 100% sure I understand the difference between origin and target in the examples given at https://www.w3.org/TR/activitystreams-vocabulary/#dfn-remove )
I think that adding "Remove" is perhaps the clearest way of making the distinction from "Delete" (though one might also need to add the parallel "Add" as distinct from "Create")
For Add, are you thinking of a case where we want a point in the stream at which point the resource is added, such that the temporal ordering doesn't catch people out that there are new entries back in time that they won't have seen? Inserting entries in the past would break caching for the pages, and so encountering an Add isn't making a claim about the time of an activity on the resource, but instead about the current stream.
If so ... yes, I think I agree with Add as well as Remove.
@azaroth42 precisely
- a Create sort of implies an Add
- a Delete sort of implies a Remove
- it's ok to have an Add activity if there's no Create earlier in the stream. The idea is that when a "derived" stream aggregates a resource after it's been created "in absolute" (and represented as such in a first stream closer to source), then this is not a real creation, even if it's the first time the resource appears in the "derived" stream.
- "aggregated activities" (title of 2.1.4) will be reworded to "aggregating activities" to reflect that all this is about aggregation situations. Also the first sentence will be updated to reflect that streams aggregate IIIF resources, not activities themselves.
I think this can be closed, given 0.5?
I think so!
The specific part that implements this: https://iiif.io/api/discovery/0.9/#aggregated-activity-streams
Closing, call of 2020-06-10