Re: My BP comments

> > 2. I notice the word 'data' is taken as singular. That looks funny 
> to me, but I know there are differences of opinion in that respect. Do 
> W3C or OGC have a recommendation on whether to treat 'data' as a 
> singular or plural noun?
>
> As a native English speaker (OK, that doesn't mean much) "data" looks 
> and sounds correct.
>
> @phila ... any comment from W3C perspective; I know I'm supposed to 
> write in US-english :-)

To the best of my knowledge data is plural, datum is the singular form.

Krzysztof



On 01/12/2016 08:44 AM, Jeremy Tandy wrote:
> Hi Frans. Thanks for your commentary ... responses below.
>
> @lvdbrink ... can you comment on number #4? Also, can you consider a 
> redraft of Section 2 (see points #7 and #8 below) and the opening of 
> section 6.1 (see point #11).
>
> > 1. (already discussed in the teleconference) The introduction or 
> scope section could do with an explanation of how the document relates 
> to the description of the Best Practices deliverable in the charter, 
> especially the first and last bullet points.
>
> See PR 203 <https://github.com/w3c/sdw/pull/203> (already merged) ... 
> hopefully this does the trick.
>
> > 2. I notice the word 'data' is taken as singular. That looks funny 
> to me, but I know there are differences of opinion in that respect. Do 
> W3C or OGC have a recommendation on whether to treat 'data' as a 
> singular or plural noun?
>
> As a native English speaker (OK, that doesn't mean much) "data" looks 
> and sounds correct.
>
> @phila ... any comment from W3C perspective; I know I'm supposed to 
> write in US-english :-)
>
> > 3.In paragraph 1.1 discoverability and accessibility are listed as the 
> key problems. I think interoperability (between different publications 
> of spatial data and between spatial data and other types of data) 
> could be listed as a third main problem; many requirements have to do 
> with interoperability.
>
> Created new issue for discussion: ISSUE 205 
> <https://github.com/w3c/sdw/issues/205>
>
> > 4. section 1.1: problems that are experienced by different groups 
> (commercial operators, geospatial experts, web developers, public 
> sector) are described. I get the impression that those problems are 
> the only or main problems that are experienced by a certain group, but 
> I don't think that is the case. Perhaps the listed problems could be 
> marked as examples? Or the list of problems per group could be expanded?
>
> Indeed- the list of problems is not exhaustive, only illustrative. As 
> an introduction I felt that this reads OK. @lvdbrink - wdyt?
>
> > 5.secion 1:1 “we've adopted a Linked Data approach as the underlying 
> principle of the best practices ”: Such a statement might drive away 
> people that for some reason resist the idea of Linked Data, or in 
> general don't like to have to adopt a new unknown paradigm. It also 
> looks like the WG was biased in identifying best practices (Linked 
> Data or bust). How about stating that upon inspection of requirements 
> and current problems and solutions concepts from the Linked Data 
> paradigm transpired to be most applicable? Or perhaps Linked Data does 
> not need to be mentioned at all.... Requirements like linkability, 
> discoverability and interoperability automatically lead to 
> recommending using HTTP(S) URIs and common semantics.
>
> The WG has agreed on several occasions (including F2F at Nottingham) 
> that we would "adopt the linked data approach" because we feel this is 
> the best way to surface spatial data on the web. Rereading the BP 
> text, I can see how a bias might be taken. I've reworded as follows ...
>
> "Analysis of the requirements derived from scenarios that describe how 
> spatial data is commonly published and used on the Web (as documented 
> in [[UCR]]) indicates that, in contrast to the workings of a typical 
> SDI, the <a href="http://www.w3.org/standards/semanticweb/data">Linked 
> Data</a> approach is most appropriate for publishing and using spatial 
> data on the Web. Linked Data provides a foundation to many of the best 
> practices in this document."
>
> Hope that works for you.
>
> > 6. I think an explanation of the term 'spatial data' should be 
> somewhere very high up in the document (abstract and/or introduction), 
> especially that spatial <> geographic (geographical data is a subset 
> of spatial data)
>
> Agreed. New issue added to the document at beginning of Intro. ISSUE 
> 206 <https://github.com/w3c/sdw/issues/206>
>
> > 7. Section 2: There seems to be overlap with description of user 
> groups in the introduction (1.1). This leads (or could lead) to 
> duplicate information. Why not just mention in the introduction that 
> there are multiple audiences and that they are described in section 2?
>
> Agreed. New issue added. ISSUE 207 <https://github.com/w3c/sdw/issues/207>
>
> > 8. Section 2: I wonder if the three groups that are described cover 
> all audience types. Some more I can think of are [...]
>
> Good point. Added toISSUE 207 
> <https://github.com/w3c/sdw/issues/207> as additional copy for a 
> potential redraft of section 2.
>
> > 9. Section 3: “SDW focuses on exposing the individual; the entities, 
> the SpatialThings, within a spatial dataset ”. That seems to exclude 
> spatial metadata, which is an important subject in SDW.
>
> Agreed. Now, referencing the deliverables from the charter, the Scope 
> states: "The use of metadata to complement spatial data".
>
> > 10.“Can be tested by machines and/or data consumers ”: I consider data 
> consumers to be humans or machines. In fact, it could be used as a 
> useful way of avoiding having to write ''humans or machines' each 
> time. Most best practices should benefit both humans and machines. 
> Only in some cases the distinction is meaningful.
>
> Reworded to: "Compliance with each best practice in this document can 
> be tested by programmatically and/or by human inspection."
>
> > 11.6.1: Is the discussion about features, information resources and real 
> world things really necessary? I find it slightly confusing and I can 
> imagine other will too. Why not just say that if you want spatial data 
> to be referenceable on the web you need to use URIs? Just that makes a 
> lot of sense and could be less confusing.
>
> @lvdbrink has attempted to capture the discussion that occurred during 
> the Sapporo F2F; this discussion certainly had value at the time. I'm 
> wary of reducing the context to the single statement you suggest but 
> agree that it's not currently straight forward. We may also want to 
> talk about the difference between Features (information resources) and 
> Spatial Things (the resources described by the information) and the 
> fact that in the end, the distinction is often not helpful.
>
> I've added a new issue to capture this point. ISSUE 208 
> <https://github.com/w3c/sdw/issues/208>
>
> > 12. Best practice 3: I notice best practices 1 and 2 are phrased as 
> solutions or recommendations . I think it is a good idea to try to do 
> that for all best practices. So instead of “Working with data that 
> lacks globally unique identifiers for entity-level resources” one 
> could write “make spatial relationships explicit”
>
> See ISSUE 193 <https://github.com/w3c/sdw/issues/193> that echoes your 
> sentiment for BP style. That said, your suggested text misses the 
> intended point. There's more content needed for BP3 (and perhaps a 
> major redraft?) as stated in ISSUE 102 
> <https://github.com/w3c/sdw/issues/102> ... the concern is not so much 
> making spatial relationships explicit, but what to do if your data 
> doesn't use URIs. How do you convert from locally scoped identifier to 
> URI?
>
> > 13.I appreciate seeing references to BP requirements from the UCR 
> document. But they are placed in the 'Evidence' section of the BP 
> template now. Is it appropriate to count requirements derived from use 
> cases as evidence of a best practice? I would expect references to use 
> cases and requirements to occur in the 'Why' section of the template. 
> Or in a template section that is especially reserved for requirements, 
> e.g 'Relevant requirements'.
>
> We're following the pro-forma set out by DWBP (for example, see 
> http://w3c.github.io/dwbp/bp.html#identifiersWithinDatasets). I'll 
> admit to not thinking too hard about this so far. I have raised an 
> issue in the WG tracker (ISSUE 36 
> <https://www.w3.org/2015/spatial/track/issues/36>) so that we come 
> back to this discussion post release of FPWD.
>
> > 14. Best practice 8: Is this based on theCRS wiki page 
> <https://www.w3.org/2015/spatial/wiki/Coordinate_Reference_Systems>? 
> It seems that WGS84 is recommended. But that is debatable and could be 
> considered American-centric. European guidelines recommend ETRS89. 
> Also, high-precision is not defined. Also, no mention is made of the 
> need to add temporal data if a CRS with an increasing error with time 
> (like WGS84) is needed. Also no mention is made of how to reconcile 
> local CRSs (as in a building plan) with global CRSs. I think CRSs are 
> one of the areas that do require some extra standardisation efforts 
> outside of this document, but which could be instigated by our working 
> group.
>
> I've added your comment to ISSUE 128 
> <https://github.com/w3c/sdw/issues/128> which is associated with BP 8. 
> We can improve the content post FPWD release.
>
> > 15.BP 10: I would at least recommend to be aware of significant digits.
>
> Added your comment to ISSUE 125 <https://github.com/w3c/sdw/issues/125>
>
> > 16. Appendix C: Why are all UC requirements listed? Why not only the 
> BP requirements? That would make a more compact table.
>
> There were many requirements that were not specifically marked for the 
> BP- but turned out to be related ... so we captured those. Also, while 
> we are working on the BP, it's good to have this full list. Perhaps 
> when we're complete, it would make sense to truncate.
>
> Thanks for all your efforts. Jeremy
>
> On Thu, 7 Jan 2016 at 12:30 Frans Knibbe <frans.knibbe@geodan.nl 
> <mailto:frans.knibbe@geodan.nl>> wrote:
>
>     Hello,
>
>     Following are my comments, after reading the BP draft from top to
>     bottom:
>
>      1. (already discussed in the teleconference) The introduction or
>         scope section could do with an explanation of how the document
>         relates to the description of the Best Practices deliverable
>         in the charter, especially the first and last bullet points.
>      2. I notice the word 'data' is taken as singular. That looks
>         funny to me, but I know there are differences of opinion in
>         that respect. Do W3C or OGC have a recommendation on whether
>         to treat 'data' as a singular or plural noun?
>      3. In paragraph 1.1 discoverability and accessibility are listed
>         as the key problems. I think interoperability (between
>         different publications of spatial data and between spatial
>         data and other types of data) could be listed as a third main
>         problem; many requirements have to do with interoperability.
>      4. section 1.1: problems that are experienced by different groups
>         (commercial operators, geospatial experts, web developers,
>         public sector) are described. I get the impression that those
>         problems are the only or main problems that are experienced by
>         a certain group, but I don't think that is the case. Perhaps
>         the listed problems could be marked as examples? Or the list
>         of problems per group could be expanded?
>      5. secion 1:1 “we've adopted a Linked Data approach as the
>         underlying principle of the best practices ”: Such a statement
>         might drive away people that for some reason resist the idea
>         of Linked Data, or in general don't like to have to adopt a
>         new unknown paradigm. It also looks like the WG was biased in
>         identifying best practices (Linked Data or bust). How about
>         stating that upon inspection of requirements and current
>         problems and solutions concepts from the Linked Data paradigm
>         transpired to be most applicable? Or perhaps Linked Data does
>         not need to be mentioned at all.... Requirements like
>         linkability, discoverability and interoperability
>         automatically lead to recommending using HTTP(S) URIs and
>         common semantics.
>      6. I think an explanation of the term 'spatial data' should be
>         somewhere very high up in the document (abstract and/or
>         introduction), especially that spatial <> geographic
>         (geographical data is a subset of spatial data)
>      7. Section 2: There seems to be overlap with description of user
>         groups in the introduction (1.1). This leads (or could lead)
>         to duplicate information. Why not just mention in the
>         introduction that there are multiple audiences and that they
>         are described in section 2?
>      8. Section 2: I wonder if the three groups that are described
>         cover all audience types. Some more I can think of are
>         A) People working with spatial data that is not geographical
>         (e.g. SVG, CAD, BIM).
>         B) People involved in development of standards that have
>         something to do with spatial data on the web .
>         C) People involved in development of software that can work
>         with spatial data.
>      9. Section 3: “SDW focuses on exposing the individual; the
>         entities, the SpatialThings, within a spatial dataset ”. That
>         seems to exclude spatial metadata, which is an important
>         subject in SDW.
>     10. “Can be tested by machines and/or data consumers ”: I consider
>         data consumers to be humans or machines. In fact, it could be
>         used as a useful way of avoiding having to write ''humans or
>         machines' each time. Most best practices should benefit both
>         humans and machines. Only in some cases the distinction is
>         meaningful.
>     11. 6.1: Is the discussion about features, information resources
>         and real world things really necessary? I find it slightly
>         confusing and I can imagine other will too. Why not just say
>         that if you want spatial data to be referenceable on the web
>         you need to use URIs? Just that makes a lot of sense and could
>         be less confusing.
>     12. Best practice 3: I notice best practices 1 and 2 are phrased
>         as solutions or recommendations . I think it is a good idea to
>         try to do that for all best practices. So instead of “Working
>         with data that lacks globally unique identifiers for
>         entity-level resources” one could write “make spatial
>         relationships explicit”
>     13. I appreciate seeing references to BP requirements from the UCR
>         document. But they are placed in the 'Evidence' section of the
>         BP template now. Is it appropriate to count requirements
>         derived from use cases as evidence of a best practice? I would
>         expect references to use cases and requirements to occur in
>         the 'Why' section of the template. Or in a template section
>         that is especially reserved for requirements, e.g 'Relevant
>         requirements'.
>     14. Best practice 8: Is this based on the CRS wiki page
>         <https://www.w3.org/2015/spatial/wiki/Coordinate_Reference_Systems>?
>         It seems that WGS84 is recommended. But that is debatable and
>         could be considered American-centric. European guidelines
>         recommend ETRS89. Also, high-precision is not defined. Also,
>         no mention is made of the need to add temporal data if a CRS
>         with an increasing error with time (like WGS84) is needed.
>         Also no mention is made of how to reconcile local CRSs (as in
>         a building plan) with global CRSs. I think CRSs are one of the
>         areas that do require some extra standardisation efforts
>         outside of this document, but which could be instigated by our
>         working group.
>     15. BP 10: I would at least recommend to be aware of significant
>         digits.
>     16. Appendix C: Why are all UC requirements listed? Why not only
>         the BP requirements? That would make a more compact table.
>
>
>     Greetings, and keep up the good work!
>
>     Frans
>


-- 
Krzysztof Janowicz

Geography Department, University of California, Santa Barbara
4830 Ellison Hall, Santa Barbara, CA 93106-4060

Email: jano@geog.ucsb.edu
Webpage: http://geog.ucsb.edu/~jano/
Semantic Web Journal: http://www.semantic-web-journal.net