Allow content state to be used independent of a specified browser

[higginsr]

At present content state works as part of a url that specifies a particular browser - unencoded example is <a href='https://example.org/viewer?iiif-content={"id":"http://dams.llgc.org.uk/iiif/2.0/4389767/canvas/4389772.json","type":"Canvas","partOf":[{"id":"http://dams.llgc.org.uk/iiif/2.0/4389767/manifest.json","type":"Manifest"}]}'>Link to Viewer</a> at https://iiif.io/api/content-state/0.2/#initialization-mechanisms-link

This ties content state to the browser at https://example.org/viewer: should we not have the option to provide the content state content without tying it to a browser, so that it opens in the browser of choice of the end user? Assuming I have my favourite IIIF viewing environment installed on my laptop I would expect IIIF content to appear in that rather than some random viewer (of which I have no prior knowledge).

How to do this?

In the above example we would want a json file containing {"id":"http://dams.llgc.org.uk/iiif/2.0/4389767/canvas/4389772.json","type":"Canvas","partOf":[{"id":"http://dams.llgc.org.uk/iiif/2.0/4389767/manifest.json","type":"Manifest"} that would be recognised by a IIIF viewing environment and processed correctly. Can we register a mimetype, either with subdivision of an existing one like application/content-state+ld+json or a new one with a unique filename extension? A Windows desktop pc might recognise a filetype (e.g. contentstatejson.i3f) and open it with the programme registered to process IIIF content. Given that the simplest content state parameter is a manifest, should manifests also share the same filetype / mimetype designation?

[aisaac]

Wondering: wouldn't this be a case for negotiation by (and declaration of) profiles as in https://www.w3.org/TR/dx-prof-conneg/ ?

[azaroth42]

I think we could defer this until there is a client capable of processing such a request?

[tomcrane]

Successor to https://github.com/IIIF/api/issues/557 as well

[azaroth42]

Deferring pending larger discussion of media types for IIIF formats generally, eg Manifest would be great to have a media type for as well.

[azaroth42]

Related to IIIF/api#2208 as a possible technology route for this, as the the share mechanism goes to the operating system's application chooser.

[tomcrane]

If this is a successor to https://github.com/IIIF/api/issues/557 then it needs to address the use case of marking a hyperlink as being a link to an IIIF resource. For example, if I'm scraping web pages and want to find the link to the manifest amongst all the other content.

<a href="https://example.org/manifest1.json" data-iiif-content>IIIF Manifest for this work</a>

Not semantic like this one from @acdha:

<link rel="alternate" type="application/ld+json;profile=&quot;http://iiif.io/api/presentation/2/context.json&quot;" href="https://www.wdl.org/en/item/123/manifest">

...but very simple.

[tomcrane]

<a href="https://example.org/manifest1.json" data-iiif-content data-iiif-content-type="Manifest">IIIF Manifest for this work</a>

<a href="https://example.org/manifest1.json" data-iiif-content data-iiif-content-type="application/ld+json;profile=&quot;http://iiif.io/api/presentation/2/context.json&quot;">IIIF Manifest for this work</a>

...for visible links to be rendered, rather than <link... tags.

Or, client follows it to see what it is.

[azaroth42]

Propose transfer to iiif/api keeping it marked as defer

[tomcrane]

:+1: still something that needs a recipe, whatever it looks like.