Create experiments document describing functionality milestones and provide manifests for demo experiments

[JulieWinchester]

This PR:

• Adds a file, EXPERIMENTS.md, that describes acceptance criteria and successive functionality milestones of increasing complexity for draft manifest demo experiments. This will give TSG members guidance on how to direct efforts when creating demos that will best help the group make progress. This document gives MUST/SHOULD/COULD guidelines for demo creation and provides 5 functionality milestones of successively increasing complexity. More milestones will need to be added later.
• Adds a set of manifest files corresponding to the functionality milestones, with each manifest pointing to the actual URL of the astronaut asset in the repo (instead of using a dummy file value as before).
• Renames the file previously called VIEWER_JSON_DEMOS.md to JSON_DEMOS_ISSUE_17.md and makes other changes to demonstrate that the work described in this document has now been completed and new efforts should be directed toward supporting draft IIIF manifests.

[JulieWinchester]

Specifically pinging @edsilv, @vincentmarchetti, and @gjcope since you all have been the other TSG members actively working on demo creation, and it was @gjcope's idea to create some more solid expectations and guidance for demo creation. Does this make sense to you? How do you feel about the MUST/SHOULD/COULD? What about the initial milestones?

[gjcope]

@JulieWinchester I like it. I think having the same draft manifests that everyone is loading is key. Should the tests including scale also have another object in the scene? This would make it easier to quickly evaluate based on relative size. We may also run into other requirements (like viewport dimensions?) but this seems like a good start.

[vincentmarchetti]

I propose wrapping the example annotations in the simplest json which is at structurally a Manifest, assuming the existence of a Scene term. I have attached one way to do this for the first model_origin. We would not require first implementations to do the complete exploration of the manifest, they could assume that the Annotation to render would be the 1st annotation of the first AnnotationPage of the first item (type Scene) of the manifest object.

This example is based on first 2D Cookbook recipe : https://iiif.io/api/cookbook/recipe/0001-mvm-image/ astronaut_in_scene.json

[gjcope]

That example defines a canvas size and then assumes the image will fill the space. It seems a little more complicated in our use case. Do we also make certain assumptions of default camera and object placement if not provided in the manifest?

[tomcrane]

I've wrapped the 5 examples in Manifest boilerplate. While this makes them a bit more verbose, they are all now IIIF Manifests that could be used in tests.

[vincentmarchetti]

Should we use URL's like

https://raw.githubusercontent.com/IIIF/3d/main/manifests/model_origin.json to retrieve these manifests , or is there a better choice of urls to retrieve this json from the repository?

[vincentmarchetti]

The manifests prepared by tomcrane last week, and now merged into main, use the URL https://github.com/IIIF/3d/raw/main/assets/astronaut/astronaut.glb for the body of the annotation. I am getting a CORS denial when my javascript fetches this URL. I observe that also, an online gltf viewer that accepts URL, at https://playcanvas.com/viewer , also fails to render the model at this URL.

Does anyone have experience loading this URL from another viewer?

[JulieWinchester]

Hi @vincentmarchetti this link should work: https://raw.githubusercontent.com/IIIF/3d/main/assets/astronaut/astronaut.glb

The draft manifest recipes have been evolving pretty quickly over on the eds branch, and at least one manifest there is using the right URL (https://github.com/IIIF/3d/blob/eds/manifests/1_basic_model_in_scene/model_origin.json). I think not all of them are, though, so I'll get that fixed.