- From: Jeremy Tandy <jeremy.tandy@gmail.com>
- Date: Thu, 14 Jan 2016 11:44:40 +0000
- To: "Heaven, Rachel E." <reh@bgs.ac.uk>, Linda van den Brink <l.vandenbrink@geonovum.nl>, "p.barnaghi@surrey.ac.uk" <p.barnaghi@surrey.ac.uk>
- Cc: SDW WG Public List <public-sdw-wg@w3.org>
- Message-ID: <CADtUq_0P6PC0d98D62YTPdHk0SHy4kAZjV-DXMwFwu=zp1Dm8w@mail.gmail.com>
Hi Rachel- Tranche 2 of comments now processed (albeit they missed the cut for FPWD). RH27, RH28, RH29 & RH31 ... this text got changed in a previous edit. RH30 ... included the need to define "thematic" in ISSUE 212 <https://github.com/w3c/sdw/issues/212> RH33 ... DWBP BP 11 talks about more than just path structures; agree that we don't want to be specific about just "creation" of persistent URIs, so I reworded without the qualification: "For guidance about persistent URIs, read [...]" RH34 ... the Linked Data Cloud is more a conceptual entity; I can't give you a URI and say "go look there". Appendix B ( http://w3c.github.io/sdw/bp/#auth-id-sources) is the beginning of our effort to give people places to look. RH41 ... ISSUE 102 <https://github.com/w3c/sdw/issues/102> is correctly placed; BP3 needs quite some work at the moment ... as outlined in the ISSUE. RH44 ... need for definition of MECE in glossary added to ISSUE 212 <https://github.com/w3c/sdw/issues/212> Jeremy On Mon, 11 Jan 2016 at 17:29 Heaven, Rachel E. <reh@bgs.ac.uk> wrote: > 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 > *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. > ------------------------------ >
Received on Thursday, 14 January 2016 11:45:22 UTC