This publication proposes the extension of the W3C Web Annotation Data Model with a set of geospatial selector types. This definition allows for the interoperability of geospatial annotations in linked open data repositories and, at the same time, proposes an equivalent structure of a vector layer, which is losslessly convertible into its equivalent JSON-LD representation. A proof of concept implementation as a QGIS plugin shows the applicability of the idea in a practical setting. Finally, possible common application cases and issues of standardization of the extension are discussed.
CEUR ceur-ws.org Annotation
Annotations are becoming an increasingly common method of participating in the scientific
discourse. Especially since the W3C Web Annotation Data Model [
A more common practice in the GIS community is to directly add data about a geospatial
feature to the database in which this geospatial feature is stored. For example, suppose a piece of
information about a building is missing in OpenStreetMap [
While one could designate the aforementioned addition of data to a knowledge base as an annotation by people, these are not the kind of annotations discussed in this publication. https://situx.github.io/ (T. Homburg) CEUR Workshop Proceedings Annotations in the context of this publication serve a diferent purpose. They may contradict each other as they represent statements of knowledge of those who created the respective annotation, and annotations may include arbitrary information, which may not be suitable for the GIS database in which the geospatial data is stored. Hence, they would commonly be stored in a diferent database referring to map content by identifiers.
In a guide of providing data to OpenStreetMap2 it is stated that data should be factual,
longterm, and observable, which obviously excludes a variety of useful, but subjective data such as
opinions about certain places, perceptions of any kind e.g. of safety [
This section introduces the foundations of annotations in the GIS community and other research communities.
Annotations in the GIS community typically involve creating new map layers, which are saved
alongside another GIS layer to be annotated. Annotations in this way are not necessarily linked
using a unique identifier, as is the case in other annotation models. Instead, annotations are often
related by their geocoordinates, i.e., an annotation that concerns a particular geospatial feature
in a diferent layer expects this geospatial feature to be at the same geocoordinates. This is not
a problem, as annotation layers in GIS are usually stored alongside the data they annotate and
are not always intended to be used outside of this context. For example, a cartographer might
want to comment on a particular aspect of a given geospatial feature to a colleague and, for
this purpose, might create a new layer with comments or even corrections of certain aspects of
geospatial data. The newly created annotation map layer might then be shared with the person
responsible for curating the geospatial data and be used for data correction. Hence, annotations
in GIS Science have historically been a means of communication between cartographers but have
not necessarily been the subject of a more comprehensive publication. Suppose an annotation
layer is to be made public. In that case, it needs to be stored in a geospatial web service and be
possibly referenced by a catalog service for the web (CSW), [
The W3C Web Annotation Data Model is an RDF [7] vocabulary that defines annotations on data sources available on the web. An annotation is defined by an ID (typically a URI [ 8]), an annotation body containing the contents of the given annotation, and an annotation target that describes the element that is described by the annotation. The model has been defined to work on image, web, and semantic web resources and utilizes diferent selector types to narrow down parts of web resources and the areas of images that are relevant for annotations. Listing 1: Example of an annotated image using the W3C Web Annotation Data Model using a
SVG selector to describe an annotation area 1 { 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 } ”@context”: ”http://www.w3.org/ns/anno.jsonld”, ”id”: ”http://example.org/anno27”, ”type”: ”Annotation”, ”body”: { ”type”: ”TextualBody”, ”value”: ”This is the best part of my image” }, ”target”: { ”source”: ”http://example.org/myimage”, ”selector”: { ”type”: ”SvgSelector”, ”value”: ”<svg:svg> ... </svg:svg>” }
} Listing 1 shows an example of an image annotation in which an area of an image, defined by an SVG [9] description is classified as the images’ favorite part by the annotating user.
The following presents related work on how annotations on map data have been used and previously saved in the GIS community.
There are vocabularies for describing observations instead of annotations that should be considered in this publication. The Semantic Sensor Network Ontology (SSO) [10] is an ontology model that captures sensor inputs from environmental sensors and saves them in an ontology model. It is essential to distinguish that, while one may consider an observation as an annotation made by a machine, the definition of observation in the SSO ontology
Act of carrying out an (Observation) Procedure to estimate or calculate the value of a property of a FeatureOfInterest shows that an observation in the sense of the SSO model is inherently measurable by a sensor and thus does not constitute the main content of an annotation discussed in this publication. Another definition of an observation can be found in the CIDOC CRM extension CRMsci [ 11]. This model defines an observation as
The activity of gaining scientific knowledge about particular states of physical reality through empirical evidence, experiments, and measurements.
This definition also includes human observations, which may be regarded as interpretations of a specific feature’s specific aspect. Web annotations, on the other hand, may be subjective, are not necessarily backed up by facts, are not necessarily observable, and therefore constitute a more general means of adding data to a piece of information.
The W3C Web Data Annotation Model has been used to annotate georeferenced images of maps to bind image coordinates in SVG [12] to a GeoJSON [13] representation which has been saved in the annotation body of the web annotation. This practice has been implemented by the service allmaps3. Annotorious4, a JavaScript library for image annotation has been used to annotate areas on map images and to subsequently save the results as GeoJSON annotation layers. To achieve this, [14] explored the possibility of collaborative map annotation in the context of historical GIS applications. In historical GIS, maps are often represented using images, i.e., raster data, which need to be manually georeferenced to be useful. This style of annotation creates a geometry representation e.g., GeoJSON in the annotation body, but does not allow a geospatial feature itself as the target of the annotation. This publication, therefore, deviates in a way that it should enable geospatial targets of the web annotation data model. 4. GeoWebAnnotations - A model to annotate geodata This section proposes how the W3C Web Annotation Data Model can be extended to represent geocoordinates and the prerequisites that need to be taken for this step. For the extension of the web annotation data model, the following cases need to be considered:
4https://recogito.github.io/annotorious/ 1. The geometry that is about to be annotated is available by a distinct URI 2. The geometry that is about to be annotated is not available with a distinct URI 3. Only a geometry collection is available with a distinct URI Of the aforementioned cases, the first case is the one which, according to the author’s estimation, is the most likely case to be available in the future. This case corresponds to the Best Practices of exposing Spatial data on the web [15], which mandates that every geospatial feature shall be made available and accessible using a unique URI. This is contrary to previous practices in the GIS world. Previously, in geospatial web services, only collections of features would be shared using an accessible web resource. Currently, the OGC defines the OGC API Features family of standards5 which mandates that each geospatial feature should be accessible with at least one URL. This would qualify features that are accessible over geospatial web services to be chosen as annotation targets in the W3C Web Annotation Data Model. Clearly, another perspective for geospatial data to be shared is if it is encoded in a linked data vocabulary such as GeoSPARQL [16]. In this case, we can expect the feature and the geometry to each be equipped with a URI by default.
To define a web annotation for geospatial objects, the W3C Web Annotation Data Model needs to be extended by defining a new annotation target selector type, a G e o S e l e c t o r and possibly diferent subtypes of the GeoSelector for diferent serializations, e.g., a W k t S e l e c t o r for Well-Known Text serializations. Listing 2 shows an example of the proposed new selector type. Listing 2: Web annotation data model extended to represent georeference annotations:
Variant 1: GeoSelector with absolute coordinates Following the W3C Web Annotation Data Model, the annotation target contains a source, which for geospatial features would correspond to a URL under which the resource is available (e.g., an OGC API Features URL or a URI in the semantic web). If the URL already refers to a geospatial feature or a feature collection should be annotated, then stating the source in this way is suficient. However, if the URL refers e.g., to a web feature service that is not able to expose single geospatial features by URL, then the optional attribute targetFeature may be stated in the selector body to make the choice of a single feature explicit.
Then, the GeoSelector includes or points to the definition of a coordinate reference system (CRS). This coordinate reference system is the CRS the annotation is defined in and does not necessarily have to match the coordinate reference system of the target feature. For example: A geospatial feature in the EPSG:258336 coordinate reference system might be exposed by a geospatial authority. Then, the annotation coordinate system could deviate from EPSG:25833, e.g., be defined in the CRS84 world coordinate system 7. The CRS definition might be analogous to definitions in the GeoSPARQL vocabulary [ 17] be given by an OGC-conform URI, by an EPSG code (an xsd:string), or by a WKT coordinate reference system defined as a String literal for non-standard coordinate reference system definitions. The value of the GeoSelector defines the area of the annotation target, which is to be annotated. This definition is in Listing 2 given by the definition of a geo:wktLiteral as defined in the GeoSPARQL vocabulary [ 18].
Another possibility for defining a geospatial annotation is the relative annotation (cf. Listing 3). This definition does not require the definition of a coordinate reference system in the annotation target. Instead, it defines coordinates relative to the feature it is annotating. For example, Suppose a polygon representing the building footprint of a fire station is to be annotated. The polygon describes a rectangular building with a width of 20m and a height of 20m, respectively. In that case, the annotation, as a WKT literal, might define a subarea of this building polygon. Listing 3: Web annotation data model extended to represent georeference annotations:
Variant 2: GeoSelector with relative coordinates 1 { 2 3 4 5 6 7 8 9 10 11 12 13 14 } }
} ”@context”: ”http://www.w3.org/ns/anno.jsonld”, ”id”: ”http://example.org/anno27”, ”type”: ”Annotation”, ”body”: ”http://example.org/road1”, ”target”: { ”source”: ”http://example.org/myfeature”, ”selector”: { ”type”: ”WktSelector”, ”targetFeature”: ””, ”value”: ”WKTLITERAL” 6https://epsg.io/25833 7https://epsg.io/4326 While a relative annotation may be optional for already georeferenced vector data, it can be very interesting for non-georeferenced geospatial data, particularly grid-like data such as rasters, which might be georeferenced at a later stage.
Listing 4: Web annotation data model extended to represent georeference annotations: Variant 2: GeoSelector with relative coordinates ”@context”: ”http://www.w3.org/ns/anno.jsonld”, ”id”: ”http://example.org/anno27”, ”type”: ”Annotation”, ”body”: ”http://example.org/road1”, ”target”: { ”source”: ”http://example.org/mygridfeature”, ”selector”: { ”type”: ”XYZSelector”, ”targetFeature”: ””, ”coordinateSystem”: ”WKTCS”, ”value”: ”GRIDLITERAL” }
}
Listing 5: Sample Web Annotation describing an opinion ”@context”: ”http://www.w3.org/ns/anno.jsonld”, ”id”: ”http://example.org/anno27”, ”type”: ”Annotation”, ”body”: ”http://example.org/road1”, ”target”: { ”source”: ”http://example.org/myfeaturecollection”, ”selector”: { Listing 4 shows that the definition of a selector can also be applied for a given raster, considering the raster can be described with a grid literal type, such as a DGGS literal [16], a list of grid cells (XYZ) or a CoverageJSON literal [19].
This section converts the newly defined W3C Web Annotation Data Model for geospatial features to a feature layer that may be used in any GIS application. As the structure of this feature layer may also be represented in GeoJSON, this set of steps can be seen as equivalent to creating a GeoJSON-LD conversion. To do this, all possible annotation bodies in the web annotation data model must be converted into equivalent elements in a GIS vector layer. The conversion from geospatial web annotations to GeoJSON is shown as a principal example of this method. The conversion works similarly for other geospatial vector data formats.
Listing 5 shows one example annotation, converted to an equivalent GeoJSON representation in Listing 6. For n given annotations in a JSON-LD [20] file, the whole JSON-LD file might be converted to a vector layer. Next, another layer can be generated by converting the annotation targets. The result is two geospatial vector layers, representing a self-contained dataset of the geospatial web annotation data model file. The reverse is also possible, i.e., to define an annotation layer and an annotation target layer for conversion into the web annotation data model. Note that, in this example, annotations bodies have been stated as ”http://example.org/road1” for brevity. An arbitrary amount of annotation bodies may be added in both formats.
Web annotations become increasingly attractive if they can also be submitted to a web hosting service for web annotations. For example, Wikidata could provide a place to host web annotations, which may be retrieved either as an annotation layer or which may be retrieved using a SPARQL [21] endpoint. However, another possibility could be an active search for geospatial web annotation layers in linked data and its exposition in specific web feature services. The OGC API Features standard allows for the definition of diferent backends and implementations and even the possibility of statically hosting annotation layers, so that annotation layers could be exposed using already established technologies to the GIS community. On top of that, recent work [22] has shown that RDF dumps may be exposed as static OGC API Feature APIs from a simple webspace 8, e.g., on a Github Page. With this approach, every webspace may be transformed and may serve as an OGC API Features Service for annotations. 5. Proof Of Concept Implementation in QGIS To put this proposed way of annotation into practice, a QGIS plugin9 has been developed which can annotate given layers using several selector tools. Selected vector layers in QGIS can be targeted for selection. Annotations may then be related to • Selected features from the targeted QGIS layer • A freeform selected area, line, or point, independent of the layer’s geometries, which may indicate additional information
Figure 1 shows the annotation dialog, which may be used to annotate one or many selected geospatial features and the resulting annotation layer. This layer may now be exported as Web Annotation JSON-LD or any other linked data serialization, as a GeoJSON-LD file, or as any other geospatial format, possibly in combination with the original layer.
This section shows a list of potential use cases that are either not implemented or currently rely on third-party databases providing closed environments for their specific annotation purpose rather than linked open-data web annotations. Using the web annotation data model specification present in this publication, these services might be enabled to publish their data interoperably.
Consider the layer discussed in the previous section, which displays parts of the ancient Roman border limes. A group of scholars may use the Web Annotation Data Model to annotate the certainty of the locations of these settlements, and they may comment on the disputes scholars have when determining them. Finally, the annotation layer may be saved as JSON-LD and published in a GitHub repository as a result of the group’s discussion. Colleagues interested in the result of these discussions or automated machine learning approach might benefit from the publication of said discussion results in a formalized way and linked to the original dataset.
Using the SPARQLing Unicorn Ontology Documentation plugin, this example use case is accessible on GitHub. Hence, it is possible to integrate the Annotation layer as a statically published Layer in QGIS.
This example use case should illustrate the usefulness of the newly defined web annotation data model extension in agreeing on specific terms in their respective contexts. It determines the safety rating of given geospatial locations. This use case is of interest because people often do not consider places inherently safe or unsafe; they have difering opinions about this matter. Also, bigger places like parks may exhibit areas where people feel comfortable walking around (e.g., illuminated places at night) and places where a perceived higher threat of theft or other crimes is expected. These areas are not displayed on OpenStreetMap, as they do not have characteristics of objective data and do not represent whole geographical features that may already be annotated using the existing web data annotation model.
The third example case concerns the internal workings of a national planning authority. Once a land use plan has been made public for comments, a geospatial authority will need to discuss various feedback to eventually decide upon the final changes to be integrated into the zoning plan. Many state authorities are involved in these situations, and many state authorities can possibly wish to alter the zoning plan. For example, the fire brigade department might want better access to a row of planned buildings in case of an emergency, or another state authority might not be satisfied with the planned zoning of parts of a given area.
This publication introduced an extension to the W3C Web Annotation Data Model, which allows for annotating individual parts of geometries identified by a URI provided locally, using a geospatial web service, or using linked data technologies. The publication suggests three diferent ways for annotation under the consideration of diferent serialization formats and varying CRS systems and with compatibility with the GeoSPARQL standard. The ability to create web annotations with a geospatial component allows for greater flexibility in communicating statements about geospatial locations independent of the constraints of geospatial databases.
Future work might investigate how to combine this method of creating web annotations with emerging work on creating ontologies for coordinate reference systems10 so that coordinate reference systems can also be entirely described in RDF. This would allow for the inclusion of customized coordinate reference system definitions for geospatial web annotations, which are possibly needed for the annotation of historical data and the annotation of 3D scans. In addition, this proposal could serve as a template for adopting the proposed family of GeoSelector types into the Web Annotation Data Model standard, or provide an extension of the original standard. With ongoing work to standardize annotations in 3D in the cultural heritage domain being discussed in, for example, the national research data infrastructures of Germany (NFDI)11 and the IIIF 3D Technical Specification Group 12, the likelihood of an extension of details of the Web Annotation Data Model become increasingly likely from another initiative. A collaboration may, in the future, be a good way of reaching beyond a specification primarily targeted at geospatial data. 10https://github.com/opengeospatial/ontology-crs 11https://www.nfdi4objects.net 12https://iiif.io/news/2022/01/11/new-3d-tsg/ [7] O. Hartig, A. Seaborne, P.-A. Champin, G. Kellogg, RDF 1.2 Concepts and Abstract Syntax, W3C Working Draft, W3C, 2024. Https://www.w3.org/TR/2024/WD-rdf12-concepts20240121/. [8] T. Berners-Lee, R. T. Fielding, L. M. Masinter, Uniform Resource Identifier (URI): Generic Syntax, RFC 3986, 2005. URL: https://www.rfc-editor.org/info/rfc3986. doi:1 0 . 1 7 4 8 7 / R F C 3 9 8 6 . [9] B. Brinza, C. Lilley, E. Willigers, D. Schulze, D. Storey, A. Bellamy-Royds, Scalable Vector Graphics (SVG) 2, Candidate Recommendation, W3C, 2018.
Https://www.w3.org/TR/2018/CR-SVG2-20181004/. [10] K. Taylor, A. Haller, M. Lefrançois, S. J. Cox, K. Janowicz, R. Garcia-Castro, D. Le Phuoc, J. Lieberman, R. Atkinson, C. Stadler, The semantic sensor network ontology, revamped, in: JT@ ISWC, 2019. [11] M. Doerr, A. Kritsotaki, Y. Rousakis, G. Hiebel, M. Theodoridou, Crmsci: The scientific observation model (2014). [12] C. McCormack, A. Grasso, C. Lilley, J. Fujisawa, D. Jackson, J. Watt, J. Ferraiolo, E. Dahlström, P. Dengler, D. Schepers, Scalable Vector Graphics (SVG) 1.1 (Second Edition), W3C Recommendation, W3C, 2011. Https://www.w3.org/TR/2011/REC-SVG11-20110816/. [13] H. Butler, M. Daly, A. Doyle, S. Gillies, T. Schaub, T. Schaub, The GeoJSON Format, RFC 7946, 2016. URL: https://rfc-editor.org/rfc/rfc7946.txt. doi:1 0 . 1 7 4 8 7 / R F C 7 9 4 6 . [14] R. Simon, J. Korb, C. Sadilek, R. Schmidt, Collaborative map annotation in the context of historical gis, in: 2009 5th IEEE International Conference on E-Science Workshops, 2009, pp. 139–142. doi:1 0 . 1 1 0 9 / E S C I W . 2 0 0 9 . 5 4 0 7 9 7 7 . [15] J. Tandy, P. Barnaghi, L. van den Brink, Spatial Data on the Web Best Practices, Technical
Report, W3C, 2017. Https://www.w3.org/TR/2017/NOTE-sdw-bp-20170928/. [16] N. J. Car, T. Homburg, Geosparql 1.1: Motivations, details and applications of the decadal update to the most important geospatial lod standard, ISPRS International Journal of Geo-Information 11 (2022) 117. [17] M. Perry, J. Herring, OGC GeoSPARQL - A Geographic Query Language for RDF Data, OGC Standard, Open Geospatial Consortium, Wayland, MA, USA, 2012. https://www.ogc.org/ standards/geosparql (accessed on 22.05.2021). [18] N. J. Car, T. Homburg, M. Perry, J. Herring, F. Knibbe, S. J. Cox, J. Abhayaratna, M. Bonduel, Ogc geosparql-a geographic query language for rdf data, OGC Implementation Standard OGC (2021). [19] T. Homburg, S. Staab, D. Janke, Geosparql+: syntax, semantics and system for integrated querying of graph, raster and vector data, in: International Semantic Web Conference, Springer, 2020, pp. 258–275. [20] D. Longley, G. Kellogg, P.-A. Champin, JSON-LD 1.1, W3C Recommendation, W3C, 2020.
Https://www.w3.org/TR/2020/REC-json-ld11-20200716/. [21] A. Seaborne, S. Harris, SPARQL 1.1 Query Language, W3C Recommendation, W3C, 2013.
Https://www.w3.org/TR/2013/REC-sparql11-query-20130321/. [22] F. Thiery, T. Homburg, The sparql unicorn ontology documentation: Exposing rdf geodata using static geoapis, in: FOSSGIS 2024 Konferenzband, 2024.