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

Tue Oct 18 14:38:16 CEST 2016

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. :)

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20161018/50ada6a5/attachment.html>