=Paper=
{{Paper
|id=Vol-3743/paper5
|storemode=property
|title=GeoWebAnnotations: Extending the W3C Web Annotation Data Model for geospatial data
|pdfUrl=https://ceur-ws.org/Vol-3743/paper5.pdf
|volume=Vol-3743
|authors=Timo Homburg
|dblpUrl=https://dblp.org/rec/conf/geold/Homburg24
}}
==GeoWebAnnotations: Extending the W3C Web Annotation Data Model for geospatial data==
https://ceur-ws.org/Vol-3743/paper5.pdf
GeoWebAnnotations: Extending the W3C Web
Annotation Data Model to annotate geospatial data
Timo Homburg1
1
i3mainz – Institute for Spatial Information & Surveying Technology, Mainz University of Applied Sciences, 55128
Mainz, Germany
Abstract
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.
Keywords
Web Annotation Data Model, Well-Known Text, Linked data, Annotation layers, QGIS Plugin, Geospatial
Annotation
1. Introduction
Annotations are becoming an increasingly common method of participating in the scientific
discourse. Especially since the W3C Web Annotation Data Model [1] has been introduced,
the prospect of annotating images and other web resources has been used by scholars to a
great extent to stimulate scholarly discussion about them. However, the concept of a web
annotation, in the same way, has not really gained traction in the GIS community as of writing
this publication. While annotations exist in the GIS community, they are often not shared in
the same way as suggested by the principles of the 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 [2]. In that case, the information can
be easily added using an appropriate tool such as JOSM1 and will stay saved if the information
is not controversial and fits the scope of the map. For this purpose, even different web portals
such as the Wheelmap [3] for adding wheelchair accessibility provide easy access to annotate
or add information to a knowledge base.
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.
6th International Workshop on Geospatial Linked Data (GeoLD2024) at ESWC 2024, May 26th, 2024, Hersonissos, Greece
Envelope-Open timo.homburg@hs-mainz.de (T. Homburg)
GLOBE https://situx.github.io/ (T. Homburg)
Orcid 0000-0002-9499-5840 (T. Homburg)
© 2024 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
CEUR
Workshop
Proceedings CEUR Workshop Proceedings (CEUR-WS.org)
http://ceur-ws.org
ISSN 1613-0073
1
https://josm.openstreetmap.de/
CEUR
ceur-ws.org
Workshop ISSN 1613-0073
Proceedings
Annotations in the context of this publication serve a different 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 different database referring to map content by identifiers.
In a guide of providing data to OpenStreetMap2 it is stated that data should be factual, long-
term, 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 [4] or simply a personalized
rating of favorite or perceived wrong things on a given map. To provide such subjective data, the
GIS community usually resorts to manually created databases and data formats representing map
layers, which may or may not relate directly to a feature by its given ID or a geolocation in the
same area as the feature in question. This inevitably leads to diversification in how annotation
information is saved and to a lack of interoperability and accessibility of said annotations. The
simple question, ”Which opinions and subjective statements have been made about a geospatial
object?” results in the querying of possibly inaccessible and often diverse data sources, which
—if properly accessible— need to undergo a normalization process to be usable. Instead, this
publication proposes saving annotations in a unified linked data format so that they may be
shared across the Semantic Web. The idea brought forward relies on an extension of the W3C
Web Annotation Data Model to incorporate geospatial features.
2. Foundations
This section introduces the foundations of annotations in the GIS community and other research
communities.
2.1. Annotations in GISScience
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 different 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), [5], which can set the two layers
2
https://blog.openstreetmap.org/wp-content/uploads/2020/07/Providing-data-to-OpenStreetMap.pdf
into context. This, however, is subject to change with the currently emerging standardization
of the OGC API Features web services. These newly adopted web services will mandate that
each geospatial feature be defined by its own URI, uniquely identifying it across a given OGC
API Features service [6]. This enables the unambiguous addressing of geospatial features and
the opportunity for targeted annotations that require a unique identifier, which is usually a
prerequisite for applying annotation models.
2.2. W3C Web Annotation Data Model
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 different 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 ”@context”: ”http://www.w3.org/ns/anno.jsonld”,
3 ”id”: ”http://example.org/anno27”,
4 ”type”: ”Annotation”,
5 ”body”: {
6 ”type”: ”TextualBody”,
7 ”value”: ”This is the best part of my image”
8 },
9 ”target”: {
10 ”source”: ”http://example.org/myimage”,
11 ”selector”: {
12 ”type”: ”SvgSelector”,
13 ”value”: ” ... ”
14 }
15 }
16 }
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.
3. Related Work
The following presents related work on how annotations on map data have been used and
previously saved in the GIS community.
3.1. Annotations vs. Observations
There are vocabularies for describing observations instead of annotations that should be con-
sidered 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.
3.2. Annotation of georeferenced images
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:
3
https://allmaps.org
4
https://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.
4.1. Components of a GeoWebAnnotation
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 different subtypes of the GeoSelector for different 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
1 {
2 ”@context”: ”http://www.w3.org/ns/anno.jsonld”,
3 ”id”: ”http://example.org/anno27”,
4 ”type”: ”Annotation”,
5 ”body”: ”http://example.org/road1”,
6 ”target”: {
7 ”source”: ”http://example.org/myroadfeature”,
8 ”selector”: {
9 ”type”: ”WktSelector”,
10 ”targetFeature”: ””,
11 ”coordinateSystem”: ”WKTCS”,
12 ”value”: ”WKTLITERAL”
13 }
14 }
15 }
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
5
http://docs.opengeospatial.org/is/17-069r3/17-069r3.html
(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 sufficient. 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 system7 . 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].
4.2. Relative annotations
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 ”@context”: ”http://www.w3.org/ns/anno.jsonld”,
3 ”id”: ”http://example.org/anno27”,
4 ”type”: ”Annotation”,
5 ”body”: ”http://example.org/road1”,
6 ”target”: {
7 ”source”: ”http://example.org/myfeature”,
8 ”selector”: {
9 ”type”: ”WktSelector”,
10 ”targetFeature”: ””,
11 ”value”: ”WKTLITERAL”
12 }
13 }
14 }
6
https://epsg.io/25833
7
https://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
1 {
2 ”@context”: ”http://www.w3.org/ns/anno.jsonld”,
3 ”id”: ”http://example.org/anno27”,
4 ”type”: ”Annotation”,
5 ”body”: ”http://example.org/road1”,
6 ”target”: {
7 ”source”: ”http://example.org/mygridfeature”,
8 ”selector”: {
9 ”type”: ”XYZSelector”,
10 ”targetFeature”: ””,
11 ”coordinateSystem”: ”WKTCS”,
12 ”value”: ”GRIDLITERAL”
13 }
14 }
15 }
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].
4.3. Conversion to annotation map layers
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: Sample Web Annotation describing an opinion
1 {
2 ”@context”: ”http://www.w3.org/ns/anno.jsonld”,
3 ”id”: ”http://example.org/anno27”,
4 ”type”: ”Annotation”,
5 ”body”: ”http://example.org/road1”,
6 ”target”: {
7 ”source”: ”http://example.org/myfeaturecollection”,
8 ”selector”: {
9 ”type”: ”WktSelector”,
10 ”targetFeature”: ”http://example.org/myfeaturecollection/myfeature”,
11 ”coordinateSystem”: ”WKTCS”,
12 ”value”: ”POINT(1 1)”
13 }
14 }
15 }
Listing 6: Equivalent representation in GeoJSON
16 {
17 {”type”:”FeatureCollection”,
18 ”features”:[
19 {
20 ”type”:”Feature”,
21 ”id”:”http://example.org/anno27”,
22 ”properties”:{
23 ”annotation”:”http://example.org/road1”,
24 ”type”:”URL”,
25 ”target”:”http://example.org/myfeaturecollection”,
26 ”targetFeature”:”http://example.org/myfeaturecollection/myfeature”,
27 },
28 ”geometry”:{
29 ”type”: ”Point,
30 ”coordinates”:[1,1]
31 }}]}}
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 annota-
tion 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.
4.4. Web Annotation Feature Services
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 annota-
tions, 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 different 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: Geowebannotation QGIS plugin defining an annotation layer on a vector layer of points of
settlements near the ancient Roman border limes. The annotation layer and the selection polygon are
shown. The layer consists of annotations on the selector points.
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.
8
https://github.com/sparqlunicorn/sparqlunicornGoesGIS-ontdoc
9
https://github.com/situx/geowebannotation
6. Potential Use Cases
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.
6.1. Example use case: Limes data
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.
6.2. Example use case: Safety perceptions
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 differing 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.
6.3. Example use case: Map planning
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.
7. Conclusions
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
different ways for annotation under the consideration of different 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.
7.1. Future Work
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 Group12 , 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.
References
[1] P. Ciccarese, B. Young, R. Sanderson, Web Annotation Data Model, W3C Recommendation,
W3C, 2017. Https://www.w3.org/TR/2017/REC-annotation-model-20170223/.
[2] M. Haklay, P. Weber, Openstreetmap: User-generated street maps, IEEE Pervasive
computing 7 (2008) 12–18.
[3] A. Mobasheri, J. Deister, H. Dieterich, Wheelmap: the wheelchair accessibility crowd-
sourcing platform, Open Geospatial Data, Software and Standards 2 (2017) 1–7.
[4] S. Rodriguez Garzon, B. Deva, Sensafety: Crowdsourcing the urban sense of safety (2019).
[5] J. Nogueras-Iso, F. J. Zarazaga-Soria, R. Béjar, P. Álvarez, P. R. Muro-Medrano, Ogc catalog
services: a key element for the development of spatial data infrastructures, Computers &
Geosciences 31 (2005) 199–209.
[6] G. Hobona, S. Simmons, J. Masó-Pau, J. Jacovella-St-Louis, Ogc api standards for the next
generation of web mapping, Abstracts of the ICA 6 (2023) 91.
10
https://github.com/opengeospatial/ontology-crs
11
https://www.nfdi4objects.net
12
https://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 Syn-
tax, W3C Working Draft, W3C, 2024. Https://www.w3.org/TR/2024/WD-rdf12-concepts-
20240121/.
[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 /
RFC3986.
[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.