When an image file is uploaded via the GUI, the process is something along these lines:

• upload the image file, and store in a temporary location.
• ask the user for a cropping square to be used in producing the thumbnail.
• create a URI for the image file surrogate object, and a URI for the image file bytestream object.
• create a URI for the thumbnail surrogate object, and a URI for the thumbnail bytestream object.
• hand the image file bytestream URI and the temporary file to the File Storage system, which will create a permanent storage.
• generate a 115 by 115 JPEG thumbnail image from the main image and the cropping square.
• hand the thumbnail image stream and the thumbnail bytestream URI to the File Storage system, which will create a permanent storage.
• create a thumbnail bytestream object in the model.
• create a thumbnail surrogate object in the model, storing the filename of the thumbnail, the mime type of the thumbnail, and the URI of the thumbnail bytestream.
• create a main image bytestream object in the model.
• create a main image surrogate object in the model, storing the filename of the main image, the mime type of the main image, and the URI of the main image bytestream.
• link the main image surrogate object to the person object.

These are no more than a multitude of technical details, except: how do you find an appropriate region of the image to use as the thumbnail?

Generating the thumbnail itself can be quite problematic if the initial image is a GIF or PNG with transparency.

For an individual on my test installation (in N3, if I remember how to write it)

INDIVIDUAL

  <http://vivo.mydomain.edu/individual/n1451>
      http://vitro.mannlib.cornell.edu/ns/vitro/public#mainImage 	
              http://vivo.mydomain.edu/individual/n1674.
 

IMAGE FILE SURROGATE

  <http://vivo.mydomain.edu/individual/n1674>
      http://vitro.mannlib.cornell.edu/ns/vitro/public#thumbnailImage
              http://vivo.mydomain.edu/individual/n5863; 
      http://vitro.mannlib.cornell.edu/ns/vitro/public#downloadLocation
              http://vivo.mydomain.edu/individual/n3156;
      http://vitro.mannlib.cornell.edu/ns/vitro/public#mimeType
              "image/jpeg";
      http://vitro.mannlib.cornell.edu/ns/vitro/public#filename
              "lily1.jpg";
      http://vitro.mannlib.cornell.edu/ns/vitro/0.7#modTime
              "2010-10-18T09:51:58";
      http://www.w3.org/1999/02/22-rdf-syntax-ns#type
              http://vitro.mannlib.cornell.edu/ns/vitro/public#File;
      http://www.w3.org/1999/02/22-rdf-syntax-ns#type
              http://www.w3.org/2002/07/owl#Thing.
 

IMAGE FILE BYTESTREAM

  <http://vivo.mydomain.edu/individual/n3156>
      http://vitro.mannlib.cornell.edu/ns/vitro/0.7#modTime
              "2010-10-18T09:51:57";
      http://www.w3.org/1999/02/22-rdf-syntax-ns#type
              http://vitro.mannlib.cornell.edu/ns/vitro/public#FileByteStream;
      http://www.w3.org/1999/02/22-rdf-syntax-ns#type
              http://www.w3.org/2002/07/owl#Thing.
 

THUMBNAIL SURROGATE

  <http://vivo.mydomain.edu/individual/n5863>
      http://vitro.mannlib.cornell.edu/ns/vitro/public#downloadLocation
              http://vivo.mydomain.edu/individual/n5889;
      http://vitro.mannlib.cornell.edu/ns/vitro/public#mimeType
              "image/jpeg";
      http://vitro.mannlib.cornell.edu/ns/vitro/public#filename
              "thumbnail_lily1.jpg";
      http://vitro.mannlib.cornell.edu/ns/vitro/0.7#modTime
              "2010-10-18T09:52:12";
      http://www.w3.org/1999/02/22-rdf-syntax-ns#type
              http://vitro.mannlib.cornell.edu/ns/vitro/public#File;
      http://www.w3.org/1999/02/22-rdf-syntax-ns#type
              http://www.w3.org/2002/07/owl#Thing.
 

