- From: Krzysztof Janowicz <janowicz@ucsb.edu>
- Date: Wed, 8 Mar 2017 08:58:49 -0800
- To: Jeremy Tandy <jeremy.tandy@gmail.com>, SDW WG Public List <public-sdw-wg@w3.org>, Ed Parsons <eparsons@google.com>
- Message-ID: <ddb1393c-4179-0369-de29-7584c1bc2b62@ucsb.edu>
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 <http://schema.org> as property for resources of type > schema:Place > * @jano questions the worth of samePlaceAs (recalling a previous > failed effort to do similar) > o 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. > o the meaning of samePlaceAs is unclear; what does it mean for > “two places to be the same - or even similar”? > o [/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: > o “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 > o “‘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) > o “*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? > o 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 > o … so the recommended practice would be to “*provide metadata > that clarifies the spatial significance of non-spatial feature > properties*” > o [/??? 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: > o adding the URI-template / HTTP proxy approach (from BP13) to BP11 > o 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 > o 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 > o “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:15:18 UTC