Social/UX barriers to IIIF interoperability?

[Ben Brumfield]

This morning, my wife pointed me at an article about miniature adventure stories written by Charlotte Bronte and her brother when they were children, with the comment, "They desperately need a transcription platform."  I responded that, of course, she could probably start one herself on FromThePage via the IIIF importer I worked on last month, since I know Harvard's on board with IIIF.  But further investigation revealed some challenges that may be of interest to this group. 

Let's look at the steps required to get from article to IIIF API:

1. Scan over the 2014 article on Open Culture ("13-Year-Old Charlotte Brontë & Her Brother Wrote Teeny Tiny Adventure Books, Measuring 1 x 2 Inches") for references to the library website itself.
2. Skim the 2014 article in the Harvard Gazette "The Genesis of Genius" for references to the library website.
3. Click on the promising link "are available in full, free, online" to get a 404 page on hollis.harvard.edu
4. Give up on finding the collection and click on a link to a specific document:  Scenes on the great bridge, November 1829
5. Discover the facsimiles of "Scenes on the great bridge" on Harvard's PDS!
6. Click on the Copyright statement to see the possibilities for re-use, getting the following assertion that seems both legally risable (ignorant of Bridgeman v. Corel) and actively hostile to re-use:
   

   This material is owned, held, or licensed by the President and Fellows of Harvard College. It is being provided solely for the purpose of teaching or individual research. Any other use, including commercial reuse, mounting on other systems, or other forms of redistribution requires permission of the appropriate office of Harvard University.
   

7. Click on the "View in Beta" link, and spot IIIF in the URL -- now we're getting somewhere!
8. Find myself viewing the same document in Mirador, which means that yes, in fact, the documents are served via IIIF.  Hooray!
9. Scan around the page frantically for some link to the presentation manifest for the document (or better, the collection).
10. View source of the page, spotting this block of Javascript:
    

    MIRADOR_DATA: [ {"manifestUri": "http://iiif.lib.harvard.edu/manifests/drs:6131694", "location": "Harvard University", "title": "MS Lowell 1 (4). [Bront\u00eb, Charlotte, 1816-1855]. Scenes on the great bridge By the Genius C.B. : AMsS (initials) ; [Haworth], 1829 Nov. 8f.(16p.) 5.6 x 3.6 cm. Houghton Library."} ]

11. Victory!  I have a manifest that I can check via curl! 
    Sort of.  Because FromThePage can import entire IIIF collections for transcription, it would save me some time if I could find the collection manifest.  Where is the collection manifest?
12. No evidence of a collection manifest in the document manifest, nor in the Mirador page source.  Give up on the collection.
13. Double-check the Mirador page for a rights/permissions statement -- perhaps the technical updates to the site might have included policy updates?
14. Find the Info section, which brings up "Rights:" with no content.
    

So do I suggest my wife launch a transcription project for the Bronte juvenalia?  Technically it's possible, and would only take a handful of clicks/cut-and-paste per document.  The old Copyright statement gives me pause, however -- it may contravene Bridgeman v. Corel and the IIIF spirit of re-use, but do I want an institution with Harvard's resources mad at me?  Probably not.

Now, I don't intend to call out Harvard specifically here -- in fact, the IIIF server implementation I developed in Philadelphia is still only accessible via URL hacking, so every complaint I made about them applies to me as well!  (Okay, I don't make sweeping rights statements about content posted on the site, but on the other hand the IIIF client functionality of FromThePage is only accessible via a secret URL, so let's call it even.)

Aside from the rights issue, I do have a couple of technical recommendations I can make from the experience:

• When presenting IIIF-enabled content, expose the manifest URL somehow.  Drew and Simon did a lot of work on this in Philadelphia, but the rest of us--me included--need to implement it, both in servers and clients.
• Include a link to the collection manifest in a document manifest whenever possible.  I think the API (section 4.4) suggests using "within" for this, but I'm not seeing it used on a lot of manifests in the iiif-universe, and need to include it on my own as well.

To end on a positive note, let's not lose site of the fact that, thanks to this community and the participation by Harvard, it is possible to transcribe facsimiles hosted by Harvard on an unrelated platform like FromThePage.  That's a real achievement.

