- From: Andreas Harth <harth@fzi.de>
- Date: Thu, 13 Aug 2015 12:48:33 +0200
- To: <public-sdw-comments@w3.org>
Hi, have a look at [1], which publishes the "GADM database of Global Administrative Areas" [2] as Linked Data, and also tries to take into account hypermedia. We have links between Features (e.g., from Germany to Baden-Wuertemberg to Karlsruhe), and have APIs for RCC8 relations. We have external links to GADM from DBpedia [3] and LinkedGeoData.org (which links to the APIs via URI templates). I still have to add rdfs:subClassOf/rdfs:subPropertyOf statements to other vocabularies to demonstrate how to provide links on the schema/vocabulary level. Best regards, Andreas. [1] http://gadm.geovocab.org/ [2] http://gadm.org/ [3] http://downloads.dbpedia.org/2015-04/links/gadm_links.nt.bz2 On 2015-08-13 02:43, Rob Atkinson wrote: > Thats my line of thinking > - so it comes down to understanding what types of objects and relations > we need to work with typical spatial data cases (without assuming a > single monolithic data model) and working out the best way to : > a) publish them (governance canonical formats and APIs) > b) discover them > > IMHO this is why we need the intersection of W3C and OGC - OGC > represents a problem domain seeking general solutions so it can do its > spatial parts effectively. W3C is the place such concerns need to be > addressed - and spatial cases are intrinsically multi-dimensional and > have pushed the W3C into poorly charted territory. > > PS - At this stage no one has identified where any of the existing Use > Cases represent a duplicate or conflicting set of requirements. I think > there is another one lurking here for the basic problem of sharing a > mapping between two ontologies - in the hydrology domain its a prime > concern to be able to describe how two different data sources relate to > the same concept in spite of different vocabularies in use. Again - this > is not spatial - but its an unavoidable pattern in spatial data and not > apparently well supported by a general solution. > > > On Thu, 13 Aug 2015 at 10:04 Erik Wilde <dret@berkeley.edu > <mailto:dret@berkeley.edu>> wrote: > > hello rob. > > On 2015-08-07 18:41, Rob Atkinson wrote: > > From the perspective of someone trying to put spatial data on > the web, > > it is largely general issues that are the problem, rather than the > > spatial aspects. So i think the focus on distilling a set of best > > practices for the spatial cases is a sensible start. > > yes, i very much second that. since there seems to be parallel work on > "data on the web" and "spatial data on the web", it would be odd to > replicate anything that's not specifically spatial in nature. > > now, some things may be interesting to mention. for example, when we did > the "tiled feeds" work, we introduced spatial links that would allow > clients to do the equivalent of UI interactions with web-based maps > (zoom in/out, 2d-pan). we never got around to properly register these > link relations, so maybe that would actually be something to look at for > the spatial data group as some spatial groundwork that can serve as a > starting point for all kinds of data. > > > What we get with spatial data is a need to make all the moving parts > > work in concert.. we have issues of identification, dimensionality, > > data models, distributed governance (AAA), data volumes, trust, API > > design and encoding at every juncture in addition to pure spatial > concerns. > > but as you say, mostly these are general data/service concerns and > almost always are orthogonal to spatial issues, right? > > cheers, > > dret. > > -- > erik wilde | mailto:dret@berkeley.edu <mailto:dret@berkeley.edu> - > tel:+1-510-2061079 | > | UC Berkeley - School of Information (ISchool) | > | http://dret.net/netdret http://twitter.com/dret | >
Received on Thursday, 13 August 2015 10:48:59 UTC