`members`, `canvases`, `ranges`, `collections` to Linking properties & table

[jpstroop]

These are only mentioned in later part of the spec. I think they should be treated like any other property, especially members since it's used twice.

[azaroth42]

We don't discuss the structural properties at all in section 3.

The list seems like: collections, manifests, members, sequences, structures, canvases, resources, otherContent, images, ranges.

Not sure that 10 entries, most of which are just MUST on one resource type is worth the space?

[azaroth42]

Would be okay with a Structural Properties table in Appendix B, rather than a full on block of 10 entries in section 3.

[jpstroop]

As discussed, I'd be willing to compromise on either adding them to the Linking table in Appendix B or adding a new Structure table there.

You should be able to go somewhere in the spec and get an overview of all of the properties we define. That's my goal.

[azaroth42]

:+1:

[azaroth42]

Added table: http://structural739.iiif.io/api/presentation/2.1/#b-summary-of-metadata-requirements

[tomcrane]

:+1: to the structural properties table. I may be years too late to the table with this, but are we happy with the symbols used? http://structural739.iiif.io/api/presentation/2.1/#b-summary-of-metadata-requirements. There is a world of difference between "optional" and "not allowed" and visually they get a bit lost in the structural table.

[mikeapp]

:+1: to the table. I agree with @tomcrane that the symbols could be improved. My instinctive reading of the red symbols is "not allowed!" - but of course the legend makes the meaning clear.

[zimeon]

:+1: to table, agree that optional symbol needs to stand out more

[azaroth42]

Agree the symbols could be improved. Does someone have UI person cycles spare to work on that? Will create a separate issue...

[zimeon]

Easy way to improve optional symbol would be just to make it bolder/darker