Re: [sdw] BP 10 http://www.bbc.co.uk/ontologies gone (#1328)

I think several things hindered the application and implementation of semantic web technologies in the GISSciences so far:

- ​Lack of standards or incomplete standards (compared to e.g. PostGIS or SQL/MM) to represent and work with spatial data in RDF (this may be improving with GeoSPARQL 1.1 onwards)
- Lack of possibilities to represent certain geospatial data types in linked data (e.g. coverages), even though approaches are created for that
- Lack of easy to use tools for the access of geospatial linked data (is also improving as there are now plugins for QGIS and a research project for ArcGIS and some middleware between RDF data and OGC API features in development)
- Lack of easy to use tools for managing geospatial linked data (e.g. until recently it was quite a pain to even convert geospatial RDF data from one CRS to another)
- Lack of easy to use tools to create mappings from GIS data to geospatial linked data vocabularies
- Lack of education/motivation of participating institutions to describe their data in their own vocabulary or to reuse existing vocabularies to classify the data they provide and lack of easy to use tools to create mappings from geodata to RDF
- Lack of (complete) geospatial-aware triple store implementations and compliance testing until very recently
- A lack of explanation/relation of OGC API Features services to Semantic Web Technologies (the trend, in my opinion, could be to use triple stores as the backend of OGC API Features services to provide more comprehensive access to and as a user combine data, i.e. a SPARQL endpoint is an offer in addition to an OGC API Feature service)
- Lack of convincing application cases to motivate a transition to linked data, as these use cases often span more than one institution and are not always encouraged by employers

With that being said I can also see more institutions trying out linked data technologies recently.
People often see the adoption of linked data technologies synonymous with having to deal with SPARQL and RDF, whereas the same does not seem to be true with (geospatial-aware) SQL databases.
People happily use SQL databases, but these databases are often masked by middleware web services. To be successful I believe the same needs to be done for SPARQL endpoints.
If the important data (e.g. feature collections), i.e. the data that would normally be provided by the mapping agency, can be exposed using the OGC API Features service, but people can still access more (related) data using a SPARQL endpoint, we can find a middle ground of traditional GIS people who "just want to download their data" and more sophisticated apps which make use of possibly even more than one SPARQL endpoint to solve a task. 

-- 
GitHub Notification of comment by situx
Please view or discuss this issue at https://github.com/w3c/sdw/issues/1328#issuecomment-1020475936 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 24 January 2022 19:43:09 UTC