Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unordered behavior on Collections #14

Open
mikeapp opened this issue Mar 20, 2019 · 3 comments
Open

Unordered behavior on Collections #14

mikeapp opened this issue Mar 20, 2019 · 3 comments
Assignees
Milestone

Comments

@mikeapp
Copy link
Member

mikeapp commented Mar 20, 2019

Original Issue
IIIF/api#1679

Background
The unordered behavior indicates that the items "included in resources that have this behavior have no inherent order, and user interfaces should avoid implying an order to the user."

Issue
This behavior was originally valid only for Manifests and Ranges, but there may be cases where the order of Manifests within a Collection is arbitrary and this behavior could be applicable.

Solution
Allow the unordered behavior for Collections.

@mikeapp mikeapp added this to the March 2019 Call milestone Mar 20, 2019
@mikeapp mikeapp self-assigned this Mar 21, 2019
@cubap
Copy link

cubap commented Mar 27, 2019

I definitely see the case for this. However, it is a little peculiar in the way our existing APIs encode themselves, since the vocabulary has an opinion in JSON-LD. For example:

  "members": {
  "@type": "@id",
  "@id": "sc:hasParts",
  "@container": "@list"
}

and https://json-ld.org/spec/latest/json-ld/#sets-and-lists offers that @list is ordered and @set is not. We can certainly make our own rules, but it seems to add to entropy to have a JSON array (unordered), that is both separately an @list (ordered) and then superseded by an unordered behavior.

A possible solution would be to have the default example for these resource collections be something that is either a @set or an @list with ordering behaviors for truly special cases. Alternately, a well-named alternative could exist for either case and they may be similar in all other ways. For example, a Range for content (Psalms 1-10) would be ordered by default, but a Subset (Range) for, say, topic (Psalms of Contrition) would not. Since Collections already allow multiple types to be collected, it may not be a big deal to include at a higher, more obvious layer than as a behavior.

@jronallo
Copy link

What I'm getting from the TRC discussion is that the use cases are good for unordered, but that the mechanism to achieve it and how it relates to JSON-LD is more complicated. So I'm 👍 on adding a way to say a Collection is unordered, but maybe it isn't the behavior mechanism?

@azaroth42
Copy link
Member

Issue 14 (Unordered behavior on Collections)

+1: 24 [aisaac awead azaroth42 beaudet gigamorph irv jbhoward-dublin jonhartzler joshuago78 jronallo julsraemy jwd kzhr markpatton mattmcgrattan mcwhitaker mikeapp mixterj regisrob rentonsa rsinghal scossu tpendragon zimeon]
0: 3 [cubap jtweed sredick]
-1: 0 []

Result: 24 / 27 = 0.89

Super majority is in favor, issue is approved

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants