The Mirador Annotations plugin allows users to create and edit annotations on images and other media. The RERUM Adapter for Mirador extends this functionality by providing a way to save these annotations to the RERUM annotation service. Depending on your project, the Adapter can be adjusted to specific needs.

Sandbox

By default, loading the Adapter as configured connects to the RERUM sandbox service. This is a public service that does not promise data integrity or persistence but is reliable over short periods for experimentation. This is very useful for testing and development and available without any setup or additional resources.

TinyThings

The Adapter uses the tinydev.rerum.io sandbox, but there is also available a tiny.rerum.io service that instead connects to the production server. This small change to the endpointUrl in the code will allow you to save annotations in a more permanent location. This can be done directly in the constructor:

constructor(canvasId, 'https://tiny.rerum.io', 'https://store.rerum.io/v1/id/agent')

As you can see, the change can also be made by simply using the TinyThings URL in the annotation configuration. This short code block shows how to set up the Adapter with the TinyThings service:

const config = {
  annotation: {
    adapter: (canvasId) => new RerumAdapter(canvasId,'https://tiny.rerum.io', 'https://store.rerum.io/v1/id/agent'),
    exportLocalStorageAnnotations: false, // display annotation JSON export button
  },
  id: 'demo',
  window: {
    defaultSideBarPanel: 'annotations',
    sideBarOpenByDefault: true,
  },
  windows: [{
    loadedManifest: 'https://iiif.harvardartmuseums.org/manifests/object/299843',
  }],
};

Similar to the sandbox, the TinyThings service is available without any setup or additional resources. However, there are a few caveats to be aware of.

1. TinyThings is production data and Linked Open Data. Polluting it with test data or bad data is poor web citizenship.
2. The metadata for the annotations is controlled by the TinyThings service, so your project will not have any reserved control or explicit authentication.
3. The result of this solution is expected to be transitional and is probably not suitable for long-term projects.

MyThings

TinyThings is designed to be forked. The GitHub repository can be cloned and run with your own API key (register here) so that your project owns the data. To implement your solution, simply replace the endpointUrl in the Adapter constructor with your own URL as in the TinyThings example above. In fact, it is possible to spin up your own instance of the RERUM service as well and still use the Adapter with the same configuration without exposing any of your data in an uncontrolled space.

Notes on the Adapter

There is an outstanding issue that will add a lot of flexibility to the Adapter. The Bearer token passthrough will allow for the use of the API key with TinyThings. The provided Authorization header will replace the default header that identifies the TinyThings service and so connects the production data to your project. This introduces a lot of concerns about security of tokens, but simplifies the resources needed, if solvable.

The creator field is added to all annotations as a common field within RERUM and other Web Annotations, but has a default value set. For any of the above solutions, you can set the creator field to a value that identifies your project or user. Because this is set on initialization, it cannot support multiple users or projects in the same instance.

The original t-pen.org platform will persist, but upon launch the thousands of projects currently hosted will be given an upgrade path. The new platform will use the public RERUM service (rerum.io) to store all public transcription data as truly Linked Open Usable Data and provide many more interfaces for coordinating teams, building projects, and annotating pages.

There will be much more information to come. For now, I want to express my sincere gratitude to the TPEN alumni who contributed so much to the code, case testing, and marketing. I reassure the many partners that have integrated TPEN into their own projects and workflows that nothing is breaking and this move forward is designed to lift all ships. I hope to plant an eagerness in the thousands of users who have captured human knowledge and culture on the platform over the last decade as we integrate all their feedback and imaginings. Finally, I acknowledge that this funding award, from the taxpayers of the United States, has accelerated our move to 3.0 significantly. While Saint Louis University would never let such an impactful and beloved platform expire early as so many digital projects tend to do, shifting out of maintenance mode and spying new horizons is exhilarating.

Dynamic-CollectionsDownload

• Rerum
• Glossing Matthew
• Lived Religion in a Digital Age
• Fiantinator
• Slavery, History, Memory and Reconciliation
• Geolocator

presented at the IIIF 2021 conference

Resources

IIIF-Aware-EcosystemDownload

• Context Files
  • IIF Presentation 3
  • Lived Religion Custom example
• Rerum
  • Tiny Things
  • RERUM store
  • RERUM API
• Data Entry and Exhibition for Rerum
• TPEN
  • Sandbox TPEN
  • Ong Route Book
  • Jeff Goldblum Manuscript
  • Presentation Sample
• Newberry Paleography
  • French
  • Italian
  • Scroll Sample
