Re: My BP comments..part 3

Hi - the last tranche is now processed. Very many thanks for the detailed
review and well constructed comments.

RH55 (relating to BP11) ...
Rather than take your suggested text, I reworded the outcome so that it
reflected an end result (for the data user) rather than a means to that end:

              <p>By default, data users are provided with the most recent
version of information about an identified resource.</p>
              <p>Data users are able to refer to the the information about
an identified resource as it was at a given time.</p>
              <p>Data users can browse through versions of the information
about an identified resource that reflect how the resource changed over
time.</p>

RH58 ... I've created a new ISSUE for this- ISSUE 214
<https://github.com/w3c/sdw/issues/214>

RH63 ... I've created a new ISSUE (#215
<https://github.com/w3c/sdw/issues/215>) to remind us to add details of
spatial relationships in the IANA Link relations register into the doc.

RH64 ... I've created a new ISSUE (#216
<https://github.com/w3c/sdw/issues/216>) to discuss scope relating to BP15

RH72 ... I've created a new ISSUE (#217
<https://github.com/w3c/sdw/issues/217>) for this concern: Are we missing a
BP describing how to discover and annotate information within unstructured
resources?

RH74 ... I've avoided mentioning specific standards in the possible
approach (e.g. Geo-DCAT-AP); I thought that the examples would be
sufficient. As the BP doc evolves I think it will become obvious whether or
not I've got the right approach :-) ... No change made to the BP doc at
this stage.