THUMBNAIL BYTESTREAM

  <http://vivo.mydomain.edu/individual/n5889>
      http://vitro.mannlib.cornell.edu/ns/vitro/0.7#modTime
              "2010-10-18T09:52:12";
      http://www.w3.org/1999/02/22-rdf-syntax-ns#type
              http://vitro.mannlib.cornell.edu/ns/vitro/public#FileByteStream;
      http://www.w3.org/1999/02/22-rdf-syntax-ns#type
              http://www.w3.org/2002/07/owl#Thing;
 

The file system looks something like this:

File storage properties file: /usr/local/vivo/uploads/file_storage_namespace.properties

a = http://vivo.mydomain.edu/individual/

Main image:

Thumbnail:

Note: The file storage system does "laundering" on the filenames, in order to allow files with special characters to be stored in a portable manner (e.g., Linux or Windows).

Jim

A summary from Eliza Chan

Excerpted from a message in the vivo-dev-all archive, by Eliza Chan, dated 2010-11-04 16:08

As an experiment tested on localhost, when the pictures were uploaded using a "non-traditional" method, i.e. copying directly to the folder /usr/local/vivo/data/uploads/file_storage_root/a~n, the content under primary tab became blank (see attachment localhost_vivo_mainTab.tiff). Pictures did show up but only when the primary tab content was clicked (see attachment localhost_vivo_tabContent.tiff). The reason for copying directly to the folder was to save the work for doing manual upload of about 1000 photos.

The way it was done was as follows:

1. Create RDF for images and add to the VIVO site, e.g.

2. Copy images to the following folders:

Update on "alias URL" and "directDownloadUrl" property

You can retrieve an image file by asking for the Individual page of its FileByteStream. For example,

http://localhost:8080/vivo/individual/n4898

VIVO will see that this particular individual is a FileByteStream, and will redirect your browser to the "alias URL" for that image. In this case:

http://localhost:8080/vivo/file/n4898/john_doe.jpg

This redirection means that the image shown in your browser has a name that you will recognize, with an appropriate file type. If you choose "Save Image" in your browser, the default filename will be suitable for the image.

However, this redirection implies additional overhead. Pages local to VIVO calculated the alias URL and used it as the "src" property on the image, avoiding the redirection. But because the "alias URL" was not present in the RDF, it was not available to external applications, which resulted in excessive load times for pages that displayed dozens of images.

The directDownloadUrl" property of FileByteStream objects contains the "alias URL", is created when the image is ingested, and is used both by VIVO and by external applications when displaying images.

Accordingly, the FileByteStream examples shown above must now look like this instead:

IMAGE FILE BYTESTREAM

  <http://vivo.mydomain.edu/individual/n3156>
      http://vitro.mannlib.cornell.edu/ns/vitro/0.7#modTime
              "2010-10-18T09:51:57";
      http://www.w3.org/1999/02/22-rdf-syntax-ns#type
              http://vitro.mannlib.cornell.edu/ns/vitro/public#FileByteStream;
      http://www.w3.org/1999/02/22-rdf-syntax-ns#type
              http://www.w3.org/2002/07/owl#Thing.
      http://vitro.mannlib.cornell.edu/ns/vitro/public#directDownloadUrl
              "/file/n3156/lily1.jpg"
 

THUMBNAIL BYTESTREAM

  <http://vivo.mydomain.edu/individual/n5889>
      http://vitro.mannlib.cornell.edu/ns/vitro/0.7#modTime
              "2010-10-18T09:52:12";
      http://www.w3.org/1999/02/22-rdf-syntax-ns#type
              http://vitro.mannlib.cornell.edu/ns/vitro/public#FileByteStream;
      http://www.w3.org/1999/02/22-rdf-syntax-ns#type
              http://www.w3.org/2002/07/owl#Thing;
      http://vitro.mannlib.cornell.edu/ns/vitro/public#directDownloadUrl
              "/file/n5889/thumbnail_lily1.jpg"