• Glossing Matthew
• Rerum Manifest Reader
  • Presentation Sample
  • Ong Route Book
• Rerum Aybee Tool
  • Presentation Sample
  • Ong Route Book
• Concordance Tool
  • Wellcome Printed Book
  • Jeff Goldblum TPEN Manifest
• Geolocator
• Dunbar Library & Archive
  • Music Archive
  • Dialect Glossary
  • Dunbar Letters Transcription Portal
• Lived Religion in a Digital Age
  • Public Experiences
  • Data Entry Portal
  • Mapping Interface

Implementation Description

Below you will see an empty Manifest geolocated via a geographic polygon. There is an Annotation Page containing a single Annotation with coordinates to central Paris, France contained in the Manifest. The body of that Annotation is GeoJSON-LD.

Example JSON

{
   "@context":[
      "http://geojson.org/geojson-ld/geojson-context.jsonld",
      "http://iiif.io/api/presentation/3/context.json"
   ],
   "id":"http://www.example.org/manifest/3",
   "type":"Manifest",
   "label":{
      "en":[
         "Manifest - Example III"
      ]
   },
   "summary":{
      "en":[
         "Example Manifest geolocated to Göttingen, Germany via Annotation."
      ]
   },
   "items":[
      
   ],
   "annotations":[
      {
         "id":"http://www.example.org/annotation_page/1",
         "type":"AnnotationPage",
         "items":[
            {
               "id":"http://www.example.org/annotation/1",
               "type":"Annotation",
               "motivation":"supplementing",
               "label":{
                  "en":[
                     "The coordinates for the main building of the event (Alte Mensa Conference Center)."
                  ]
               },
               "body":{
                  "type":"Feature",
                  "properties":{
                     "label":"Göttingen, Germany"
                  },
                  "geometry":{
                     "type":"Polygon",
                     "coordinates":[
                        [
                           [
                              9.80943,
                              51.570156
                           ],
                           [
                              9.850628,
                              51.579117
                           ],
                           [
                              10.030529,
                              51.590637
                           ],
                           [
                              10.056962,
                              51.532347
                           ],
                           [
                              9.948829,
                              51.481692
                           ],
                           [
                              9.905576,
                              51.513933
                           ],
                           [
                              9.804273,
                              51.524557
                           ]
                        ]
                     ]
                  }
               },
               "target":"http://www.example.org/manifest/3"
            }
         ]
      }
   ]
}

Important Implementation Notes

• To support interoperability through Linked Data, the IIIF Presentation API 3.0 and GeoJSON-LD 1.0 context are included at the top of the document.
• An unintended yet beneficial consequence of this paring is that these contexts are processed as JSON-LD 1.1. This is because the IIIF Presentation API 3 context contains the @version tag set to 1.1 which tells JSON-LD processors what version to use for processing the JSON.
• IIIF Presentation API 3.0 dictates that resource types be annotated by Annotation Pages as opposed to single Annotations, even in cases where this is only one Annotation.
• A single GeoJSON Feature was used to assert the coordinates. Since an Annotation Page can have an array of items, multiple Features can be supported all at once. GeoJSON also has Feature Collection, which can contain an array of Features. In this way, it is possible to represent multiple Features under a single Feature Collection object. Our experience with user interfaces that consume GeoJSON is that they will draw a single Feature Collection of points the same way as an array of multiple Feature objects. Since user interfaces support either, without preference, we chose to represent the single Feature as simply as possible without wrapping it inside a Feature Collection object.
• You can see more description about using this syntax in the recipe from the IIIF Cookbook, including a link to a working example using the recipe.

Restrictive Outcomes

After creating this example and studying how processors interpret it, and furthering this example through slight variations, we noticed critical points of incompatibility.

1. The properties field of GeoJSON-LD is not well described and has been left to act as a wild card. It can contain nearly anything and is therefore subject to repeat described terms from other contexts, such as label.
2. During this phase of research, we learned that the GeoJSON-LD specification and context are receiving limited attention. It is difficult to make suggestions or implement improvements (like making the context JSON-LD 1.1 on its own).

Conclusion

The IIIF Cookbook Community Group, in coordination with the IIIF Maps Community Group, considers GeoJSON-LD compatible with IIIF Presentation API 3.0. Linked Data processors are able to expand and compact the GeoJSON-LD data syntax in these Annotations. It is troubling that the GeoJSON-LD specification and context are abandoned. However, IIIF supports extensions within its scope, and the IIIF Maps Community Group is working with the GeoJSON Web Group to bring the specification into an environment where it will be improved upon and maintained.

