W3C home > Mailing lists > Public > public-sdw-wg@w3.org > March 2017

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

From: Jeremy Tandy <jeremy.tandy@gmail.com>
Date: Wed, 08 Mar 2017 17:04:28 +0000
Message-ID: <CADtUq_2-upVuZkvVdG-gHOVjk-QWSRcuAmDsQug0hbyVC9XmiQ@mail.gmail.com>
To: janowicz@ucsb.edu, SDW WG Public List <public-sdw-wg@w3.org>, Ed Parsons <eparsons@google.com>
Thanks Jano. Hopefully you can make the call tonight to engage in the
discussions likely to arise? Jeremy

On Wed, 8 Mar 2017 at 16:59 Krzysztof Janowicz <janowicz@ucsb.edu> wrote:

> Hi,
> See below/inline on samePlaceAs.
> On 03/08/2017 07:30 AM, Jeremy Tandy wrote:
> 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*]
> In almost all cases when we say (geo)spatial we mean spatiotemporal so
> sameEventAs would not seem out of scope.
>    - 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]
> IMHO, there is an important difference between relations that have a
> formal semantics, e.g., owlSameAs, those that don't, and those that are
> 'fuzzy'. If they are fuzzy in a mathematical sense, e.g., by having a
> graded membership, then they have a formal semantic (which is not
> expressible in OWL). If, however, fuzzy simply means 'not exactly defined',
> then my worry is that this will lead to a lot of confusion. What does it
> mean that the physical extents are similar? At what time? What if there are
> no known physical extents, e.g., for Troy, what if there are multiple
> physical extents (as multiple geometries are used for a feature based on
> granularity)? What do we want to learn/infer based on a fuzzy samePlaceAs?
> Can this relation also be used if two places are similar or related?
> As far as the Anne Frank house example is concerned, I would be surprised
> to see an even-driven fire incident entity being defined samePlaceAs as a
> building. Instead, I would say 'ex:fireIncident-56a38 tookPlaceAt <
> https://g.co/kg/m/02s5hd>' or from an event perspective
> 'ex:fireIncident-56a38 involved <https://g.co/kg/m/02s5hd>' or
> ''ex:fireIncident-56a38 covered <https://g.co/kg/m/02s5hd>' (if the space
> is the key issue here), or  any other form of modeling the relation between
> the incidents and places. This seems way more useful to me than saying that
> the fire incident is the same place as the house; after all I want to say
> that the fire happened there not that they are the same.
> Best,
> jano
>    - @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
> --
> 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
Received on Wednesday, 8 March 2017 17:05:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:17:05 UTC