Ben

http://fromthepage.com/

[Stern, Randy]

Hi Ben,

Thanks for your entertaining narrative! You have highlighted an area in which the IIIF community is actively working - the discovery and reuse of available IIIF materials. You further highlight the need to contextualize works within collections in such a discovery environment.

Our Harvard Mirador instance is in Beta, and highlighting the link to the manifest is one item on our to do list.

Keep the comments and suggestions coming!

Randy

--
-- You received this message because you are subscribed to the IIIF-Discuss Google group. To post to this group, send email to iiif-d...@googlegroups.com. To unsubscribe from this group, send email to iiif-discuss...@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/iiif-discuss?hl=en
---
You received this message because you are subscribed to the Google Groups "IIIF Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to iiif-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Robert Sanderson]

Thanks Ben,

To invert the order (apologies) such that the IIIF specific actions are the top:

Aside from the rights issue, I do have a couple of technical recommendations I can make from the experience:

• When presenting IIIF-enabled content, expose the manifest URL somehow.  Drew and Simon did a lot of work on this in Philadelphia, but the rest of us--me included--need to implement it, both in servers and clients.

Totally agreed. And to make that happen, we (IIIF community) need to be explicit about how implementers should expose the manifest URL in a way that's appealing and obvious to non-technical folks.  The drag and drop work done in Philadelphia is a great start and needs some followup:

  * An API note about how to do it, linked from some more descriptive and easy to find document

  * An attractive, very liberally licensed (CC0?) icon to use for it 

  * Implementations in existing discovery systems to provide the drag

  * Implementations in clients to accept the drop

There's an issue for tracking drag and drop:  https://github.com/IIIF/iiif.io/issues/602

And a related issue for microdata: https://github.com/IIIF/iiif.io/issues/557

• Include a link to the collection manifest in a document manifest whenever possible.  I think the API (section 4.4) suggests using "within" for this, but I'm not seeing it used on a lot of manifests in the iiif-universe, and need to include it on my own as well.

And totally agreed again :)  Perhaps a best practice in the descriptive document for discovery.  There's already the means to take this forwards, we just need to encourage people to make use of it.  To make it worthwhile, however, there needs to be:

* Implementations in clients for Collections, generally. Collections were discussed and proposed at the Harvard technical meeting in 2013 (IIRC?) as a solution for creating a hierarchy of manifests for discovery, but as you point out, Mirador still uses its own proprietary format.

* UI/UX to follow links to collections from Manifests, and from there back to the other Collections and Manifests.

* Collections to exist!

* A community supported crawler to more fully populate the known universe of IIIF content, in a well known location (e.g. somewhere linked on iiif.io) and easy to add to.

* A search and/or browse UI built on top of that data

There isn't an issue specifically about this yet, so I'll make one.

Related to publishing the discovery data: https://github.com/IIIF/iiif.io/issues/517

And on to the workflow ...

On Fri, Nov 13, 2015 at 7:40 AM, Ben Brumfield <benw...@gmail.com> wrote:

Let's look at the steps required to get from article to IIIF API:

1. Scan over the 2014 article on Open Culture [...]

We're not going to solve either issue of getting reuse rights for content clearly expressed (though we can and should promote institutions doing this!) or semantic search in IIIF. There's too much variation and too many unique requirements, and there's other work going on in both spaces that we can leverage.

1. Click on the "View in Beta" link, and spot IIIF in the URL -- now we're getting somewhere!

This seems like the starting point for IIIF.  Exactly how you discover the object described in the Manifest will be very different for every case ... at least until Google starts to take notice :)

And this is where the drag/drop link should also be, to skip past the next steps.

 

1. Victory!  I have a manifest that I can check via curl! 
   Sort of.  Because FromThePage can import entire IIIF collections for transcription, it would save me some time if I could find the collection manifest.  Where is the collection manifest?

And this is where the within up link to collections is important, but the processing of it is dependent on the client business logic. 

So we should be able to reduce the workflow to something that implementers can easily do, both on the client and content provision sides, and that regular users can do without understanding the machinery behind the scenes :)

Rob

--

Rob Sanderson

Information Standards Advocate