Next Step

The main goal is to ensure we can make all the basic kinds of assertions through IIIF resource types. We know we can geolocate an entire resource to a Polygonal coordinate area. The other basic assertion is to geolocate some fragment of a resource contained within a Manifest.

Implementation Description

Below you will see an empty Manifest. There is a GeoJSON service attached to the Manifest with the coordinates to central Paris, France. The service contains a GeoJSON-LD object within the service object structure.

Example JSON

{
   "@context":[
      "http://iiif.io/api/presentation/2/context.json",
      "http://geojson.org/geojson-ld/geojson-context.jsonld"
   ],
   "@id":"http://www.example.org/example2/manifest",
   "@type":"sc:Manifest",
   "label":"Manifest - Example II", 
   "description":"An Empty Manifest that is geolocated to Paris, France via an IIIF Presentation API 2.1 service.",
   "sequences":[],
   "service":{
      "@id":"https://www.example.org/geo/service/point-coordinates(2.34,48.86)&format=geojson",
      "profile":"http://geojson.org/geojson-spec.html",
      "type":"FeatureCollection",
      "features":[
         {
            "@type":"Feature",
            "properties":{
               "label":"Paris, France"
            },
            "geometry":{
               "type":"Point",
               "coordinates":[
                  2.34,
                  48.86
               ]
            }
         }
      ]
   }
}

Important Implementation Notes

• To support interoperability through Linked Data, the IIIF Presentation API 2.1 and GeoJSON-LD 1.0 context are included at the top of the document.
• The IIIF Presentation API 2.1 and GeoJSON-LD 1.0 context are JSON-LD 1.0.
• The assertion is directly on the Manifest.
• A GeoJSON Feature Collection was used to represent the single Feature object. Since service must be an object, it is best to control expectations and always return a Feature Collection, since it would require a Feature Collection to represent an array of Feature objects.

Restrictive Outcomes

After creating this example and studying how processors interpret it, and furthering this example through slight variations, we noticed critical points of incompatibility.

1. The context of GeoJSON-LD is not compatible with with JSON-LD 1.0. JSON-LD 1.0 processing cannot realize arrays of arrays, meaning geometry for Polygons cannot be supported.
2. The properties field of GeoJSON-LD is not well described and has been left to act as a wild card. It can contain nearly anything and is therefore subject to repeat described terms from other contexts, such as label. Linked Data separates the meanings of duplicate keys to their direct definitions.
3. service is a JSON object. This means it is not possible to represent multiple Features as a simple Array. To do this, a single Feature Collection JSON object containing the array of Features must be used.
4. Manifests and Services do not have motivation. Motivation is important for determining the functionality and outcome expected of the syntax used.

Conclusion

The IIIF Cookbook Community Group, in coordination with the IIIF Maps Community Group, deemed that GeoJSON-LD was not compatible with IIIF Presentation API 2.1 services. Linked Data processors will not be able to understand or realize the GeoJSON-LD data syntax used are likely to ignore that which they cannot process. It is not realistic to expect that existing services will change to only return Feature Collections, and we do not want to restrict what GeoJSON resource types can be used in future development.

Next Step

With the release of IIIF Presentation API 3.0 looming, we would like to investigate if the improved API could support geographic assertions.

Implementation Description

Below you will see an empty Manifest geolocated via a geographic polygon. There is an Annotation Page containing a single Annotation with coordinates to central Paris, France contained in the Manifest. The body of that Annotation is GeoJSON-LD.

Example JSON

{
   "@context":[
      "http://geojson.org/geojson-ld/geojson-context.jsonld",
      "http://iiif.io/api/presentation/3/context.json"
   ],
   "id":"http://www.example.org/manifest/3",
   "type":"Manifest",
   "label":{
      "en":[
         "Manifest - Example III"
      ]
   },
   "summary":{
      "en":[
         "Example Manifest geolocated to Göttingen, Germany via Annotation."
      ]
   },
   "items":[
      
   ],
   "annotations":[
      {
         "id":"http://www.example.org/annotation_page/1",
         "type":"AnnotationPage",
         "items":[
            {
               "id":"http://www.example.org/annotation/1",
               "type":"Annotation",
               "motivation":"supplementing",
               "label":{
                  "en":[
                     "The coordinates for the main building of the event (Alte Mensa Conference Center)."
                  ]
               },
               "body":{
                  "type":"Feature",
                  "properties":{
                     "label":"Göttingen, Germany"
                  },
                  "geometry":{
                     "type":"Polygon",
                     "coordinates":[
                        [
                           [
                              9.80943,
                              51.570156
                           ],
                           [
                              9.850628,
                              51.579117
                           ],
                           [
                              10.030529,
                              51.590637
                           ],
                           [
                              10.056962,
                              51.532347
                           ],
                           [
                              9.948829,
                              51.481692
                           ],
                           [
                              9.905576,
                              51.513933
                           ],
                           [
                              9.804273,
                              51.524557
                           ]
                        ]
                     ]
                  }
               },
               "target":"http://www.example.org/manifest/3"
            }
         ]
      }
   ]
}

