See also: IRC log
<jtandy> topic
<scribe> scribe: Linda
jtandy: notes we don't have quorum so can't resolve anything
<silence>
jtandy: can we three have useful discussion on the topics that are on the agenda?
Frans: useful question. We could try to agree on something and present it to the larger group.
jtandy: ok
frans: the question is: what can we summarize and put in the BP
<jtandy> to quote Frans: Is there really a need to have a third concept (Feature)? If the world could manage with two core concepts, that would be preferable, wouldn't it?
<jtandy> so that leaves spatial things and geometry
frans: yes these two are enough,
I think there was consensus about this. We should describe
these two in the BP.
... definitions are missing
<jtandy> UML models for ISO TC 211 are free here: http://www.isotc211.org/hmmg/HTML/index.htm
<frans> page about further development of geosparql: https://www.w3.org/2015/spatial/wiki/Further_development_of_GeoSPARQL
jtandy: My conclusion is in the end nobody cares about the difference between the spatial things and the geometries.
frans: agrees, it's always about the digital models of things, not the real world things
jtandy: when people create linked data, and they want to record the color of a fire hydrant, they have the real world thing in their head. Fundamentally, people can figure it out.
<frans> An example: https://www.w3.org/TR/vocab-org/#org:Site
jtandy: refers to TBLs VCard example.
<jtandy> * It is not uncommon for Spatial Data Infrastructures (SDI) to expose geographic datasets with overlapping scope. For example, two datasets may describe lighthouses in the UK: (i) maritime navigation aids, and (ii) aviation vertical obstructions. Both datasets may describe a Feature for Eddystone Lighthouse; each with attributes defined according to the relevant data model, e.g. one providing a point location and the light characteristic, the
<jtandy> other a detailed two-dimensional representation and obstruction height. Due to the constraints of SDIs, each Feature representing Eddystone Lighthouse would have a different unique identifier. One may assert that these two identifiers identify the same resource (e.g. using `owl:sameAs`). However, care needs to be taken when attempting such reconciliation as the concepts implied by the Feature Type use in each dataset may not be perfectly aligned. Do we
<jtandy> know that two Features are the same real-world Thing? Not really. Collocation of two Features is insufficient to determine ‘sameness’; we must also assess the semantics of each Feature Type and perhaps gather further supplementary evidence to determine if two Features are abstractions of the same real-world Thing.
jtandy: I wrote the above in my notes.
frans: we can assume that people working with data on the web know that we are always talking about representations / models of things, not real world things themselves.
Linda: the Semmtech people have an issue that touches on this subject.
<jtandy> * The BBC defines their `core:sameAs` property to assert that “something is the same as something else, but in a way that is slightly weaker than owl:sameAs. It's purpose is to connect separate identities of the same thing, whilst keeping separation between the original statements of each.” Also note that schema.org [SCHEMA] defines a `sameAs` property that relates an entity to the URL of a reference Web page that provides unambiguous
<jtandy> identification of that entity; using `schema:sameAs` one could assert that both features were identified by [the information listed on] the same reference Web page. Similarly, one could use `isPrimaryTopicOf` [FOAF]
frans: is not the same thing
jtandy: BBC have created their own, weaker version of sameAs
<frans> https://www.w3.org/2015/spatial/track/issues/38
jtandy: let's get back to the
constraints we have in SDIs.
... a feature is an abstraction of a real world thing and is a
member of one particular feature type. Is that the Semmtech
issue?
frans: I'd have to look into it.
jtandy: Is the issue that there are different abstractions of the physical world and you want to somehow relate them?
Linda: that's how I understand it yes.
frans: they want to assert some
kind of equivalence between two models of the same thing. This
is missing.
... not only for spatial data but data in general. sameAs is
too strong, seeAlso to weak.
jtandy: Could e.g. 'spatialSameAs' be part of the spatial ontology?
frans: perhaps, but it could also involve non-spatial models in practice.
jtandy: but could still be ok. Domain and range wouldn't need to be spatial objects.
would mean that both objects are talking about the same spatial object.
frans: could be a suggestion for
spatial ontology work.
... agreeing on the definition of this property could be hard.
But we can put it on a to try list.
... explanations of what is a spatial thing and what is a
geometry belong in the BP.
<jtandy> propose: in the Best Practice document we talk about "spatial things" and "geometries" as being disjoint objects - and no-one cares about the incredibly subtle difference between "spatial things" and the term "Feature" as used in ISO/TC 211 and OGC ... so we will use the term "spatial thing" for simplicity
<jtandy> (topology is a special kind of spatial relationship)
<jtandy> (in the real world - with normal web developers - no one cares about the difference between spatial thing and Feature)
<jtandy> frans says that there are many definitions "floating around" ... but the Spatial Ontology should clarify this
frans: we should have an open description of what is meant by spatial things
Linda: like the description in basic geo
<jtandy> * SpatialThing: “Anything with spatial extent, i.e. size, shape, or position. e.g. people, places, bowling balls, as well as abstract areas like cubes.” [W3C Basic Geo]
<jtandy> * Feature: “A geographical feature, capable of holding spatial relations.” [NeoGeo]
<jtandy> * Location: “A spatial region or named place.” [DCTERMS]
<jtandy> "SpatialThing" is open enough for our needs.
+1
<jtandy> +1
<frans> +1
RESOLUTION: in the Best Practice document we talk about "spatial things" and "geometries" as being disjoint objects - and no-one cares about the incredibly subtle difference between "spatial things" and the term "Feature" as used in ISO/TC 211 and OGC ... so we will use the term "spatial thing" for simplicity
<jtandy> (at least given the 100% agreement from the three of us!)
jtandy: implication: the BP can remain simple, and the subtlety and definitions go in the spatial ontology.
<jtandy> frans: BP doc _needs_ to remain simple!
<jtandy> propose: we will use the W3C Basic Geo definition of SpatialThing in the BP document
frans: a geometry can have
spatial relationships, but these are not automatically also
spatial relationships of the related spatial thing
... an explanation is needed of spatial relationships and how
they are related to spatial things and geometries.
jtandy: is that written down somewhere?
frans: no, not really.
... but should be a simple description. We should write it down
and ask the group's opinion.
Linda: isn't that description present in geosparql?
frans: not really.
<jtandy> functions, rules and relations (as used in GeoSPARQL) all relate to the same fundamental concept of spatial relationships - and it is this fundamental concept we need to describe in the BP doc
<jtandy> ... topology is a sub-class of spatial relation?
<frans> https://en.wikipedia.org/wiki/Spatial_relation
Frans: this page describes topological, directional and distance relationships.
<jtandy> mereological relationship is _not_ a spatial relationship ... anything can be comprised of parts
jtandy: are mereological relationships spatial?
<jtandy> [probably] still need to talk about reconciliation of spatial things ...
jtandy: as editors we now have a clearer picture of what we should put in the BP.
jtandy: have not seen progress.
Linda: me neither
jtandy: we need a new wd before
TPAC
... so next WD before summer break.
Linda: my summer break is first part of sept
jtandy: End of july for next
WD.
... allowing review by group members
... vote on 27th of july
... which means finish by the 20th
... editorial changes on 28th, 29th.
Linda: agrees
jtandy: we didn't approve the
minutes, but we don't have quorum anyway.
... we need to look through the comments and respond to them.
Simeon, Rob Atkinson...
Linda: and the issues?
jtandy: a lot of them will become
solved because we now have the narrative and the DWBP we are
relying more on than before.
... frans thanks for your input!
... closes the meeting
RSSAgent, make logs public
RSSAgent, draft minutes
This is scribe.perl Revision: 1.144 of Date: 2015/11/17 08:39:34 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Found Scribe: Linda Inferring ScribeNick: Linda Present: Linda frans jtandy Regrets: phila kerry eparsons scottsimmons bill mattperry clemens josh andrea roba bart Agenda: https://www.w3.org/2015/spatial/wiki/Meetings:BP-Telecon20160615 WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 15 Jun 2016 Guessing minutes URL: http://www.w3.org/2016/06/15-sdwbp-minutes.html People with action items:[End of scribe.perl diagnostic output]