[MEI-L] Associating MEI <facsimile> with an image manifest, not an image itself

Tue Oct 18 12:25:15 CEST 2016

Hi Andrew,

Am 18.10.2016 um 06:13 schrieb Andrew Hankinson <andrew.hankinson at mail.mcgill.ca>:
> 
> IIIF Images have individual URIs to them. e.g.,
> 
> http://example.com/iiif/image.jpg/full/full/0/default.jpg
> 

I was aware of that. I understood that Ryan would like to link to the manifest, which may be located somewhere completely different than the individual image files. When Diva.js was mentioned, I immediately had those cases with manuscripts spread across multiple libraries in mind. While the image server should be able to deliver _some_ manifest from a predictable URL, it may not be the one that compiles the manuscript parts from different servers.

> You can associate this with individual surface elements. Zone elements can then be related as child elements to those surfaces.
> 
> I would avoid using hash parameters for pages since the response from a IIIF manifest is JSON, and hash parameters have an undefined behaviour when presented with a non-XML or non-HTML response.

You just found the words to better express my uneasiness ;-)

> 
> -Andrew
> 
> PS: Ryan is one of the 'folks at McGill.' :)
> 

That's what I thought – thanks for letting us participate in your discussions ;-)
jo

> 
>> On Oct 14, 2016, at 2:12 PM, Johannes Kepper <kepper at edirom.de> wrote:
>> 
>> 
>>> Am 14.10.2016 um 19:35 schrieb Michael Ryan Bannon <ryan.bannon at gmail.com>:
>>> 
>>> Hi Johannes,
>>> 
>>> Thanks for the input. I guess <graphic target="..." type="iiif" /> solves part of my problem - I can link to the manifest. However, I'm using Diva.js to display the contents so I can't reference a page directly with a URL. Rather, I have to load the entire manifest then give a page index to the Diva.js API to load. So, I guess my question now is if I can attach extra data to a <graphic> element.
>>> 
>>> I suppose what I could do (which is maybe cheating) is to assume my own graphic type -- let's call it 'divajs' -- that requires the target be a URI with a page parameter. So, I could have:
>>> 
>> 
>> this is exactly what I tried to say ;-)
>> 
>>> <graphic target="http://url/to/iiif/manifest.json#100" type="divajs" />
>>> 
>>> Is this still valid MEI?
>> 
>> yes. graphic/@target has "anyURI" as content, and @type is just a token of your choice. MEI doesn't know or define what @type="iiif" means, and since it's your application that has to make use of it, you can equally well use @type="divajs". The only problem I see with this setup is that
>> 
>>> http://url/to/iiif/manifest.json#100
>> 
>> is not a regular URI (at least to my knowledge): Unlike in HTML, the hash has no specific meaning to get something inside a JSON file. However, if I got that right, IIIF is using JSON-LD. Following the documentation [1], each page is defined using a separate object in an array:
>> 
>> "canvases": [
>> 	{"@id":"http://www.example.org/iiif/book1/canvas/p1",
>> 	"@type":"sc:Canvas",
>> 	"label":"p. 1"
>> 	// ...
>> 	},
>> //...
>> ]
>> 
>> The @id value is intended as the "official" link to this item. However, if you use mei:graphic/@target to point to this, you loose the reference to the manifest itself. You could add a bunch of redirects to your web server to resolve those links to the manifest, but this feels equally strange as the "…/manifest.json#p100" solution.
>> 
>> I'd love to hear how the folks at McGill handle this…
>> jo
>> 
>> 
>> 
>>> 
>>> Tx,
>>> 
>>> Ryan
>>> 
>>> On Fri, Oct 14, 2016 at 1:10 PM, Johannes Kepper <kepper at edirom.de> wrote:
>>> Hi Ryan,
>>> 
>>> right now, I'm still using individual <surface> elements inside <facsimile>, one for each page. Each surface then has a <graphic target="path/to/manifest.json" type="iiif/>. This works mostly because I don't have a manifest for all pages (yet), but individual for each page. This is clearly not ideal, but works for me for the time being. I wouldn't mind to link to the same manifest from multiple targets, and then use some kind of URI mechanism to refer to a specific page inside that manifest. I'm not that familiar with IIIF, but afaik, each page (canvas) has an "@id" property, which can be used as target for the reference. I know the following syntax isn't working out of the box, but you may get the idea:
>>> 
>>> <facsimile>
>>>       <surface label="fol 3v">
>>>               <graphic target="path/to/manifest.json#page17" type="iiif/>
>>>               <zone/><!-- if you like… -->
>>>       </surface>
>>> </facsimile>
>>> 
>>> Like you, I'm keen to learn about better ways to do this ;-)
>>> jo
>>> 
>>> 
>>>> Am 14.10.2016 um 18:47 schrieb Michael Ryan Bannon <ryan.bannon at gmail.com>:
>>>> 
>>>> Hello MEI-ers,
>>>> 
>>>> I've been going over the MEI guidelines to find the best way of associating an external image manifest with an MEI <facsimile>, but I haven't had much luck. In particular, I'm dealing with images hosted on an IIIF server. So, I wouldn't necessarily have a URL to the image. Rather, I would have:
>>>> 
>>>> - URL to an IIIF manifest
>>>> - indices of pages in the manifest
>>>> 
>>>> I'm guessing the best solution is to have a <ref> element in my <meiHead> somewhere, then point to that <ref> from the <facsimile> element? (That's my best guess as I can't see how <facsimile> could contain the IIIF manifest URL or page indices, unless I'm missing something.)
>>>> 
>>>> Any help is greatly appreciated.
>>>> 
>>>> Tx,
>>>> 
>>>> Ryan
>>>> _______________________________________________
>>>> mei-l mailing list
>>>> mei-l at lists.uni-paderborn.de
>>>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>>> 
>>> 
>>> _______________________________________________
>>> mei-l mailing list
>>> mei-l at lists.uni-paderborn.de
>>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>>> 
>>> _______________________________________________
>>> mei-l mailing list
>>> mei-l at lists.uni-paderborn.de
>>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>> 
>> 
>> _______________________________________________
>> mei-l mailing list
>> mei-l at lists.uni-paderborn.de
>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
> 
> 
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20161018/16faaf79/attachment.sig>