Important Implementation Notes

• To support interoperability through Linked Data, the IIIF Presentation API 3.0 and GeoJSON-LD 1.0 context are included at the top of the document.
• An unintended yet beneficial consequence of this paring is that these contexts are processed as JSON-LD 1.1. This is because the IIIF Presentation API 3 context contains the @version tag set to 1.1 which tells JSON-LD processors what version to use for processing the JSON.
• IIIF Presentation API 3.0 dictates that resource types be annotated by Annotation Pages as opposed to single Annotations, even in cases where this is only one Annotation.
• A single GeoJSON Feature was used to assert the coordinates. Since an Annotation Page can have an array of items, multiple Features can be supported all at once. GeoJSON also has Feature Collection, which can contain an array of Features. In this way, it is possible to represent multiple Features under a single Feature Collection object. Our experience with user interfaces that consume GeoJSON is that they will draw a single Feature Collection of points the same way as an array of multiple Feature objects. Since user interfaces support either, without preference, we chose to represent the single Feature as simply as possible without wrapping it inside a Feature Collection object.
• You can see more description about using this syntax in the recipe from the IIIF Cookbook, including a link to a working example using the recipe.

Restrictive Outcomes

After creating this example and studying how processors interpret it, and furthering this example through slight variations, we noticed critical points of incompatibility.

1. The properties field of GeoJSON-LD is not well described and has been left to act as a wild card. It can contain nearly anything and is therefore subject to repeat described terms from other contexts, such as label.
2. During this phase of research, we learned that the GeoJSON-LD specification and context are receiving limited attention. It is difficult to make suggestions or implement improvements (like making the context JSON-LD 1.1 on its own).

Conclusion

The IIIF Cookbook Community Group, in coordination with the IIIF Maps Community Group, considers GeoJSON-LD compatible with IIIF Presentation API 3.0. Linked Data processors are able to expand and compact the GeoJSON-LD data syntax in these Annotations. It is troubling that the GeoJSON-LD specification and context are abandoned. However, IIIF supports extensions within its scope, and the IIIF Maps Community Group is working with the GeoJSON Web Group to bring the specification into an environment where it will be improved upon and maintained.

Next Step

The main goal is to ensure we can make all the basic kinds of assertions through IIIF resource types. We know we can geolocate an entire resource to a Polygonal coordinate area. The other basic assertion is to geolocate some fragment of a resource contained within a Manifest.

Implementation Description

Below you will see an IIIF Presentation 3.0 Manifest that contains a single Canvas with an IIIF Image API 3 compliant image painted onto it. The word “Paris” appears on the image and the region containing the word is targeted by two Annotations. One Annotation supplements the fragment with the text “Paris”. The other Annotation supplies coordinates to a central point in Paris, France.

Example JSON

