BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//pretalx//talks.staging.osgeo.org//foss4g-europe-2024-academic-tra
 ck//speaker//UF7J7G
BEGIN:VTIMEZONE
TZID:EET
BEGIN:STANDARD
DTSTART:20000101T000000
RRULE:FREQ=YEARLY;BYMONTH=1;UNTIL=20001231T220000Z
TZNAME:EET
TZOFFSETFROM:+0200
TZOFFSETTO:+0200
END:STANDARD
BEGIN:STANDARD
DTSTART:20021027T050000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
TZNAME:EET
TZOFFSETFROM:+0300
TZOFFSETTO:+0200
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20020331T040000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
TZNAME:EEST
TZOFFSETFROM:+0200
TZOFFSETTO:+0300
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
UID:pretalx-foss4g-europe-2024-academic-track-7CXQ9S@talks.staging.osgeo.or
 g
DTSTART;TZID=EET:20240703T121000
DTEND;TZID=EET:20240703T121500
DESCRIPTION:Motivation\n----------\n\n\nSpatial Data Infrastructures (SDI) 
 developed for the exchange of environmental\nhas heretofore been greatly s
 haped by the standards issued by the Open\nGeospatial Consortium (OGC). Ba
 sed on the Simple Object Access Protocol (SOAP)\,\nservices like WMS\, WFS
 \, WCS\, CSW became digital staples for researchers and\nadministrative bo
 dies alike. \n\nIn 2017 the Spatial Data on the Web Working Group (SDWWG) 
 questioned the overall\napproach of the OGC\, based on the ageing SOAP tec
 hnology\n[@SDWWG2017]. The main issues identified by the SDWWG can be summ
 arised as:\n\n- Spatial resources are not identified with URIs.\n- Modern 
 API frameworks\, e.g. OpenAPI\, are not being used.\n- Spatial data are st
 ill shared in silos\, without links to other resources.\n- Content indexin
 g by search engines is not facilitated.\n- Catalogue services only provide
  access to metadata\, not the data.\n- Data difficult to understand by non
 -domain-experts.\n\nTo address these issues the SDWWG proposed a five poin
 t strategy inspired on the\nFive Star Scheme [@BernersLee2006]:\n\n- **Lin
 kable**: use stable and discoverable global identifiers.\n- **Parseable**:
  use standardised data meta-models such as CSV\, XML\, RDF\, or JSON.\n- *
 *Understandable**: use well-known\, well-documented\, vocabularies/schemas
 .\n- **Linked**: link to other resources whenever possible.\n- **Usable**:
  label data resources with a licence.\n\nThe work of the SDWWG triggered a
  transformational shift at the OGC towards\nspecifications based on the Op
 enAPI. But while convenience of use has been the\nfocus\, semantics has be
 en largely unheeded. A Linked Data agenda has not\nbeen pursued.\n\nHoweve
 r\, the OpenAPI opens the door to an informal coupling of OGC services wit
 h\nthe Semantic Web\, considering the possibility of adopting JSON-LD as\n
 syntax to OGC API responses. The introduction of a semantic layer to digit
 al\nenvironmental data shared through state-of-the-art OGC APIs is becomin
 g a\nreality\, with great benefits to researchers using or sharing data.\n
 \nThis communication lays down a simple SDI set up to serve semantic envir
 onmental\ndata through a SensorThings API created with the `glrc` software
 .  A use case is\npresented with soil data services compliant with the Glo
 SIS web ontology.\n\nSensorThings API\n----------------\n\nSensorThings AP
 I is an OGC standard specifying a unified framework to\ninterconnect Inter
 net of Things resources over the Web [@liang2016ogc].\nSensorThings API ai
 ms to address both the semantic\, as well as syntactic\,\ninteroperability
 . It follows ReST principles [@fielding2002principled]\,\npromotes data en
 coding with JSON\, the OASIS OData protocol\n[@chappell2011introducing] an
 d URL conventions. \n\nThe SensorThings API is underpinned on a domain mod
 el aligned with the ISO/OGC\nstandard Observations & Measurements (O&M) [@
 Cox2011]\, targeted at the\ninterchange of observation data of natural phe
 nomena. O&M puts forth the\nconcept of `Observation` has an action perform
 ed on a `Feature of Interest`\nwith the goal of measuring a certain `Prope
 rty` through a specific `Procedure`.\nSensorThings API mirrors these conce
 pts with `Observation`\, `Thing`\,\n`ObservedProperty` and `Sensor`. This 
 character makes of SensorThings API a\nvehicle for the interoperability of
  heterogeneous sources of environmental\ndata.\n\n\n`glrc`\n------\n\n`grl
 c` (pronounced "garlic") is a lightweight server that translates SPARQL\nq
 ueries into Linked Data web APIs [@merono2016grlc] compliant with the Open
 API\nspecification. Its purpose is to enable universal access to Linked\nD
 ata sources through modern web-based mechanisms\, dispensing the use of th
 e\nSPARQL query language. While losing the flexibility and federative capa
 cities\nof SPARQL\, web APIs present developers with an approachable inter
 face that can\nbe used for the automatic generation of source code.\n\n\nA
  `glrc` API is constructed from a SPARQL query to which a meta-data sectio
 n is\nprepended. This section is declared with a simplified YAML syntax\, 
 within a\nSPARQL comment block\, so the query remains valid SPARQL. The me
 ta-data provide\nbasic information for the API set up and most importantly
 \, the SPARQL end-point\non which to apply the query. The listing below sh
 ows an example. \n\n```\n#+ endpoint: http://dbpedia.org/sparql\n\nPREFIX 
 dbo: <http://dbpedia.org/ontology/>\nPREFIX dbr: <http://dbpedia.org/resou
 rce/>\nPREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>\nPREFIX rdf: <
 http://www.w3.org/1999/02/22-rdf-syntax-ns#>\n\nSELECT ?band_label { \n   
  ?band rdf:type dbo:Band \;\n          dbo:genre dbr:Hard_Rock \;\n       
    rdfs:label ?band_label .\n} ORDER BY ?band_label\n```\n\nA special SPAR
 QL variable formulation is used to map into API parameters. By\nadding an 
 underscore (`_`) between the question mark and the variable name\,\n`glrc`
  is instructed to create a new API parameter. A prefix separated again\nwi
 th an underscore informs `glrc` of the parameter type. The `?band_label`\n
 variable can be expanded to `?_band_label_iri` to create a\nnew API parame
 ter of the type IRI.\n\n\nUse case: GloSIS\n----------------\n\nThe Global
  Soil Partnership (GSP) is a network of stakeholders in the soil\ndomain e
 stablished by members of the United Nations Food and Agriculture\nOrganisa
 tion (FAO). Its broad goals are to raise awareness to the importance of\ns
 oils and to promote good practices in land management towards a sustainabl
 e\nagriculture. \n\nAcknowledging difficulties in exchanging harmonised so
 il data as an important\nobstacle to its goals\, the GSP launched in 2019 
 an international consultancy to\nassess the state-of-the-art and propose a
  path towards a Global Soil Information\nSystem (GloSIS) based on a unifie
 d exchange. A domain model resulted\, based\non the ISO 28258 standard for
  soil quality [@SchleidtReznik2020]\, augmented with\ncode-lists compiled 
 from the FAO Guidelines for Soil Description [@Jahn2006].\nThis domain mod
 el was then transformed to a Web Ontology\, relying on the Sensor\,\nObser
 vation\, Sample\, and Actuator ontology (SOSA) [@Janowicz2019]\, and other
 \nSemantic Web standards such as GeoSPARQL\, QUTD and SKOS. The GloSIS web
  ontology\nhas been successfully demonstrated as a vehicle to exchange soi
 l information as\nLinked Data [@GloSIS]. \n\nA prototype API for the GloSI
 S ontology\, formulated in compliance with the\nSensorThings API specifica
 tion\, will be presented in this communication. It\ndemonstrates how the s
 ame set of SPARQL queries can be used to query through a\nReST API any end
 -point available over the internet\, sharing linked soil data in\naccordan
 ce with the GloSIS ontology. Thus providing a clear step towards the\nfede
 rated and harmonised system envisioned by the GSP.
DTSTAMP:20260601T171934Z
LOCATION:Omicum
SUMMARY:The template for a Semantic SensorThings API with the GloSIS use ca
 se - Luís M. de Sousa
URL:https://talks.staging.osgeo.org/foss4g-europe-2024-academic-track/talk/
 7CXQ9S/
END:VEVENT
END:VCALENDAR