Digital Library Systems and Services

Stanford, CA 94305

[Ben Brumfield]

Thanks to Randy for accepting the email in the spirit in which I hoped to offer it -- I look forward to following the rest of Harvard's Mirador work.

Rob, I only can disagree with one issue in your comments:

On Friday, November 13, 2015 at 11:38:45 AM UTC-6, Rob Sanderson wrote:

Totally agreed. And to make that happen, we (IIIF community) need to be explicit about how implementers should expose the manifest URL in a way that's appealing and obvious to non-technical folks.  The drag and drop work done in Philadelphia is a great start and needs some followup:

  * An API note about how to do it, linked from some more descriptive and easy to find document

  * An attractive, very liberally licensed (CC0?) icon to use for it 

  * Implementations in existing discovery systems to provide the drag

  * Implementations in clients to accept the drop

In addition to implementations in clients to accept manifest drops, I think we also need clients to present (or re-present) the manifests they're consuming, just as we hope servers and discovery systems will do. 

My experience this morning was of bypassing a discovery system entirely -- my first interaction with the IIIF-enabled document was within Mirador, deep-linked from elsewhere.  

Let's say an organization has digitized manuscript material through the Internet Archive, and is using FromThePage to transcribe that collection (a real-world use-case).  Furthermore, let's hypothesize that I've updated the code to interact with IA primarily through IIIF instead of the Bookreader.  If a researcher discovers the documents on FromThePage instead of Archive.org--as is likely if they've searched for transcribed text--and if that researcher wants to add the documents to an annotation project in Mirador or present them via the Universal Viewer, then they'll need FromThePage to present that manifest in order to ingest those documents.

In that case, even though the transcription tool is acting as a IIIF client, we'd want it to expose a IIIF manifest -- even if it only deep-links to the original manifest on the IIIF server.

Does that make sense?

Ben

[Robert Sanderson]

On Fri, Nov 13, 2015 at 11:24 AM, Ben Brumfield <benw...@gmail.com> wrote:

Rob, I only can disagree with one issue in your comments:

On Friday, November 13, 2015 at 11:38:45 AM UTC-6, Rob Sanderson wrote:

Totally agreed. And to make that happen, we (IIIF community) need to be explicit about how implementers should expose the manifest URL in a way that's appealing and obvious to non-technical folks.  The drag and drop work done in Philadelphia is a great start and needs some followup:

  * An API note about how to do it, linked from some more descriptive and easy to find document

  * An attractive, very liberally licensed (CC0?) icon to use for it 

  * Implementations in existing discovery systems to provide the drag

  * Implementations in clients to accept the drop

In addition to implementations in clients to accept manifest drops, I think we also need clients to present (or re-present) the manifests they're consuming, just as we hope servers and discovery systems will do.

Yep, sorry, I didn't mean to imply the list was comprehensive :)

 

In that case, even though the transcription tool is acting as a IIIF client, we'd want it to expose a IIIF manifest -- even if it only deep-links to the original manifest on the IIIF server.
Does that make sense?

To re-express slightly:  
  * Client implementations should also expose a drag link for the manifests it renders to allow transfer to other clients/systems

Yes?

R

[Ben Brumfield]

On Friday, November 13, 2015 at 1:30:58 PM UTC-6, Rob Sanderson wrote:

To re-express slightly:  

  * Client implementations should also expose a drag link for the manifests it renders to allow transfer to other clients/systems

Yes?

Perfect!
Ben

[Simeon Warner]

I think that, as Rob mentioned, we need "An attractive, very liberally
licensed (CC0?) icon to use" for drag and drop. Is anyone out there in
IIIF-space able to come up with an icon or icons?

Probably something based on or incorporating the standard IIIF Logo [1]
would be good. I assume source files for that are somewhere with
Stanford folks?

Cheers,
Simeon

[1]
https://github.com/IIIF/iiif.io/blob/master/source/img/logo-iiif-34x30.png

> --
> -- You received this message because you are subscribed to the
> IIIF-Discuss Google group. To post to this group, send email to
> iiif-d...@googlegroups.com. To unsubscribe from this group, send
> email to iiif-discuss...@googlegroups.com. For more options,
> visit this group at https://groups.google.com/d/forum/iiif-discuss?hl=en
> ---
> You received this message because you are subscribed to the Google
> Groups "IIIF Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to iiif-discuss...@googlegroups.com