{
  "@context": [
    "http://geojson.org/geojson-ld/geojson-context.jsonld",
    "http://iiif.io/api/presentation/3/context.json"
  ],
  "id": "http://www.example.org/manifest/4",
  "type": "Manifest",
  "label": {
    "en": [
      "Manifest - Example IV"
    ]
  },
  "summary": {
    "en": [
      "A Manifest containing GeoJSON-LD Web Annotations to target the word \\"Paris\\" on the provided resource in order to transcribe it and geolocate it to Paris, France."
    ]
  },
  "items": [
    {
      "id": "http://www.example.org/canvas/1",
      "type": "Canvas",
      "label": {
        "fr": [
          "Page de Couverture du Le Scarabée D'or"
        ]
      },
      "width": 3204,
      "height": 4613,
      "items": [
        {
          "id": "http://www.example.org/content_page/1",
          "type": "AnnotationPage",
          "items": [
            {
              "id": "https://preview.iiif.io/cookbook/0139-geo-annotation/recipe/0139-geolocate-canvas-fragment/content.json",
              "type": "Annotation",
              "motivation": "painting",
              "label": {
                "en": [
                  "The cover page."
                ]
              },
              "body": {
                "id": "https://iiif.io/api/image/3.0/example/reference/59d09e6773341f28ea166e9f3c1e674f-gallica_ark_12148_bpt6k1526005v_f20/full/max/0/default.jpg",
                "type": "Image",
                "format": "image/jpeg",
                "service": [
                  {
                    "id": "https://iiif.io/api/image/3.0/example/reference/59d09e6773341f28ea166e9f3c1e674f-gallica_ark_12148_bpt6k1526005v_f20",
                    "type": "ImageService3",
                    "profile": "level1"
                  }
                ],
                "width": 3204,
                "height": 4613
              },
              "target": "http://www.example.org/canvas/1"
            }
          ]
        }
      ],
      "annotations": [
        {
          "id": "http://www.example.org/annotation_page/1",
          "type": "AnnotationPage",
          "items": [
            {
              "id": "http://www.example.org/annotation/1",
              "type": "Annotation",
              "motivation": "supplementing",
              "label": {
                "en": [
                  "Transcription Text"
                ]
              },
              "body": {
                "type": "TextualBody",
                "value": "Paris",
                "format": "text/plain",
                "language": "en"
              },
              "target": "http://www.example.org/canvas/1#xywh=1300,3370,250,100"
            },
            {
              "id": "http://www.example.org/annotation/2",
              "type": "Annotation",
              "motivation": "supplementing",
              "label": {
                "en": [
                  "Coordinate Data"
                ]
              },
              "body": {
                "type": "Feature",
                "properties": {
                  "label": {
                    "en": [
                      "Paris, France"
                    ]
                  }
                },
                "geometry": {
                  "type": "Point",
                  "coordinates": [2.34, 48.86]
                }
              },
              "target": "http://www.example.org/canvas/1#xywh=1300,3370,250,100"
            }
          ]
        }
      ]
    }
  ]
}

Important Implementation Notes

• To support interoperability through Linked Data, the IIIF Presentation API 3.0 and GeoJSON-LD 1.0 context are included at the top of the document.
• An unintended yet beneficial consequence of this paring is that these contexts are processed as JSON-LD 1.1. This is because the IIIF Presentation API 3 context contains the @version tag set to 1.1 which tells JSON-LD processors what version to use for processing the JSON.
• IIIF Presentation API 3.0 dictates that resource types be annotated by Annotation Pages as opposed to single Annotations, even in cases where this is only one Annotation.
• A single GeoJSON Feature was used to assert the coordinates. Since an Annotation Page can have an array of items, multiple Features can be supported all at once. GeoJSON also has Feature Collection, which can contain an array of Features. In this way, it is possible to represent multiple Features under a single Feature Collection object. Our experience with user interfaces that consume GeoJSON is that they will draw a single Feature Collection of points the same way as an array of multiple Feature objects. Since user interfaces support either, without preference, we chose to represent the single Feature as simply as possible without wrapping it inside a Feature Collection object.
• See the fragment of the image targeted by the Annotations! This is thanks to the magic of IIIF Image API 3!
• You can see more description about using this syntax in the recipe from the IIIF Cookbook, including a link to a working example using the recipe.

Restrictive Outcomes

After creating this example and studying how processors interpret it, and furthering this example through slight variations, we noticed critical points of incompatibility.

1. The properties field of GeoJSON-LD is not well described and has been left to act as a wild card. It can contain nearly anything and is therefore subject to repeat described terms from other contexts, such as label.
2. During this phase of research, we learned that the GeoJSON-LD specification and context are receiving limited attention. It is difficult to make suggestions or implement improvements (like making the context JSON-LD 1.1 on its own).

Conclusion

The IIIF Cookbook Community Group, in coordination with the IIIF Maps Community Group, considers GeoJSON-LD compatible with IIIF Presentation API 3.0. Linked Data processors are able to expand and compact the GeoJSON-LD data syntax in these Annotations.

Next Step

IIIF Presentation API 3.0 also has services. We need to investigate whether or not these services can support GeoJSON-LD.

Implementation Description

Below you will see an empty Manifest geolocated via a GeoJSON service. The body of that service is a GeoJSON-LD Point.

Example JSON

