IIIF media not importing with CSV Import

Omeka S
1

Old topic, sort of, and haven’t been able to get back to this for awhile but wanted to follow up. I’m on Omeka S 1.2.0 and just tried CSVImport with Media Import -> IIIF Image. In my csv file my column with IIIF image URL’s look like the following:

http://libme25-0479439.mit.edu:8182/iiif/2/IAA118525.jp2/info.json
http://libme25-0479439.mit.edu:8182/iiif/2/IAA118547.jp2/info.json

but the import fails immediately with ‘Invalid URL’ messages in the error log:

Stack trace:
#0 /var/www/html/omeka-s/application/src/Api/Adapter/AbstractEntityAdapter.php(267): Omeka\Api\Adapter\AbstractEntityAdapter->hydrateEntity(Object(Omeka\Api\Request), Object(Omeka\Entity\Item), Object(Omeka\Stdlib\ErrorStore))
#1 /var/www/html/omeka-s/application/src/Api/Manager.php(224): Omeka\Api\Adapter\AbstractEntityAdapter->create(Object(Omeka\Api\Request))
#2 /var/www/html/omeka-s/application/src/Api/Manager.php(78): Omeka\Api\Manager->execute(Object(Omeka\Api\Request))
#3 /var/www/html/omeka-s/application/src/Api/Adapter/AbstractEntityAdapter.php(310): Omeka\Api\Manager->create(‘items’, Array, Array, Array)
#4 /var/www/html/omeka-s/application/src/Api/Manager.php(227): Omeka\Api\Adapter\AbstractEntityAdapter->batchCreate(Object(Omeka\Api\Request))
#5 /var/www/html/omeka-s/application/src/Api/Manager.php(97): Omeka\Api\Manager->execute(Object(Omeka\Api\Request))
#6 /var/www/html/omeka-s/modules/CSVImport/src/Job/Import.php(83): Omeka\Api\Manager->batchCreate(‘items’, Array, Array, Array)
#7 /var/www/html/omeka-s/modules/CSVImport/src/Job/Import.php(61): CSVImport\Job\Import->createEntities(Array)
#8 /var/www/html/omeka-s/application/src/Job/DispatchStrategy/Synchronous.php(37): CSVImport\Job\Import->perform()
#9 /var/www/html/omeka-s/application/src/Job/Dispatcher.php(105): Omeka\Job\DispatchStrategy\Synchronous->send(Object(Omeka\Entity\Job))
#10 /var/www/html/omeka-s/application/data/scripts/perform-job.php(43): Omeka\Job\Dispatcher->send(Object(Omeka\Entity\Job), Object(Omeka\Job\DispatchStrategy\Synchronous))
#11 {main}
2018-09-25T22:53:52+00:00 ERR (3): exception ‘Omeka\Api\Exception\ValidationException’ in /var/www/html/omeka-s/application/src/Api/Adapter/AbstractEntityAdapter.php:571
Errors:
{
“o:media”: [
{
“o:source”: [
“Error decoding IIIF JSON”
]
},
{
“o:source”: [
“Invalid URL specified”
]
}
]
}

Using Cantaloupe 4.0 image server.

Hopefully something silly on my end; must be working for someone, right?

Here’s a line from the csv file:

id,type,placename,title,year,copyright,filename,jp2name,iiif_image
IAA118676,35 mm color slide,Rusafa,Rusafa. Northern Gate. Interior View.,1987|ca. 1987,Aga Khan Documentation Center at MIT,IAA118676,IAA118676.jp2,http://libme25-0479439.mit.edu:8182/iiif/2/IAA118676.jp2/info.json

Thanks.

Carl

2

That “invalid URL” error happens when the URL you give us doesn’t look like a URL (or doesn’t look like an absolute URL).

The URLs you mention in this post don’t trip that particular error, so something else is probably happening somewhere in the importer or in the CSV file itself that’s making the URL string not be exactly what you’re posting. Extra whitespace, for example, could be an issue. Or just mapping the IIIF source to the wrong column altogether, but I assume that’s not what’s happening here.

3

Hmmm. Just as a basic check, I just tried to edit an item and adding the URL for image file (Media -> IIIF Image -> IIIF Image URL) . The URL works (returns the expected information about the file) in my web browser but when I tried to save the URL in Omeka

http://libme25-0479439.mit.edu:8182/iiif/2/VBI-000576-001.jp2/info.json

it generates the message:

 Omeka S Encountered an Error

I’m guessing, then, it’s something with my test environment setup (Omeka S running under Vagrant and Virtual Box) and will investigate further. See if there’s any more Omeka logging information as well as check the Cantaloupe log.

FWIW, I’ve edited individual items and added the IIIF Image URL successfully in the past and guessing something is not quite right with my server setup or perhaps even network. configuration related.

Thanks.

4

i’ve been in the same problem
the error message was

ERR (3): exception ‘Omeka\Api\Exception\ValidationException’ in /www/html/omeka/application/src/Api/Adapter/AbstractEntityAdapter.php:571
Errors:

and after i found there was “,” in my file name, the problem solved.
try check your file names, also.

5

Problem appears to be network related on my end. Long story, but by using a different server I was able to successfully get Omeka-S to load images using IIIF info.json URL’s (e.g., http://libme25-0479439.mit.edu:8182/iiif/2/IAA118613.jp2/info.json) in my record. I can view the image with the default viewer (OpenSeadragon?) if I click on the URL in the ‘Other Media’ field in the record. Otherwise, only item metadata will display. As you can imagine, this isn’t quite the behavior I’m looking for.

However, I may be wrong about this, for Universal Viewer to automatically display an image coming from the IIIF server I have to supply a URL pointing to a manifest (e.g. in the ‘Has Format’ or some other field which we set in the UniversalViewer module configuration page). To do this for all my items would require (programmatically) creating a simple manifest for what are mostly items representing a single image and populating the Has Format or other field.

Sample item here with remote IIIF server with UV: http://libme25-0479439.mit.edu:8080/omeka-s/s/tabbaa/item/16296

Ideally, I would like to automatically display a small (probably larger than thumbnail-sized) image of the object once the item record is displayed – initially without the embedded IIIF viewer – and then click on the image which would launch UV or other IIIF image viewer.

At any rate, my goal is to test Omeka-S with an external IIIF image server and Universal Viewer. Because of time-limitations and many interruptions it’s been a bit of a winding path but I do seem to be getting closer to knowing what works.

Carl

6

If you have iiif server, you don’t have to set the manifest, it is automatically used, unless if there is a specific url in the dcterms:hasFormat. You may create manifest only if you want specific things in your manifest, or if its creation is too slow. And that’s your case: your want to use a remote iiif server, so you have to fill the url of the manifests in all your items.
Your url is an internal one, so it cannot be checked on the web. Anyway, the server should accept cors headers.

7

Hi Daniel,

Appreciate your comments. Hosting our images on a remote IIIF server (separate from Omeka-S) is one of our possible use-cases. Images do display correctly in UV without manifests if loaded directly into the Omeka-S instance using the internal IIIF image server. It’s our call which way to go, but at least the options are clear.

Also, sorry for the unusable URL. We moved to a new building and these URLs apparently aren’t recognizable to outside networks. Would not be a factor if we go into production but annoying on many levels when testing.

Thanks, again.

Carl

8

This should be something you can do with a theme pretty easily… you’d show thumbnails on the item’s page, and each thumbnail would link to the associated media page which would have the “real” viewer (it is OpenSeadragon by default). I think the thumbnails or the size thereof is probably the only difference there from the bog-standard item page.