source: gs3-installations/intermuse/trunk/sites/intermuse/collect/demo-localhost/INDEX-IIIF-MANIFEST.sh@ 38294

#!/bin/bash

source ../_local_collect_config.sh


# Build up URL through static 'site' URL to collect/<openannotation>.json
#iuri_prefix=http://localhost:4343/greenstone3/library/sites/intermuse/collect/$col

## ifilename=${1:-archives/HASH012c.dir/openannotation-list.json}
#ifilename=${1:-amadeus-iiif-manifest--with-otherContent.json}


##iuri_tail=${ifilename#archives/}

##iuri="${iuri_prefix}${iuri_tail}"
#iuri="${iuri_prefix}/${ifilename}"


docid="${1:-HASH012cd965c3e83d504f4a78cd}"

download_url="$gs_library_url/collection/$col/document/$docid"
download_url="$download_url?sa=iiif-manifest&ed=1&includeFileAssocOpenAnnotations=true&excerptid-text=iiif-manifest"

if [ ! -d tmp ] ; then
echo ""
    echo "Making directory 'tmp'"
    mkdir tmp
fi

# Workaround for JSON parsing error.  When using the Greenstone document URL directly
# then POSTing to /simpleAnnotationStore/manifests resulted in a JSON error
# Issue caused by leading blank space
#
# Workaround is to download it as collect/tmp/doc-openannotation--with-otherContent.json
# and as part of that process, strip out whitespace.
# Then a new URL is built to the collect/tmp/doc-openannotation--with-otherContent.json
# and that version of the file is POSTed to /simpleAnnotationStore/manifests

pid=$$

echo ""
echo "Downloading openannotation JSON for $docid as workaround to strip out leading blank space"
echo "  $download_url"
echo ""
curl --silent "$download_url" | egrep -v "^\\s*$" > tmp/doc-openannotation--with-otherContent--pid$pid.json


iuri="$gs_library_url/sites/$site/collect/$col/tmp/doc-openannotation--with-otherContent--pid$pid.json"

internal_url_base="http://localhost:$gs_http_port/simpleAnnotationStore"

post_url="${internal_url_base}/manifests"

echo ""

echo curl -X POST -d \"uri=${iuri}\" \"$post_url\"
#echo "[Dry run, suppressing curl]"
curl --silent -X POST -d "uri=${iuri}" "$post_url"

if [ $? = 0 ] ; then
    echo "For debugging purposes, supressing removal of tmp/doc-openannotation--with-otherContent--pid$pid.json"
    /bin/rm tmp/doc-openannotation--with-otherContent--pid$pid.json
fi

echo ""

# When the IIIFManifest file is ingested, the returned JSON includes the 'short_id' for the
# submitted file.  This is a value that a built Greenstone collection needs to know to
# use Mirador's search within-the-document, but produced at this stage is too late
# to be incorporated. The solution to this has been to look into how SAS calculates
# this short_id value, and encode the same calculation into the GoogleVisionAPI plugin
# so the same value can be computed there (when it is generating OpenAnnotations, and
# storing them as associated files), with the computed value set as the metadata field
# SASShortID


# In more detail ...
#
# To search within specific IIIFManafest, the SAS Search endpoint makes use of a field
# called 'short_id'.  This turns out to be an MD5 hash of the URL, and is done so the
# Restful URL to query the document specifies the

# For example the Doc ID:
#    http://ld.greenstone.org/intermuse/demo-localhost/HMS_1/canvas/1
#
# gets hashed to 212807d9741cd2497368dee6c16f2882
#
# and so is then searched through SAS as:
#
# http://localhost:8383/simpleAnnotationStore/search-api/212807d9741cd2497368dee6c16f2882/search?q=SOUL


# So Greenstone3's XSL presentation layer can correctly construct the URL to search within
# the Mirador viewer using the SAS search endpoint, it need to set this short_id as a piece
# of metadata (SASShortID).
#
# This is done in the GoogleVisionAPI Plugin, 'replicating' (computing up-stream, really)
# the MD5 hash calculation that SAS also does at this point, when the IIIFManifest is ingested