RH78 ... added the comment to the issue covering Glossary contents (#212
<https://github.com/w3c/sdw/issues/212>)

Thanks! Jeremy





On Tue, 12 Jan 2016 at 12:26 Heaven, Rachel E. <reh@bgs.ac.uk> wrote:

> Final set of comments...
>
> Again, these are mostly typos and minor rewordings, nothing major that
> would make me object to publication as a first draft.
>
>
>
> RH56, RH58, RH59, RH62, RH64, RH72 below are some of the more open
> questions.
>
>
>
> Thanks again, Rachel
>
>
>
> ------
>
> RH47, RH48 – not used
>
>
>
> RH49
>
> 6.2.1 (geo)spatial data
>
> See previous comment RH5, update title
>
>
>
> RH50
>
> BP7 Possible Approach to Implementation
>
> s/conventient/convenient
>
>
>
> RH51
>
> BP7 Possible Approach to Implementation
>
> s/Choose the right format and deciding on when/Choose the right format and
> decide on when
>
>
>
> RH52
>
> BP8 Possible Approach to Implementation
>
> "e.g. Australia moves by 7cm per year". Kerry commented on this needing
> clarification, though I think she misunderstood the intention. Suggest
> replacing with "e.g. Australia sits on a tectonic plate that is moving 7cm
> per year relative to the African plate"
>
>
>
> RH53
>
> BP8 Possible Approach to Implementation
>
> "...considering use of a dynamic datum" citation for this could be
>
>
> http://www.crcsi.com.au/assets/Resources/Stakeholder-Requirements-for-Modernising-Australias-Geocentric-Datum.pdf
>
>
>
> RH54
>
> BP9 Why
>
> s/In some cases it is needed/In some cases it is necessary
>
>
>
> RH55
>
> BP11 Intended Outcome
>
> "..tracking of the changes and accessing the most up-to-date properties
> data" suggest change to
>
> "..tracking of the changes and accessing and/or referencing the most up to
> date version and any previous version of the properties data"
>
>
>
> RH56
>
> BP12 Why
>
> There is nothing to stop publishers describing their spatial things
> multiple times using different vocabularies, thereby maximising the
> potential for interoperability and letting the consumers choose which is
> the most useful. The wording here makes it seem as if only one must be
> chosen –  is that intentional ? If so, what is the reasoning ?
>
>
>
> RH57
>
> BP12 Why
>
> s/adapted/adopted
>
>
>
> RH58
>
> BP12 Possible Approach to Implementation
>
> "This best practice helps you decide which vocabulary to use" - I don't
> think it helps you to decide as it stands, it just tells you to decide.
>
> The list of mappings as suggested in ISSUE-38 would be very useful.
>
>
>
> RH59
>
> BP12 Possible Approach to Implementation
>
> "For this it is required to:" suggest change to "The steps required to
> choose the best vocabularies are:"
>
> (bullet points could be interpreted as different options rather than
> sequential steps otherwise)
>
>
>
> RH60
>
> BP12 Possible Approach to Implementation
>
> "They should have URIs in which when you look those up you can see what
> they mean. "
>
> suggest change to
>
> "They should have URIs that return human readable definitions when looked
> up".
>
>
>
> RH61
>
> BP12 Possible Approach to Implementation
>
> "There are different vocabularies....or an actionable selection list" -
> this paragraph seems to be redundant/repetition
>
>
>
> RH62
>
> BP13 Why
>
> "near is contextual - it depends if you're walking or driving" bullet
> point  - at first read this seems to be saying it would be better to know
> the actual distance rather than a context-dependant statement of "near",
> but perhaps it's referring to network distance?
>
> i.e. should be
>
> "near is contextual - a straight line distance calculated by simple
> geometric analysis does not take into account the mode and speed of travel
> or available pathways."
>
>
>
> RH63
>
> BP13 Possible Approach to Implementation
>
> Can we indicate which of these are already in the IANA registry or not ?
>
> Could this group do the work of registering or creating properties for the
> missing ones that we can see would be useful e.g. samePlaceAs
>
>
>
> RH64
>
> BP15
>
> Is this only about processing of the spatial aspects of sensor data ?
> Perhaps that needs to be made clearer in the title and the content, and to
> state that processing information about any of the non-spatial aspects is
> out of scope.
>
>
>
> RH65
>
> BP17 Why
>
> ". Crowd-sourced data should be published as structured data with explicit
> semantics and also links to other related data (wherever applicable)."
>
> suggest change to
>
> ", however, when possible and applicable, crowd-sourced data should be
> published as structured data with explicit semantics and also links to
> other related data."
>
>
>
> RH66
>
> BP17 Possible Approach to Implementation
>
> s/allows processing and intepreting it/allows it to be processed and
> interpreted
>
>
>
> RH67
>
> BP18 Intended Outcome
>
> s/sensory/sensor
>
>
>
> RH68
>
> 6.3 NOTE (second one)
>
> s/create the links that the use those/create the links that use those
>
>
>
> RH69
>
> BP19 Possible Approach to Implementation
>
> Not clear if the bullet points are alternative options or sequential steps
>
>
>
> RH70
>
> BP23 Why
>
> s/resources with with spatial extent...can often inferred /resources with
> spatial extent...can often be inferred
>
>
>
> RH71
>
> BP23 Intended Outcome
>
> Add to the cautionary NOTE that owl:sameAs may not always have been used
> in the strictest sense
>
>
>
> RH72
>
> BP24 Why
>
> "Spatial data is typically well structured" - but lots of unstructured
> data too. It would be good to see another best practice on how to discover
> and possibly annotate information (so it can be discovered and linked into)
> within unstructured resources.
>
>
>
> RH73
>
> BP26 Why
>
> s/catalog services that offer query/catalog services that offer queries
>
>
>
> RH74
>
> BP26 Possible Approach to Implementation
>
> Should we mention relevant metadata standards here?
>
>
>
> RH75
>
> 6.5
>
> Expand API in title (as previous comment RH3).
>
>
>
> RH76
>
> EXAMPLE 30
>
> "certain speed threshold is exceeded", I think this should be the opposite
> sense: "certain speed threshold is not reached"
>
>
>
> RH77
>
> ANNEX B
>
> s/are available and how they can be accessed, currently/are available, and
> how they can be accessed, currently
>
> (adding comma)
>
>
>
> RH78
>
> Glossary
>
> Few items to be added as already mentioned in previous comments. Perhaps
> GIS and SDI definitions could be updated to indicate the relation between
> them (e.g. GIS is usually a component part of an SDI)
>
>
>
> ---
>
> The End!
>
>
>
> *From:* Heaven, Rachel E. [mailto:reh@bgs.ac.uk]
> *Sent:* 11 January 2016 17:30
> *To:* Jeremy Tandy; Linda van den Brink; p.barnaghi@surrey.ac.uk
> *Cc:* SDW WG Public List
> *Subject:* My BP comments..part 2
>
>
>
> Some more comments... (RH36 and RH41 most important ones here)
>
> Rachel
>
>
>
> RH27
>
> 3.Scope
>
> In agreement with Ed’s comment: “typically well structured and describes”
> could be down-graded to “often well structured, but includes locations
> identified in unstructured text, and describes...”
>
> RH28
>
> 3.Scope paragraph 2
>
> “elicit the required features” – suggest change to “elicit the
> requirements” to avoid using the overloaded term feature
>
> RH29
>
> 3. Scope
>
> Bullet point “To discuss who has authority....” change to “Discussion
> regarding who has authority..” to keep consistent grammar with the other
> bullet points
>
> RH30
>
> 3. Scope. (and several other places)
>
> “thematic” – add to glossary
>
> RH31
>
> 3. Scope
>
> “Can be tested by machines...”  suggest change to “Can be conformance
> tested by machines...”
>
> RH32
>
> BP1 Possible Approach to Implementation
>
> “..much like how Twitter’s...” is probably technically correct but sounds
> a bit jarring to me; “..in the way that Twitter’s...” reads more easily.
> Feel free to ignore this comment for being way too pernickety.
>
> RH33
>
> BP1 Possible Approach to Implementation
>
> I think we need to mention designing a good path structure for URIs too,
> which is also in the DWBP document
>
> “For guidance about how to create persistent URIs...” change to “For
> guidance about how to design path structures for persistent URIs...”
>
> RH34
>
> BP2 Possible Approach to Implementation
>
> Should we advise people to look on the Linked Data Cloud to find sources
> of existing identifiers?
>
> RH35
>
> BP2
>
> Refer to BP4 for advise on identifiers for authoritative resources that
> change over time
>
> RH36
>
> BP3 title
>
> This title doesn’t give an easy clue to what it’s actually about. The
> subtitle  “Spatial reconciliation across datasets” is fine.
>
> What about something like
>
> “Determine spatial correlation between objects in different datasets and
> express as links”
>
> RH37
>
> BP3 Why
>
> “.. in a context where spatial functions are not available, it is a good
> idea ...”
>
> suggest expanding to
>
> “.. in a context where spatial functions are not available, or explicit
> geometry is not available, it is a good idea ...”
>
> RH38
>
> BP3 Why
>
> “There is also danger in relying on spatial correlation alone;...”
>
> suggest change to
>
> “There is also danger in relying on spatial correlation alone,
> particularly if this is only handled in 2D and ignores any (explicit or
> undeclared) height and time component;...”
>
> RH39
>
> BP3 Possible Approach to Implementation
>
> “If the spatial datasets you want to reconcile are managed in a Geographic
> Information System (GIS), you can use the GIS spatial functions to find
> related spatial things.”
>
> Suggest expanding to
>
> “If the spatial datasets you want to reconcile are managed in a Geographic
> Information System (GIS) or a spatial database, you can use the spatial
> functions to find related spatial things.”
>
> RH40
>
> BP3
>
> If RH38 is implemented, suggest adding “spatial database” to glossary e.g.
> definition like “A spatial database, or geodatabase is a database that is
> optimized to store and query data that represents objects defined in a
> geometric space. Most spatial databases allow representation of simple
> geometric objects such as points, lines and polygons and provide functions
> to determine spatial relationships (overlaps, touches etc)”
>
> RH41
>
> BP3
>
> ISSUE-102  - is this in the wrong place in the document ?
>
> RH42
>
> BP4 Possible Approach to Implementation
>
> “A lake that became smaller or bigger is generally still the same lake.
>
> If your resources are versioned, a good solution is to provide a
> canonical, versionless URI for your resource, as well as date-stamped
> versions. “
>
> Suggest expanding to
>
> “A lake that becomes smaller or bigger is generally still the same lake,
> but some links (e.g. from statistical datasets, or related to the boundary
> of the lake) need to target a specific version of its geometry.
>
> If your resources are versioned, a good solution is to provide a
> canonical, versionless URI for your resource, as well as date-stamped
> versions. You should also include information on the update frequency in
> the dataset metadata, see <BP26>”
>
> RH43
>
> BP5 Possible Approach to Implementation
>
> Needs a mention of how to handle MECE sets, e.g.
>
> “Provide metadata to indicate how a given subset resource is related to
> the original large dataset” append “, with reference to an identified
> Mutually Exclusive Collectively Exhaustive (MECE) collection where
> appropriate”.
>
> Probably need further content and examples on this.
>
> RH44
>
> If RH43 implemented: add MECE to glossary.
>
> RH45
>
> BP5 NOTE
>
> Correction to singular/plural sense
>
> s/Web service URLs in general/A Web service URL in general
>
> RH46
>
> 6.2 Expressing spatial data
>
> s/And we do the mapping/We also do the mapping
>
>
>
>
>
> *From:* Heaven, Rachel E. [mailto:reh@bgs.ac.uk <reh@bgs.ac.uk>]
> *Sent:* 11 January 2016 13:17
> *To:* Jeremy Tandy; Linda van den Brink; p.barnaghi@surrey.ac.uk
> *Cc:* Frans Knibbe; SDW WG Public List
> *Subject:* My BP comments..part 1
>
>
>
> Dear BP editors
>
>
>
> Many thanks for the great work you have put into this. I too have read the
> draft from top to bottom, made lots of pencil notes. On the whole they are
> just typos and for ease of reading, as someone coming to this document
> relatively afresh. BP 15 is the only one that I question is in scope, but
> that comment will be in a later email.
>
>
>
> Meanwhile, here is the first tranche of comments (numbered RHn; they get
> less dense later on through the document!). If you want me to process the
> simple changes in github myself please let me know and I’ll try to get to
> grips with it (something I really should do at some point anyway...). I
> have today and tomorrow free...
>
>
>
> Best wishes,
>
> Rachel
>
>
>
>
>
> RH1
>
> Table of Contents 1.2 Expand "SDI" (in addition to being expanded when
> first used in the main text. Someone browsing the contents to see if they
> want to bother reading the document could be put off by a load of acronyms)
>
> RH2
>
> Table of Contents 6.3 Linking spatial data
>
> s/Linking Spatial Data/Linking spatial data      (change to lower case for
> consistency)
>
> RH3
>
> Table of Contents 6.5 expand "API"  (reason as in RH1)
>
> RH4
>
> Table of Contents Annex C:  s/best practices/Best Practices   (upper case
> for consistency)
>
> RH5
>
> Table of Contents 6.2.1 (geo)spatial data
>
> Not completely clear from this title if this section is just concerned
> with geospatial data. If it is, then suggest change title to "geographic
> spatial (geospatial) data", and do we need a separate section to deal with
> spatial data that is not geographic ?
>
> OR, is this section intended to cover non-geographic cases too, in which
> case the title could be "geographic and non-geographic spatial data", and
> some examples of the latter need to be added.
>
> RH6
>
> Table of Contents 6.2.3 Temporal data
>
> Suggest changing this title to "Temporal component of spatial data" or
> "Spatio-Temporal data" so the relevance to the best practices is clearer
> when eye-balling the table of contents.
>
> RH7
>
> Table of Contents 6.2.4 Sensor and observation data
>
> Suggest changing this title to "Spatial data from sensors and
> observations" so the relevance to the best practices is clearer when
> eye-balling the table of contents.
>
> RH8
>
> 1.1. General Introduction
>
> We need to introduce the term “geospatial data” here. (see also Frans
> point 6)
>
> e.g. in paragraph 1
>
> “Spatial data, or data related to a location is what this Best Practice
> document is all about. We use the term geospatial if the location is
> geographic.”
>
> RH9
>
> 1.1 Suggest merging para 2 to 3 to remove repetition, and change
> “geospatial data” to “spatial data”
>
> "It's not that there is a lack of spatial data on the Web; the maps,
> satellite and street level images offered by search engines are familiar
> and there are many more nice examples of spatial data being used in Web
> applications.  However, the data that has been published is difficult to
> find and often problematic to access for non-specialist users. The key
> problems we are trying to solve in this document are discoverability and
> accessibility, and our overarching goal is to bring publishing spatial data
> into the web mainstream as a mechanism for solving these twin problems.”
>
> RH10
>
> 1.1 s/Commercial operators, including search engines operators/ Commercial
> operators, including search engine operators
>
> RH11
>
> 1.1 NOTE: s/technolgies/ technologies
>
> RH12
>
> 1.1 NOTE: Can we make any statement about the state of play of standards
> for non-geographic spatial data ?
>
> RH13
>
> 1.1 “For Web developers..” paragraph, can we add a mention of the source
> of the location data e.g.
>
> “But Web developers are increasingly creating and using data related to
> locations, e.g. obtained from GPS enabled mobile devices and sensors,...”
>
> RH14
>
> 1.1 s/partiipants/participants
>
> RH15
>
> 1.1 “ The public sector...” paragraph, I think a paragraph break is
> missing here i.e. “by the European Union. <p/> Spatial data often”
>
> RH16
>
> 1.1 Can we add a glossary or external link for Internet of Things (or add
> description to the NOTE suggested below in RH17).
>
> RH17
>
> 1.1 “The best practices we describe in this document....”  Can we add a
> NOTE section after this paragraph for people not familiar with linked data,
> similar to the one above, e.g. (though feel free to improve on this!).
> Could combine with Frans point 5 to explain why we have adopted this
> approach.
>
> “NOTE
>
> If you are not a web developer, Linked Data may be one of those buzz words
> that doesn’t mean much to you. Essentially it is about publishing URIs to
> represent bite size pieces of information or real world things, and
> publishing well described relationships between pairs of URIs, all in a way
> that is machine readable thereby enabling data from different sources to be
> connected and queried.”
>
> RH18
>
> 1.1 “How to publish environmental monitoring data, such as sensor output,
> with sufficient context to unambiguously interpret the values.” This bullet
> point is very specific compared to the others and comes a bit out of the
> blue. This document should only be concerned with spatial attributes, so
> perhaps it should be something like “How to publish data from sensors and
> observations with sufficient context to unambiguously interpret the spatial
> component”.
>
> RH19 (duplicate with RH1)
>
> 1.2 Difference between spatial data on the Web and current SDI practice
>
> Expand "SDI" in the title, as RH1
>
> RH20
>
> 2.Audience
>
> As Frans point 7, repetition of the multiple groups of users. Suggest
> simplifying the first paragraph to
>
> “The audience is the broadest community of Web users possible, three
> important groups of which are described below. Application and tool
> builders addressing the needs of the mass consumer market should find value
> and guidance in the document.”
>
> RH21
>
> 2.Audience and BP17 – it seems important to engage developers of social
> media tools with these best practices, to enable citizen authored
> information to be properly “spatialised” at source.  Can we say anything
> about how that might happen ?
>
> RH22
>
> 2.1 Geospatial experts without Web knowledge
>
> Perhaps change title to “Geospatial experts (not necessarily with Web
> knowledge)” or something similar. Some do have both skillsets J
>
> RH23
>
> 2.1 In this section, these users are described according to their role as
> a publisher of data, whereas in the introduction their role is “find and
> use data”. Can these two sections be made consistent, or perhaps have a
> matrix of expertise group (geospatial OR web) crossed with their role
> (publisher OR consumer OR ?custodian). Relates to ISSUE-190.
>
> RH24
>
> 2.2 Web developers without geospatial knowledge
>
> Perhaps change title to “Web developers (not necessarily with geospatial
> knowledge)” or something similar, consistent with RH21
>
> RH25
>
> 2.2 Web developers without geospatial knowledge
>
> This section has a distinct change in voice (lifted from an old email from
> Ed I think?). For consistency suggest reword to
>
> “These are people who just want to work with (find, publish, use) spatial
> data on the Web and are not necessarily experts in geospatial technology.
> Spatial data is just one facet of the information space they work with, and
> they don’t want to be required to have up front knowledge. These web
> developers will be writing Web-based applications that use spatial data
> directly, but also writing applications that help non-technical users
> publish spatial information on the Web, for example, people who are
> publishing information about their village fête or local festival; they are
> just creating content, which happens to have a spatial aspect.”
>
> RH26
>
> 2.3 Content publishers
>
> re ISSUE-190 whether we need this category, perhaps we rename to Spatial
> Data Custodian and text is "These are people who are responsible for
> acquiring, managing and publishing spatial data. They want to know how to
> publish their spatial data so that it can be used to its full potential, by
> using the skills of the geospatial experts and web developers.
>
>
>
>
>
> ...more later...
>
>
> ------------------------------
>
> This message (and any attachments) is for the recipient only. NERC is
> subject to the Freedom of Information Act 2000 and the contents of this
> email and any reply you make may be disclosed by NERC unless it is exempt
> from release under the Act. Any material supplied to NERC may be stored in
> an electronic records management system.
> ------------------------------
> ------------------------------
>
> This message (and any attachments) is for the recipient only. NERC is
> subject to the Freedom of Information Act 2000 and the contents of this
> email and any reply you make may be disclosed by NERC unless it is exempt
> from release under the Act. Any material supplied to NERC may be stored in
> an electronic records management system.
> ------------------------------
> ------------------------------
> This message (and any attachments) is for the recipient only. NERC is
> subject to the Freedom of Information Act 2000 and the contents of this
> email and any reply you make may be disclosed by NERC unless it is exempt
> from release under the Act. Any material supplied to NERC may be stored in
> an electronic records management system.
> ------------------------------
>