summary of open discussion threads for BP doc as input to plenary call 8-March-2017

Words in *italics* are my comments - that I will repeat tonight during the
meeting.

*Decision: shall we recommend samePlaceAs property? *

(see discussion thread [1])

   - +1 votes from bill, kerry
   - @bill suggests samePlaceAs as _both_ IANA registry entry and in
   schema.org as property for resources of type schema:Place
   - @jano questions the worth of samePlaceAs (recalling a previous failed
   effort to do similar)
      - would we need samePersonAs, sameEventAs etc. [*no - we’re just
      concerned with geospatial here*]
      - the meaning of samePlaceAs is unclear; what does it mean for “two
      places to be the same - or even similar”?
      - [*we’re not suggesting a formal mathematical relationship like for
      topology / spatial predicates nor the devilish owl:sameAs … here, I’m
      thinking of the relationship as a “social” term that humans would apply;
      and be deliberately fuzzy about the implications for geometry …
if we take
      the definition of “Place” from **schema.org* <http://schema.org>* as
      “an entity has a somewhat fixed, physical extent”, then samePlaceAs could
      be used when those “physical extents” are more or less similar,
continuing
      with our examples in Amsterdam, I might want to say that
      “ex:fireIncident-56a38 :samePlaceAs *<https://g.co/kg/m/02s5hd>” -
      meaning that the fire (which has a physical extent) is geographically
      coincident with Anne Frank’s house but without getting hung up
on topology
      relationships that apply to the geometry … and the fire incident is
      definitely _NOT_ owl:sameAs Anne Frank’s house! I want to use samePlaceAs
      for fuzzy matches; where boundary geometries are indistinct or absent]
   - @josh accepts the value of the imprecise geospatial relationship but
   questions the semantics:
      - “There is certainly interest in defining qualitative spatial
      relationships that can be asserted and inferred even if
geometrically they
      are imprecise or complex to calculate” - which is consistent with my aim
      - “‘Place’ is not just a position or even a geometry, but a type of
      feature. samePlaceAs asserts a much more detailed relationship than
      ‘collocated’” (@josh also suggests ‘notSpatiallyDisjoint’ - but
that feels
      way too mathematical)
      - “*collocatedWith*” seems like a good suggestion
   - @roba considers this an “open issue” where there is no best practice;
   pointing to ad-hoc practices (and sometimes downright bad practices such as
   using owl:sameAs to point to the Google Maps interface!)


*Decision: shall we remove BP2 "Provide context required to interpret data
values" [2]? *

(see discussion thread [3])

   - +1 votes from clemens, phila, eparsons, rob
   - sadly, this generic problem is _not_ covered by DWBP
   - Dave Raggett from Web of Things (WoT) WG has been looking at the UoM
   issue; QUDT is too heavyweight and have created a task force to work on
   linked data and semantic processing whose work will include investigation
   into units of measure
   - @roba notes the lack of bp in the wild, but thinks that this concern
   is critical for interoperability. He says UoM (as discussed in a _huge_
   thread summarised here [B]) is a general case; CRS is a specific spatial
   case where units of measurement are used; precision and accuracy are also
   general cases where we really need a spatial case.
   - @roba also indicates that “Hopefully ssn willl present a solution and
   qb4st can offer guidance on how to do it at the set level... but these are
   emergent not bp” - [*but as emergent practices, we can’t advocate them
   in the BP doc*]
   - @jonblower notes that UoM is one of those things that looks simple on
   the surface, but is rather fiendish underneath… (noting a number of
   previous attempts to address this issue; QUDT, UDUNITS, UCUM, JSR-275…)
   - @josh wonders if we missed the “spatial” concern with this issue?
      - Context is a vague term; UoM is very general; … should we talk
      about the _spatial context_ of other feature properties or data values?
      e.g. population value refers to an administrative area; a river
has a flow
      property based on a measurement or calculation at a particular point
      - … so the recommended practice would be to “*provide metadata that
      clarifies the spatial significance of non-spatial feature properties*”
      - [*??? This was not the original intent - I’m not sure where this
      would fit in the current BP document … it _might_ be a topic that I could
      cover in BP14 when we discuss Linking ???*]
   - [*editor’s proposal is to identify “open interoperability issues”
   where there is no evidence of  [best] practice in the Conclusions section
   of the BP doc - to be written in the next sprint. See the detailed plan [A]
   where we’re compiling a list … I think the conclusions from the UoM
   discussion thread are a good start in describing the problem*]
   - [*does anyone want to volunteer to help Dave Raggett in the WoT WG?*]


*Decision: shall we remove BP12 "Include search capability in your data
access API" [4] because we've said enough about this in BP11 "convenience
APIs"? *

(see discussion thread [5])

   - +1 votes from jtandy, eparsons, linda, andrea, scott, matthew perry,
   roba


*Decision: shall we remove BP13 "Provide subsets for large spatial
datasets" [6] because DWBP already says enough? *

(see discussion thread [7])

   - +1 votes from jtandy, linda, andrea
   - @jtandy suggests:
      - adding the URI-template / HTTP proxy approach (from BP13) to BP11
      - expanding the existing BP11 example about Environment Agency
      Bathing Water Quality API to provide more details about the
Linked Data API
      that uses URI templates to provide RESTful access toSPARQL
queries thereby
      taking away from the user the challenge of writing generalised SPARQL
      queries and understanding the underpinning data model
      - in BP11 it would be worth recommending that the relationship
      between complete resource and subset should be asserted in API responses
      that provide subsets
   - @clemens agrees
      - “Regarding the relationship between the subset and the source, I
      agree that it would be good practice to be clear about the relationship”
      and provides some examples



[1]: https://lists.w3.org/Archives/Public/public-sdw-wg/2017Feb/0532.html

[2]: http://w3c.github.io/sdw/bp/#provide-context

[3]: https://lists.w3.org/Archives/Public/public-sdw-wg/2017Feb/0531.html

[4]: http://w3c.github.io/sdw/bp/#include-search-api

[5]: https://lists.w3.org/Archives/Public/public-sdw-wg/2017Mar/0027.html

[6]: http://w3c.github.io/sdw/bp/#ids-for-chunks

[7]: https://lists.w3.org/Archives/Public/public-sdw-wg/2017Mar/0026.html


[A]:
https://www.w3.org/2015/spatial/wiki/Detailed_planning_BP_document#Editorial_2

[B]: https://lists.w3.org/Archives/Public/public-sdw-wg/2016Jul/0160.html