Changeset 38294 for gs3-installations/intermuse/trunk/sites/intermuse/collect/demo-localhost/INDEX-IIIF-MANIFEST.sh

Timestamp:

2023-10-06T18:07:52+13:00 (8 months ago)

Author:

davidb

Message:

Tighten up full-build script sequence

File:

• gs3-installations/intermuse/trunk/sites/intermuse/collect/demo-localhost/INDEX-IIIF-MANIFEST.sh (modified) (3 diffs)

gs3-installations/intermuse/trunk/sites/intermuse/collect/demo-localhost/INDEX-IIIF-MANIFEST.sh

@@ -48 +48 @@
 iuri="$gs_library_url/sites/$site/collect/$col/tmp/doc-openannotation--with-otherContent--pid$pid.json"
 
-#internal_url_base="http://localhost:4343/simpleAnnotationStore"
 internal_url_base="http://localhost:$gs_http_port/simpleAnnotationStore"
 
@@ -60 +59 @@
 
 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
@@ -65 +65 @@
 echo ""
 
-# The above curl POST returns JSON output of the form:
-#   {"loaded":{"short_id":"f3bac06f17c9240b76b082dbdcbb365a","uri":"http://ld.greenstone.org/intermuse/programmes/HASH012cd965c3e83d504f4a78cd/manifest"}}
+# 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
 
-# It might be the short_id is need for a later step in Greenstone, a comment to this affect was left in this script:
+
+# In more detail ...
 #
-#    The short_id is needed to ... 
+# 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
 #
-# However no other detail given, and at present the features that are needed in Mirador appear to work OK
+# gets hashed to 212807d9741cd2497368dee6c16f2882
 #
-# Legacy comment written during a development phase that is no longer relevant/required??
+# and so is then searched through SAS as:
+#
+# http://localhost:8383/simpleAnnotationStore/search-api/212807d9741cd2497368dee6c16f2882/search?q=SOUL
 
-# {"loaded":{"short_id":"e2465cd7e5174f2720cee110d9b4a06a","uri":"http://ld.greenstone.org/intermuse/programmes-and-performers/HASH012cd965c3e83d504f4a78cd/manifest"}}+ echo ''
+
+# 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
+