- From: Frans Knibbe <fjknibbe@gmail.com>
- Date: Thu, 20 Aug 2020 15:49:03 +0200
- To: peb aryan <pebbie@gmail.com>
- Cc: Semantic Web <semantic-web@w3.org>
- Message-ID: <CADh4F1RVFJKz4cZ75_bs4vE0hxYkk=x43_DrVGM0xF99vwnenw@mail.gmail.com>
Hello Peb, Thanks for your insights! I think I understand your experiences. One way of looking at publishing and linking raw data on the web is expecting data to be directly usable, without needing to pull the data through offline software. Although that would be great, I don't think it will happen anytime soon. Probably additional specialist software will be always needed by specialists. But we do have to make sure that raw data on the web are as usable as possible for any additional software. So extra care must be given to thoroughness, completeness, interpretability, etc. of (spatial) data on the web. In that respect, I'm sure there is room for improvement in GeoSPARQL. The subject you raise about accessing sub-geometries is interesting, because the problem could be solved by specifying additional SPARQL functions (like ST_PointN <http://postgis.net/docs/ST_PointN.html> and ST_GeometryN <https://postgis.net/docs/ST_GeometryN.html> in PostGIS), but it could also be solved by allowing complex/nested geometries in the (RDF) graph. So this requirement could play a role in discussion about optimal (or allowed) representations of geometry in the semantic web: is it necessary to pick one geometry 'atom', and if so, what should it be? Anyway, the two PostGIS functions I mentioned are described in the OGC simple features for SQL specification, so adding them to GeoSPARQL is covered by this issue <https://github.com/opengeospatial/geosemantics-dwg/issues/13>. About transforming geometry coordinates from one coordinate reference system (CRS) to another: I don't see an issue for that yet in the list. Would you care to add one? And would you agree that the best way to express the CRS of a geometry is to use an IRI in a separate graph node? Greetings, Frans Op di 18 aug. 2020 om 14:27 schreef peb aryan <pebbie@gmail.com>: > Hi Frans, > > Thank you for initiating the discussion. > As a person who has worked on both worlds, I still find GeoSPARQL very > limiting from both sides. > > The last thing I really used geosparql for was mashing up personal > trajectory data and public transport (GTFS). > Other than that, it's far easier to just directly manipulate the spatial > data itself with OGR/GDAL. > > Some difficulties i encountered are on how to do geometry manipulation > when querying, e.g. : > - functions for accessing sub-geometries (e.g. point at index i from a > line or a polyline), retrieving one coordinate component from a literal > value in WKT, or constructing new geometry component without falling back > to error-prone string manipulation > - a way to express transformation of geometry from one CRS to another CRS > outside WKT specs(also with the update on how it is expressed with > WKT2:2015 and WKT2:2019 allows for custom pipeline and referencing raster > data source (i.e. geoid & custom local correction grid)). > - functions involving different spatial data representation beyond > qualitative spatial relations: e.g. augmenting 2D data with raster for > vertical component and making it 3D point data. > - a way to express the CRS of a geometry in less verbose manner > > The above issues are what I can summarize from photogrammetry/remote > sensing domain. > It seems that some of the issues (CRS, 3D and Rasters) have already been > raised in the github and the standard tracker. > > Cheers, > > Peb > > On Tue, Jul 28, 2020 at 10:13 PM Frans Knibbe <fjknibbe@gmail.com> wrote: > >> Hi, >> >> GeoSPARQL <https://www.ogc.org/standards/geosparql> 1.0 (released in >> 2012) is a standard from the OGC <https://www.ogc.org/about>. It offers, >> among other things, an ontology for geographical features and geometry >> <http://www.opengis.net/ont/geosparql#> and SPARQL functions to work >> with geospatial data. >> As Simon wrote, GeoSPARQL is about to be revised, so now is a perfect >> time for the semantic web community to have a critical look at the >> specification. I would say that the upcoming revision work is not only of >> interest to those who are already using GeoSPARQL, but also to everyone >> that might some day work with spatial/geometric data on the web, either on >> the supply or the demand side. So that is probably you, dear reader :-) >> The current list of issues for the revision >> <https://github.com/opengeospatial/geosemantics-dwg/issues> was mainly >> compiled by people whose job it is to work with (geo)spatial data. I think >> it will be very beneficial for the revision if people with different >> backgrounds make their impressions known. Explicit targets for the next >> version of GeoSPARQL are improving the way GeoSPARQL can be put to use in >> the Semantic Web and in graph databases, so any input from people working >> in those areas is highly valued and of great importance. >> Here are some questions that could spark a bit of discussion in this >> list, perhaps resulting in additional official comments or change requests: >> >> - Have you ever used GeoSPARQL? If so, any problems? >> - Have you ever tried to implement (parts of) GeoSPARQL in your >> software? If yes, did you run into problems? >> - Have you ever run into problems working with spatial or geometric >> data? Perhaps on the ontology level, or on the data integration level, or >> in some other way? >> - Domains like geography, astronomy, biology, computer graphics, web >> graphics, building information modelling (BIM) and computer aided design >> (CAD) all use spatial data. Have you ever tried to somehow combine >> different types of spatial data or spatial knowledge? If so, how was that >> experience? >> >> Even if you're not interested in spatial data on the web at all, but do >> like to fuss about lists in RDF or the sweet spot of atomicity in RDF >> literals, you're very welcome to weigh in... >> >> Greetings, >> Frans >> >> Op di 21 jul. 2020 om 08:19 schreef Cox, Simon (L&W, Clayton) >> <Simon.Cox@csiro.au>: >> >>> ... revision underway. Submit issues and requests here: >>> https://github.com/opengeospatial/geosemantics-dwg >>> >>> -----Original Message----- >>> From: Linda van den Brink <l.vandenbrink@geonovum.nl> >>> Sent: Tuesday, 21 July, 2020 01:42 >>> To: public-sdwig <public-sdwig@w3.org> >>> Subject: FYI: OGC requests public comment on GeoSPARQL Standards Working >>> Group recharter >>> >>> Hi all, >>> >>> This may be of interest to some of you and may have been missed by >>> non-OGC members... >>> >>> We have talked a little about work on the GeoSPARQL standard in this >>> group. The work will take place within OGC, where a working group is now >>> being resurrected. This OGC Standards Working Group will provide a major >>> update to a key standard for representing and querying spatial data on the >>> Semantic Web. >>> >>> The Open Geospatial Consortium (OGC) now seeks public comment on the >>> draft updated charter for the OGC GeoSPARQL Standards Working Group (SWG). >>> The GeoSPARQL SWG will revise, and likely extend, the GeoSPARQL standard. >>> Comments are due by August 6, 2020. >>> >>> See https://www.ogc.org/standards/requests/210 for more information. >>> >>> Linda >>> >>
Received on Thursday, 20 August 2020 13:49:26 UTC