- From: Jeremy Tandy <jeremy.tandy@gmail.com>
- Date: Wed, 08 Mar 2017 17:04:28 +0000
- To: janowicz@ucsb.edu, SDW WG Public List <public-sdw-wg@w3.org>, Ed Parsons <eparsons@google.com>
- Message-ID: <CADtUq_2-upVuZkvVdG-gHOVjk-QWSRcuAmDsQug0hbyVC9XmiQ@mail.gmail.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