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

Tue Oct 18 15:32:24 CEST 2016

> Am 18.10.2016 um 14:38 schrieb Michael Ryan Bannon <ryan.bannon at gmail.com>:
> 
> The problem is that diva.js is not able to load an image just by the image uri. It requires the entire manifest. But, at this point, it's no longer an mei concern. :)
> 

well, yes and no. Of course the problem surfaces because of a specific software's needs. However, the real question (here) is not how Diva.js handles image URIs, but how IIIF fits into MEI. It seems like a sensible idea to be able to link not only to the graphic, but also the IIIF manifest. Right now, one has to decide between the two of them. I could imagine to allow something like @authURI (through att.authorized) and @codedval (through att.canonical) on graphic. The descriptions of these attributes don't make a perfect match, but a use like this seems to be in the spirit of what they're supposed to do. In essence, @authURI would point to the manifest, while @codedval would point to an identifier for the page in question in that manifest.

This is just a first, naive try. Maybe others have better ideas?
jo

> 
> On Oct 18, 2016 06:25, "Johannes Kepper" <kepper at edirom.de> wrote:
> 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
> 
> 
> _______________________________________________
> 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/031e1418/attachment.sig>