{
    "@context":[
       "http://geojson.org/geojson-ld/geojson-context.jsonld",
       "http://iiif.io/api/presentation/3/context.json"
    ],
    "id":"http://www.example.org/manifest/3",
    "type":"Manifest",
    "label":{
       "en":[
          "Example IIIF Presentation API 3.0 Manifest III"
       ]
    },
    "summary":{
       "en":[
          "Example Manifest geolocated to Paris, France via a IIIF Presentation API 3 Service."
       ]
    },
    "items":[],
    "service":[
        {
            "@id":"https://example.org/geo/service/point-coordinates(48.86,2.34)&format=geojson",
            "profile":"http://geojson.org/geojson-spec.html",
            "type":["Feature", "GeoJSON_Service"],
            "properties":{
                "label":"Paris, France"
            },
            "geometry":{
                "type":"Point",
                "coordinates":[
                    2.34,
                    48.86
                ]
            }
        }
    ]
}

Important Implementation Notes

• To support interoperability through Linked Data, the IIIF Presentation API 3.0 and GeoJSON-LD 1.0 context are included at the top of the document.
• An unintended yet beneficial consequence of this paring is that these contexts are JSON-LD 1.1. This is because the IIIF Presentation API 3 context contains the @version tag set to 1.1 which tells JSON-LD processors what version to use for processing the JSON.
• A single GeoJSON Feature was used to assert the coordinates. Since service can be an array of service objects, multiple Features can be supported all at once. GeoJSON also has Feature Collection, which can contain an array of Features. In this way, it is possible to represent multiple Features under a single Feature Collection object. Our experience with user interfaces that consume GeoJSON is that they will draw a single Feature Collection of points the same way as an array of multiple Feature objects. Since user interfaces support either, without preference, we chose to represent the single Feature as simply as possible without wrapping it inside a Feature Collection object.
• IIIF Presentation API 3.0 dictates that services must have a type.

Restrictive Outcomes

After creating this example and studying how processors interpret it, and furthering this example through slight variations, we noticed critical points of incompatibility.

1. It is difficult to represent the “type” clash of GeoJSON-LD and IIIF Presentation API 3.0. Each type comes from a different context, and most processors expect that type is a string, not an array. It is likely that processors would not be able to process type, which would cause them to ignore this service JSON.
2. Manifests and Services do not have motivation. Motivation is important for determining the functionality and outcome expected of the syntax used.

Conclusion

The IIIF Cookbook Community Group, in coordination with the IIIF Maps Community Group, considers GeoJSON-LD incompatible with IIIF Presentation API 3.0 services. Linked Data processors will have trouble process service types in cases where they clash with other Linked Data type requirements, and are likely to ignore that which they cannot process.

Next Step

Continue to push for standards in the geospatial communities by improving the specifications they rely on. There are other methods being used to transmit and render coordinate data over the Web and other systems. Though some may be specialized enough to require their own syntax, interoperability can only be improved through standardization of these geospatial data practices.

The evolution of technology and the maturing of data in the Internet of Things exacerbated this natural need for spatiotemporal description to properly chronicle the story of humanity. Analytics on spatiotemporal data can produce new understanding from old knowledge and give predictions of what will happen tomorrow. It gives insight to the how and why of a history of interaction and behavior, and the change those wrought, for better or worse.

Data scientists in the humanities and beyond realize the common need for spatiotemporal dimensions. Global consortia are forming to develop standardized, uniform ways of making responsible and interoperable spatiotemporal assertions and connections. As much as it is for the data and for science, it is for the human. User interfaces are crafted to take in this standardized format so that data can move between pointed, analytical, and human-readable visualizations connecting humans, time, and space. Here are one thousand examples of such ventures: https://gisgeography.com/gis-applications-uses/.

What started the Walter J. Ong, S.J., Center for Digital Humanities at Saint Louis University’s (OCDH) specific involvement in standardized geospatial assertions is Lived Religion in the Digital Age. This project attempts to describe the amorphous effects religion has on a region, and vice-versa. One data capture method is accepting a testimonial from a human describing religion, or lack of religion, during an experience or event. “I was at a place at this time, witnessed interactions with people and/or objects and have this conclusion about how religion shaped or was shaped by what was witnessed.” A data challenge to describe People, Places, Things, Events and their abundant, abstract, loose connections. Once the work began and data structures were in place, a question still loomed: how do I reliably assert known Earth coordinates onto Person, Place, Thing or Event data?

If you are a human interested in better understanding humans as it pertains to time and space, then you may be interested in the role OCDH is playing. We plan to release a series of blogs that will demonstrate our entanglement in geospatial data science. It will expose our experience with the geospatial data standards we have encountered and are attempting to enhance. There are avenues that intersect geospatial assertions and interoperable linked open usable data. We would like to give you the coordinates.