> <mailto:iiif-discuss...@googlegroups.com>.

[Jason Ronallo]

> * A community supported crawler to more fully populate the known universe of
> IIIF content, in a well known location (e.g. somewhere linked on iiif.io)
> and easy to add to.
> * A search and/or browse UI built on top of that data

Is there a list anywhere of sites that publish IIIF content that could
seed such a thing?

Jason

[Mek Karpeles]

Jason, et al:

Re: a list of sites that publish IIIF resources; I've been maintaining a small list of links to institutions which have taken steps to publish their collections of their IIIF resources:

 

https://graph.global/universes/iiif

Unfortunately, some of these urls link to static dumps of data I've collected or crawls I've conducted of portals (e-codices), as most IIIF services don't expose a real-time mechanism for listing their resources. Right now this list only features 5 institutions (Yale, Stanford, Biblissima, e-codices, SCTA, and the Internet Archive) representing ~10M IIIF items.

Please do add a link to your institution's collection via the git repository here (or mail me and I'll add it):

https://github.com/ryanfb/iiif-universe/

I'd welcome for iiif.io to maintain such a list. Conceivably, the community would add IIIF server urls to a "registry" by submitting a url through the iiif.io website (like google does for their search engine) or alternatively through a git repo. I'm even happy to work on this with whomever can facilitate access.

That said... Even when we do achieve a close-to-universal registry of IIIF servers, the bigger imperative and opportunity (the elephant in the room) is deciding on a single standardized way for IIIF services to list their resources (collections, manifests)...

