viewing_* should use URIs

azaroth42 commented 10 years ago

We have a good solution in the Image API for supports that allows extension but looks like strings. We should do the same for viewing_hint and viewing_direction instead of the current method.

The documentation change is just to say that any URI can be added, rather than any value, for viewing_hint. And then the contexts need the same trick as Image already has for supports.

azaroth42 commented 10 years ago

The viewing_hint "start" collides with oa:start from TextPositionSelector, both would be URIs that have the JSON representation of "start". http://www.openannotation.org/spec/core/specific.html#TextPositionSelector

Can we rename to "start_canvas" to avoid this particular collision? Or something else?

jpstroop commented 10 years ago

"logical_start" ?

azaroth42 commented 10 years ago

"viewer_start"?

Also just to throw a wrench ... given that these are on the Canvas, which might be in different sequences, we run into trouble when different sequences have different start canvases. The viewer will just pick the first start ... which might be from the other sequence :( Do we need to replace it with a relationship from Sequence to Canvas?

jpstroop commented 10 years ago

I'm sure I follow--wouldn't a viewer choose a Sequence first, and then look for the start_here_everything_before_me_is_boring Canvas?

If thats not logical for some reason I'm not seeing, maybe there should only be one start_here_everything_before_me_is_boring per Manifest?

azaroth42 commented 10 years ago

It would select a Sequence of Canvases, call them A through Z. That Manifest might have a second Sequence, which would have the exact same Canvases, and hence both sequences have the same Canvas with a start_here_please hint. But if that Canvas isn't the right start_here_please for the second Sequence, you can't tell which to use.

If the algorithm is to walk through the current sequence and pick the first start_here_please, then that solves it a little bit. But you might have a situation, like...

Sequence 1: a,b,c,D,e,f,g
Sequence 2: a,B,c,d,g,f,e

Where capitals are the intended start_here_please.

As B always comes before D, and the canvases are the same, sequence 1 will start at B even though the intent is for it to start at D.

jpstroop commented 10 years ago

I think this could easily turn into the "Why are multiple sequences possible when Ranges exist?" discussion we had in May, so, to sidestep that, is only one start per Manifest possible?

azaroth42 commented 10 years ago

I agree it's veering in that direction. Notably, also, towards ranges used for table of contents being tied to Sequences as well, following the same logic.

My concern is that to fix it if we defer would potentially require a new Major version. Perhaps a call early next week to discuss with any interested parties? It impacts pretty much any system.

jpstroop commented 10 years ago

Sorry, typed that last one while on the phone; glad you understood.

So, I'm still wondering (you probably have a wider variety of use cases in mind), what's wrong with making "start_here" and "top" (for that matter), only allowed once per Manifest?

azaroth42 commented 10 years ago

Because that means also one Sequence per Manifest, which while currently isn't a big problem as there (as far as I know) haven't been any non experimental multi-Sequence objects, there are a lot of use cases for multiple sequences.

Multiple "top"s aren't quite so bad, as the UI can present a choice of ToC -- hopefully the label would allow the user to select which one to use. However "start_here" isn't interactive, that would defeat the point.

So two options:

rename "start" to something else, recommend only one start per Manifest.
Fix the Sequence/Range/Hints mess.

I'm not convinced that 2 is feasible without significantly delaying 2.0. On the other hand I don't want to go to 3.0 straight after 2.0.

azaroth42 commented 10 years ago

RS, JS -- "begin" and option 1, as works fine for 99.999% of the cases.

azaroth42 commented 10 years ago

@zimeon proposes the relationship option, and @azaroth42 to discuss on iiif-discuss

azaroth42 commented 10 years ago

Per call, it was seen as worthwhile to solve the edge case at the cost of some (hopefully minimal) additional complexity.

Proposal:

{
  "@type" : "sc:Sequence",
  "start_canvas" : "uri-of-canvas",
  "canvases": [ ... ]
}

Means updating:

text of the presentation API spec
frames to say that start_canvas is @embed = false
context to map to some predicate
non-existent vocabulary/model document to define the predicate

My perspective: It seems cleaner than the viewing hint 99.9% solution and isn't significantly more complex.

jpstroop commented 10 years ago

I don't see any problems with this approach. Do we like "start_canvas"? Was "start" only bugging us because of the collision with "oa:start"?

zimeon commented 10 years ago

+1. I think start_canvas is worth the few extra characters for clarity in reading, even if original motivation was to avoid collision

jpstroop commented 10 years ago

Agreed.

-Js

Sent via mobile. Please excuse typos, brevity, etc.

mikeapp commented 10 years ago

Looks good ; 'start_canvas' is more informative.

azaroth42 commented 10 years ago

Changes are in the branch referenced above. Shall I go ahead and issue a PR or wait to see if there's discussion on iiif-discuss?

jpstroop commented 10 years ago

Right seems like an obvious solution to me (right?). Wait a day if you want, but I think I'd be comfortable with proceeding.

-Js

Sent via mobile. Please excuse typos, brevity, etc. On Aug 6, 2014 6:05 PM, "Rob Sanderson" notifications@github.com wrote:

Changes are in the branch referenced above. Shall I go ahead and issue a PR or wait to see if there's discussion on iiif-discuss?

— Reply to this email directly or view it on GitHub https://github.com/IIIF/iiif.io/issues/290#issuecomment-51404263.

IIIF / api

viewing_* should use URIs #290