Variations of usage of ActivityStreams' (ordered)items elements
aisaac opened this issue · 2 comments
As discussed on the IIIF TSG call 25 July 2018 (https://docs.google.com/document/d/1e2F3sJPG4rfMsvee-IvuWDIJqgLe0tP6aBattUmwBa4/), the IIIF Discovery spec at http://iiif.io/api/discovery/0.1/ uses the element 'orderedItems' from Activity Streams in line with the AS spec for ordered list of elements. But for what seems to be similar cases of ordered AS items in nearby specifications, the choice was to use the 'items' element. For example http://iiif.io/api/presentation/3.0/#55-annotation-page and https://www.w3.org/TR/annotation-model/#annotation-page .
The issue has been discussed by the Editors in a call mentioned at IIIF/api#1350 but the issue itself does not track the argument that was made then.
The rationale for this is the following:
- Not all
items
lists in the Presentation API are ordered, and the feeling was that it is worse to have two fields (ordered / unordered) in the JSON than to have only one (ordered) where the order is sometimes meaningless. This comes from the JSON first principle, rather than starting with an RDF ontology -- it would be confusing to put unordered content into a property calledorderedItems
. - Conversely, all lists of items in the discovery spec MUST be ordered, as the algorithm relies on this. Thus,
orderedItems
is not confusing in this context. - There is desire from the TSG and the community generally to ensure that the spec is not tied explicitly to IIIF content (e.g. @beaudet).
items
for the core, ordered set of activities rather than the AS nativeorderedItems
would require at least that definition. Currently, no additional contexts are needed beyond activity streams. - It's simpler to have just the W3C's AS context, than to have multiple for core properties. Adding further, non-iiif contexts would be needed only for extending the set of types or namespaces.
Consensus on TSG Call 2018-08-08: Rationale is sufficient, closing. Will leave ordereditems in Discovery.