Warning, this is the grouchy section of my message (I'm really sorry, its nothing personal!). Also, I know the discovery spec (https://groups.google.com/forum/#!topic/iiif-discuss/_qUlCqzsBBw) is a lot farther than I am suggesting. Please take my comments with a grain of salt:

...It's my belief that querying a server's collections is a really nice-to-have addition, but not at the postponing of there existing some/any mechanism of listing what resources a IIIF server has. I (without exaggeration) believe a IIIF service should be required (even somehow retroactively for IIIF Image v1) to return a paginated list of its resource ids. As a work-around, I see more and more portals addressing this issue themselves by bypass their IIIF service and querying against some underlying (solr, elasticsearch, etc) index. Allowing for this to be the norm as (IIIF adoption accelerates and as) we "figure discovery out" undermines and weakens one of the biggest value propositions of the standard, which is its interoperability.

Hopefully I don't sound (too) bitter. I applaud our community's tremendous progress and efforts and I know we really are getting there. I also acknowledge I'm both being extreme/radical and I haven't by any means put in sufficient leg work to complain. I am simply voicing a personal frustration (from a stance of moral imperative) that, within the scope of IIIF, I don't believe there's any issue of greater importance than achieving a real-time universal index of all resources. I would literally stop everything and throw 100% of my efforts at addressing this and nipping it at the bud (exactly because I think it's so important to, and because I do care about, IIIF's sustained adoption).

I have been attempting to address the challenge independently (with https://graph.global/universes/iiif). When I noticed how daunting of a task this was (it's almost like services don't want their resources to be discovered!) and realized other end-users are facing the same challenge, I thought there had to be a better approach to getting the ball moving.

As a result, I implemented a IIIF service for the Internet Archive, almost solely for the purpose (other than believing in the mission of the IIIF s) of demonstrating what it might look like for a IIIF service to list all its resources. If you navigate to the link below, you'll see a paginated index of ~9.3M book and image IDs[1] served by the Internet Archive in IIIF format:

https://iiif.archivelab.org/iiif

If there's one point of this rant worth discussing, it's that: For an immediately actionable first step, I believe this type of exhaustive, paginated "collection" addresses a fundamental element of discovery, is both easily, technically and politically achievable with minimal change to our existing IIIF services, and doesn't necessitate complicated discussions about a standard DSL / query language, or other confounding facets of search, filtering, and discovery. 

Regarding an experimental "discovery", I'm working on an interface for the Archive's IIIF service whereby the user can issue arbitrary ElasticSearch queries to the following endpoint (not complete yet) and dynamically compose arbitrary collections of manifests. I don't propose this as a solution, just as inspiration for what's achievable (and a temporary solution so that people have the ability to discover via the IIIF service, as opposed to an un-interoperable portal, as we figure out a long-term solution)

https://iiif.archivelab.org/iiif/collection.json?q=

So, that's my rant and I'm here to help.

[1] Please do note, in the Archive's example, we recently moved from SOLR to ElasticSearch which is affecting the ordering of our results and thus idempotent paging through them -- I do apologize, I'm working on resolving that!

[Matt McGrattan]

• Include a link to the collection manifest in a document manifest whenever possible.  I think the API (section 4.4) suggests using "within" for this, but I'm not seeing it used on a lot of manifests in the iiif-universe, and need to include it on my own as well.

And totally agreed again :)  Perhaps a best practice in the descriptive document for discovery.  There's already the means to take this forwards, we just need to encourage people to make use of it.  To make it worthwhile, however, there needs to be:

* Implementations in clients for Collections, generally. Collections were discussed and proposed at the Harvard technical meeting in 2013 (IIRC?) as a solution for creating a hierarchy of manifests for discovery, but as you point out, Mirador still uses its own proprietary format.

* UI/UX to follow links to collections from Manifests, and from there back to the other Collections and Manifests.

* Collections to exist!

* A community supported crawler to more fully populate the known universe of IIIF content, in a well known location (e.g. somewhere linked on iiif.io) and easy to add to.

* A search and/or browse UI built on top of that data

There isn't an issue specifically about this yet, so I'll make one.

Related to publishing the discovery data: https://github.com/IIIF/iiif.io/issues/517

On top of just exposing pre-canned Collections, what's the simplest model here for the combination of search across/discovery, collections, and manifests?

Something like a search service that takes a search query [syntax could be mandated, or just be free], which returns a collection that contains all of the manifests that match that search query? Each individual manifest to contain a reference to the local discovery service so that if you've got one, you can also work out how to find more? That is, not just include a reference to the Collection that the manifest is within, but to the discovery service that was used to generate the collection.

I know the Wellcome already do something like this, I'm pretty sure others do to, and it'd be trivially easy [hours of work, not days] to implement something similar for Digital.Bodleian.  

Then a putative IIIF cross-collection search would have a list of search service to query.

Matt

[Mek Karpeles]

I agree, Matt. Though I still maintain the easiest victory /  first step is to expose a paginated list of resource IDs. It's both the least work to implement, a common convention for HTTP REST interfaces, and the greatest win (physically discovering resources is a hard problem, retroactively harvesting metadata about these resources, towards universal search, is made achievable from this starting point). 

For what it's worth, I also think a crawler approach (while a great idea and a good demonstration of the principle) may be counter-intuitive to our desired outcome (it treats the symptom, not the problem). With minimal modification (as Matt describes) IIIF Services have the ability to self-report their resources in real-time, which is better (fresher, faster propagation, more comprehensive) than we can hope to accomplish with a crawler.

[Ed Summers]

> On Nov 15, 2015, at 7:45 AM, Mek Karpeles <michael....@gmail.com> wrote:
>
> https://iiif.archivelab.org/iiif/collection.json?q=

I very much agree that we should encourage people to make high-level collection views available. One other way of convincing people is that they are very useful for internal indexing and administrative services.

In your example you have:

{
"@context": "http://iiif.io/api/image/2/context.json",
"@id": "https://iiif.archivelab.org/collection.json",
"@type": "sc:Collection",
"collections": [
{
"@type": "sc:Collection",
"id": "https://iiif.archivelab.org/BABYPEQ/manifest.json",
"label": ""
},
...
]
}

The resource at https://iiif.archivelab.org/BABYPEQ/manifest.json is actually a manifest. So don't you want something like this instead?

{
"@context": "http://iiif.io/api/presentation/2/context.json",
"@id": "https://iiif.archivelab.org/collection.json",
"@type": "sc:Collection",
"label": "Sonograms",
"manifests": [
{
"@type": "sc:Manifest",
"id": "https://iiif.archivelab.org/BABYPEQ/manifest.json",
"label": "Sonogram 1"
},
...
]
}

It looked like you were going to have a collection of collections, which is perfectly fine, as long as you point at actual collections rather than manifests.

Thanks for your rant, and all the work you are doing at archive.org with IIIF!

//Ed

[Mek Karpeles]

Ed -- yes, you're right! I'll jump on that tomorrow (and will try to make some of the other proposed changes as well). Thank you!

[Jason Ronallo]

Naive question but is there something like sitemaps that could be used
to discover IIIF resources? Or is this what manifests do? Creating
something like a sitemap or sitemap extension seems simpler still for
implementers than some sort of pagination query through them all. For
general SEO I'm already creating sitemaps and using sitemap protocol
extensions like the video extension to improve discovery of those
resources. Or are there reasons with IIIF published resources where
sitemaps would not work?

Jason

> --
> -- You received this message because you are subscribed to the IIIF-Discuss
> Google group. To post to this group, send email to
> iiif-d...@googlegroups.com. To unsubscribe from this group, send email to
> iiif-discuss...@googlegroups.com. For more options, visit this
> group at https://groups.google.com/d/forum/iiif-discuss?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "IIIF Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to iiif-discuss...@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.

[Mek Karpeles]

Sitemaps too are a great first step, they accomplish the goal of having "something" re: a list of resources published somewhere. Ordering, completeness, data rot, and computational expense are all considerations --

The end goal is interoperability between iiif services and a mechanism for programmatic discovery. If a sitemap can guarantee ordering of its resource listing across update (is dynamically generated), and is computationally feasible for services with tens of millions of resources, that's great. I imagine services with this many items will cash there sitemap, meaning it wouldn't be complete. It seems like an undesirable outcome for most the majority of services to have out of date indices. There's also a matter of extensibility. A sitemap needs to be in a specific format in order to be useful to a search engine. As we continue to develop the discovery spec, we will want something which can be extended and show different granularities have data depending on what the user requests. Having something granul tell him see mission critical tell him see mission critical, but it is important to not get locked into a specific format which will severely limit our future capabilities.

A paginated index would maintain the standard of using json (and allow services a more robust, order-guaranteed way of aggregating listings across iiif services), be less computationally expensive (only certain pages need to be fetched at a time), is always fresh / real-time and complete (no data rot or missing entries), and can be easily extended to fulfill future needs.

E.g. with pagination, if you want to see what resources have changed on a server, you just have to look at the last few pages, (essentially a diff).

In terms of extensibility, we might want the option to create a json collection from this listing endpoint (as is the Archive's use case: https://iiif.archivelab.org/iiif/collection.json). After all, the iiif server is already supposed to have the ability to serve collections and it would be a real pain in the butt for clients to have to repeat all this work from raw sitemap data (it seems like an unnecessary interchange format when the spec describes an exact data structure for accomplishing this). Is a sitemap capable of encoding all the information that we would want in these manifests? Something to consider as we grow.

[Robert Sanderson]

Just to clarify ... this seems like a call to action to publish (either statically or dynamically) IIIF Collections that can be crawled, rather than anything being missing to enable that?

Would integration of pagination relationships into Collections, Layers and AnnotationLists (next/prev/first/last) in the Presentation API description help? The search spec being discussed for searching within sets of annotations could be more broadly applicable?

(This is issue: https://github.com/IIIF/iiif.io/issues/598)

Rob

--
-- You received this message because you are subscribed to the IIIF-Discuss Google group. To post to this group, send email to iiif-d...@googlegroups.com. To unsubscribe from this group, send email to iiif-discuss...@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/iiif-discuss?hl=en
---
You received this message because you are subscribed to the Google Groups "IIIF Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to iiif-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Matt McGrattan]

By way of taking a step in the direction of removing the social/UX barriers, drag and drop is now live on the main Digital.Bodleian site.

http://digital.bodleian.ox.ac.uk

[click through to the main UI]

The IIIF icon below the metadata panel is now draggable, and has been tested against Mirador and the Universal Viewer.

Collections, and a collection service to follow shortly.

Cheers!

Matt