- From: Andrea Perego via GitHub <sysbot+gh@w3.org>
- Date: Mon, 04 Mar 2019 22:36:14 +0000
- To: public-dxwg-wg@w3.org
I'm all for WKT, but I would like to re-state a couple of issues mentioned earlier in this thread (see https://github.com/w3c/dxwg/issues/83#issuecomment-371650468): 1. The level of complexity of the proposed solution(s): As I mentioned earlier, the requirement in LOCN (and then in GeoDCAT-AP) was to reduce as much as possible the number of nodes in the graph between the dataset and the geometry specifying its spatial coverage. IMO, this is a common concern, and it is probably not surprising that some triple stores (as Virtuoso) have a buit-in property `geo:geometry` (which is not included in the W3C Basic Geo vocabulary), whose range is a WKT literal. 2. The need to have specific properties to represent centroids and bboxes: This is typically how spatial coverage is specified when it is a geometry, but we don't have properties for doing the job. This can be addressed if using GML (which has the notion of "Envelope"), but not in WKT. But this means that this information will be at the level of literal only. In my experience, these are the main issues people are stumbling upon. -- GitHub Notification of comment by andrea-perego Please view or discuss this issue at https://github.com/w3c/dxwg/issues/83#issuecomment-469450087 using your GitHub account
Received on Monday, 4 March 2019 22:36:17 UTC