Re: Choosing the right format & vocabulary for spatial data

Hi Jeremy,

Because of the problem I am having with fragment identifiers I am not sure
which Best Practice you mean exactly. Do you mean the "How to describe
geometry" best practice? BP 7 is titled "Reuse existing (authoritative)
identifiers when available" in the version that I am looking at.

Anyway, here are some thoughts:

   1. A decision tree forces an order in questions to be answered, and can
   block certain avenues of useful thought. I don't know it that is helpful in
   this case. I certainly makes it more difficult for the BP editors to
   determine the order of questions in the tree. How about presenting the
   questions leading to a decision on how to publish spatial data as an
   unordered list, to which readers can assign their own weights?
   2. I would try to avoid having data publishers make assumptions on how
   data will be used (e.g.  their target community). This keeps the silo based
   thinking intact. I would like to see recommendations that are good no
   matter how and by whom the data will be consumed.
   3. The question "do you need a CRS other than WGS84?" seems to encourage
   the use of WGS84. I think the current proliferation of WGS84 on the web is
   not a good practice. The use of WGS84 should sooner be discouraged than
   4. The fact is that for some issues good solutions don't really exist
   yet. Making that clear, and pointing at initiatives that could help in the
   future (like a proposed new version of GeoSPARQL) could be a useful
   thing to do in the BP.


On 25 July 2016 at 13:14, Jeremy Tandy <> wrote:

> All.
> We Best Practice editors are trying to figure out how we should write the
> Best Practice(s) relating to data format and vocabulary ... currently
> that's SDWBP 7 [1].
> As agreed at our last BP sub-group call, we're restructuring the SDW BP
> doc based on the DWBP document [3].
> Data formats are described in DWBP 13 [4] and data vocabularies in DWBP 15
> [5]. Both of these best practices provide generic advice. We want to
> provide some actionable advice for how to chose the right data format
> and/or vocabulary for spatial data.
> We also need to make this guidance prescriptive ... so we need to tell
> people what their choices are based around today's options.
> We wonder if it's possible to make a single 'decision tree' that readers
> to could use to help them make the choice?
> The kind of questions that might be used in such a decision tree include:
> * does the data format support Web linking (see RFC5988 [6]) ... this is a
> _MUST_
> * what dimensionality (of SpatialThings) is needed?
> * what types of geometry are needed (e.g. polygons w holes, relative
> positioning)?
> * do you need a CRS other than WGS84?
> * what technical environments / tool chains do your target community
> predominately use?
> ... etc.
> Choosing the vocabulary (e.g. RDF vocab / OWL ontology) only makes sense
> if an RDF-serialisation (RDF-XML, N-Triples, JSON-LD, TTL etc.) is used
> ... but JSON-LD gives the opportunity to blur the boundaries with other
> formats and _still_ use RDF.
> Similarly, CSV as "tabular data" can be converted to JSON [7] or RDF [8]
> ...
> I'm not sure what the 'decision tree' should look like- or even if this is
> the correct approach.
> Furthermore, should we be referencing the emerging GeoSPARQL 1.1 ontology
> being developed by Josh [9] ... as this aims to add more [geometry]
> serialisations that are the vocabulary more widely usable.
> I'm also mindful that often people use a hybrid approach mixing best of
> breed technologies for RDF and spatial ...
> ***Your thoughts please***
> As an implementer, what questions are important to you when choosing the
> format? How would you structure this best practice? Is this even achievable?
> Many thanks, Jeremy
> [1]:
> [2]:
> [3]:
> [4]:
> [5]:
> [6]:
> [7]:
> [8]:
> [9]:
> L
> <>
> <>
> <>

Received on Wednesday, 27 July 2016 12:04:52 UTC