RE: My BP comments..part 3

Hi Jeremy

Many thanks – a sterling effort ! I’m happy with your processing of all my comments.

Re. RH21 –Yes, you are not a mind reader too, I will try and explain better !
BP17 states that the best practice will not be able to be met by some social media channels because they don’t allow structured data. This could read a bit like a dead-end to widespread implementation. Are the “some” a significant portion of the social media channels ? Are we hoping that they will change their rules? If so should we give the developers of those channels a special mention in the Audience section?
Perhaps just re-wording to  “...currently do not allow...” in BP17 will be sufficient to sound more open to change.
And regardless of whether we are hoping for that change, we need to include or refer to a way of handling the unstructured information (already logged as ISSUE-217 and ISSUE-220).

Thanks again – great work, my +1 added to the vote of thanks to all the editors at the last meeting

Rachel


From: Jeremy Tandy [mailto:jeremy.tandy@gmail.com]
Sent: 14 January 2016 14:11
To: Heaven, Rachel E.; Linda van den Brink; p.barnaghi@surrey.ac.uk
Cc: SDW WG Public List
Subject: 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<mailto: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<mailto:reh@bgs.ac.uk>]
Sent: 11 January 2016 17:30
To: Jeremy Tandy; Linda van den Brink; p.barnaghi@surrey.ac.uk<mailto: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]
Sent: 11 January 2016 13:17
To: Jeremy Tandy; Linda van den Brink; p.barnaghi@surrey.ac.uk<mailto: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 ☺
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.
________________________________
________________________________
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.
________________________________