BP comments

Many thanks to the editors for all their hard work on the best practice
draft - it's shaping up very nicely I think.

I have some comments below. I'm sorry to submit these at the last minute
and appreciate they will take time to review and (perhaps) act on.  I don't
think any of them are important enough to delay moving to First Public
Working Draft, but may be worth addressing at some point.

Some are just typos which could probably be easily fixed.

Anyway - thanks eds and talk to you tomorrow on the call

=============

Section 1.1 Note box
"technolgies" should be "technologies"

Section 1.1
"we've adopted a Linked Data approach"
I wonder if we should introduce this a little, to explain how to share
spatial data effectively on the web, we need to build on the mechanisms and
strengths of the web, which means allowing people to link directly to
entities and data points of interest, and use HTTP to deliver information
about those things - which leads us to use the Linked Data approach.

Or something like that - to justify the choice of approach and so avoid
potential criticism that it was chosen for dogmatic rather than pragmatic
reasons.

In Best Practice 2, there is a reference to http://dbpedia.org/page/Utrecht
which is the 'information resource', with corresponding
http://dbpedia.org/resource/Utrecht as NIR.  Did you mean to use the
'resource' version?

Best Practice 5, "Why" section
"conveiently" should be "conveniently"

BP5 NOTE
It could be useful to explain what is meant by a "Web service URL" and how
it differs from another URL, and how to recognise one when you see it! - in
one sense, it's just another URL that you can GET and receive something
back.  The point about persistence is the important one, hence avoiding
URLs that are likely to change if the chosen technology changes

6.2
"The primary use case for this is you already have a database of assets and
you want to publish the semantics of this data."  It's not clear to me what
this means - maybe you could express it differently or refer to an
example?  I think it's the use of 'semantics' here and in the following
couple of sentences that I think is open to different interpretations and
could perhaps be explained further.  Also "asset" is a heavily used word
and an alternative might be clearer.

Does this mean (guessing) "you have a database about SpatialThings and you
want to publish precise information about their attributes and how they are
inter-related" ? (or something like that).

Instead of "The spatial thing itself as well as its spatial properties have
semantics. There are several vocabularies which cover spatial things and
spatial properties.", how about something like:

"The attributes of a spatial thing can be described using existing
vocabularies, where each term has a published definition. If you want to
describe an aspect of the thing that matches that definition then it is
good practice to use a term from an established widely used vocabulary. If
you can't find a suitable existing vocabulary term, you should create your
own, and publish a clear definition for the new term".

Issue 37 - perhaps it is more natural to allow a SpatialThing to have
either a precise spatial extent, or a fuzzy spatial extent, or an undefined
spatial extent, and create a subclass of it for the subset of things that
do have a clearly defined spatial extent.

BP7, "Intended Outcome" section
"conventient" should be "convenient"

BP7, Possible approach to implementation

"in some cases, geometry can be 95% of the total data size" - other
percentages may apply! Maybe - "often the geometric data is a large
percentage of the total data size"

The choice of how to represent geometry might depend most on the tools you
expect your audience to have easy access to.  Because different user groups
have different favourite tools, maybe good advice would be to offer as many
representations as you can - balancing that against the cost of the
additional storage or additional processing if converting on-the-fly.  I
don't think binary formats are inherently less useful than text formats in
this regard - most people are going to need some tooling to process
geometry data, whatever choice you make.

Issue-121: In my opinion, this is a useful BP to include

BP17
How does crowd-sourced data differ from other data? (I'm not saying it
doesn't! - just a genuine question on what considerations are specific to
data generated in this way, which might inform how it can best be dealt
with)

BP18, Possible Approach to Implementation
The metadata items here probably apply to all kinds of dataset, so perhaps
suggestions like these could be moved to a more general metadata section -
or maybe even just refer to something on DWBP or elsewhere?

BP20, Why
I think we probably need to define and explain what is meant in practice by
'formal and meaningful semantics'

There is some overlap between all the linking BPs (19-23).  No harm in
separating out different aspects of good linking practice, but we should be
careful to avoid repetition and could perhaps start with some sign-posting
of how the recommendations are organised.  At the moment there is a
tendency to think "haven't I just read that in the previous section"