Re: Does 'Feature' = 'Real World Thing'?

All we really need to do is provide means of expressing the occurrence of “discernment” (a theory) and its connection to a representation in data (a model). We don’t have to get any deeper into cognition than that. Whether two different features / things can be reconciled to one theory of the world, for example, is really out of our scope, although it wouldn’t even be possible to attempt without that documentation of their existence. 

Whether multiple representations (feature data !) model the same feature / thing is very much in our scope. This includes differences in scale, CRS, geometry, form of referencing, even what particular properties have measurements. 

Josh

> On Oct 22, 2015, at 12:06 PM, Krzysztof Janowicz <janowicz@ucsb.edu> wrote:
> 
>> So I think this means that Features (= 'description of Things') don't exist until we create them. Creating them requires that we discern them. This may not always be possible. Figuring out the conditions of what _is_ possible feels like it's outside our scope (thankfully).
> 
> Exactly. In addition, it points to the fact that there are multiple ways to 'construct' features for things and thus many different features can highlight different aspects of (or viewpoints on) what is the same (or appears to be the same) thing.
> 
> Best,
> Krzysztof
> 
> 
> 
> On 10/22/2015 08:58 AM, Jeremy Tandy wrote:
>> @Krzysztof ...
>> 
>> So I think this means that Features (= 'description of Things') don't exist until we create them. Creating them requires that we discern them. This may not always be possible. Figuring out the conditions of what _is_ possible feels like it's outside our scope (thankfully). 
>> 
>> Jeremy
>> 
>> 
>> On Thu, 22 Oct 2015 at 16:29, Krzysztof Janowicz <janowicz@ucsb.edu <mailto:janowicz@ucsb.edu>> wrote:
>> Hi,
>> 
>> 
>>> So... Can we imagine situations where a "thing" does not have an associated "feature" ?
>>> 
>>> Perhaps when we deal with the vague colloquial places ?
>>> 
>> 
>> as features are abstractions / representations, I would argue that most "things" out there do not have "features". If the question is whether certain things cannot have features at all, it becomes more complicated. There are probably some good arguments that can be made on the grounds of human cognition, state of knowledge, and limits of what can be observed.
>> 
>> Best,
>> Krzysztof
>> 
>> 
>> 
>> On 10/22/2015 04:30 AM, Ed Parsons wrote:
>>> So... Can we imagine situations where a "thing" does not have an associated "feature" ?
>>> 
>>> Perhaps when we deal with the vague colloquial places ?
>>> 
>>> Ed
>>> 
>>> 
>>> On Thu, 22 Oct 2015 12:16 Andreas Harth <harth@kit.edu <mailto:harth@kit.edu>> wrote:
>>> Hi,
>>> 
>>> why do you call an information resource/graph a "feature"?
>>> 
>>> They way you use that terminology does not have anything to do
>>> with spatial data.
>>> 
>>> In your terminology, we would have:
>>> 
>>> * http://harth.org/andreas/foaf.rdf#ah <http://harth.org/andreas/foaf.rdf#ah> - identifying the thing/me
>>> as a person
>>> * http://harth.org/andreas/foaf.rdf <http://harth.org/andreas/foaf.rdf> - identifying the feature (?)
>>> 
>>> Calling an information resource (in the Linked Data sense)/graph/
>>> RDF document a "Feature" is a bad idea.
>>> 
>>> In NeoGeo, we use "Feature" for the spatial thing [1].  My impression
>>> was that GeoSPARQL did something similar.  I don't have access to the
>>> definition of "GFI_Feature" of ISO 19156:2011 though.
>>> 
>>> So the following classes would be roughly equivalent (namespaces via
>>> prefix.cc):
>>> * spatial:Feature
>>> * geosparql:Feature
>>> * dcterms:Location
>>> * wgs84:SpatialThing
>>> 
>>> Cheers,
>>> Andreas.
>>> 
>>> [1] http://geovocab.org/spatial#Feature <http://geovocab.org/spatial#Feature>
>>> 
>>> On 10/22/2015 11:39, Simon.Cox@csiro.au <mailto:Simon.Cox@csiro.au> wrote:
>>> >  >> Does that mean that if I want to express this in RDF, I need three
>>> > URIs? One for the real-world-thing, one for the feature and one for the
>>> > feature representation?
>>> >
>>> > ØHopefully you're a little less confused. In my mind we have just two URIs:
>>> >
>>> > oURI identifying 'Thing'
>>> >
>>> > oURI identifying 'description of Thing' / 'Feature' / 'graph'
>>> >
>>> > It is also OK to have distinct URIs for the concrete
>>> > representation/serialization/format of the feature.
>>> >
>>> > Conventionally this is often the URI for the feature with a suffix like
>>> > .rdf, .xml, .ttl appended (as an alternative to http conneg).
>>> >
>>> > e.g.
>>> >
>>> > http://places.net/thing/eddystone-lighthouse <http://places.net/thing/eddystone-lighthouse> is a URI denoting a thing
>>> > in the world
>>> >
>>> > http://example.org/feature/eddystone-lighthouse <http://example.org/feature/eddystone-lighthouse> is the URI for a feature
>>> >
>>> > http://example.org/feature/eddystone-lighthouse.xml <http://example.org/feature/eddystone-lighthouse.xml>
>>> > http://example.org/feature/eddystone-lighthouse.ttl <http://example.org/feature/eddystone-lighthouse.ttl> are URIs for
>>> > different serializations of the feature, so
>>> >
>>> > http://example.org/feature/eddystone-lighthouse <http://example.org/feature/eddystone-lighthouse> foaf:primaryTopic
>>> > http://places.net/thing/eddystone-lighthouse <http://places.net/thing/eddystone-lighthouse> .
>>> >
>>> > http://example.org/feature/eddystone-lighthouse <http://example.org/feature/eddystone-lighthouse> prv:serializedBy
>>> > http://example.org/feature/eddystone-lighthouse.xml <http://example.org/feature/eddystone-lighthouse.xml>
>>> >
>>> > http://example.org/feature/eddystone-lighthouse.xml <http://example.org/feature/eddystone-lighthouse.xml> dct:hasFormat
>>> > http://example.org/feature/eddystone-lighthouse.ttl <http://example.org/feature/eddystone-lighthouse.ttl> .
>>> >
>>> > However, to a dumb URI consumer, which has no conception of ‘suffix’,
>>> > these are different URIs.
>>> >
>>> > Simon
>>> >
>>> > *From:*Jeremy Tandy [mailto: <mailto:jeremy.tandy@gmail.com>jeremy.tandy@gmail.com <mailto:jeremy.tandy@gmail.com>]
>>> > *Sent:* Thursday, 22 October 2015 8:30 PM
>>> > *To:* Svensson, Lars < <mailto:L.Svensson@dnb.de>L.Svensson@dnb.de <mailto:L.Svensson@dnb.de>>; Joshua Lieberman
>>> > <jlieberman@tumblingwalls.com <mailto:jlieberman@tumblingwalls.com>>
>>> > *Cc:* public-sdw-wg@w3.org <mailto:public-sdw-wg@w3.org>
>>> > *Subject:* Re: Does 'Feature' = 'Real World Thing'?
>>> >
>>> > All- many thanks again for contributions to this topic! I think that we
>>> > have a resolution- or at least sufficient resolution for us to move forward.
>>> >
>>> > @Clemens ... you said:
>>> >
>>> >  > there is no concept that would support using the same identifier for
>>> > both features [...]. A feature instance is of exactly one feature type,
>>> > it cannot be of the feature type "light house" from application schema A
>>> > and "vertical obstruction" of application schema B.
>>> >
>>> > I think that this relates to the frame-based _information_ modelling
>>> > approach used for creating Application Schema. And yes- this is
>>> > different to the approach taken with RDF.
>>> >
>>> > @Simon ... based on going back to the spec, you conclude:
>>> >
>>> >  > the term ‘Feature’ clearly refers to the abstraction, information,
>>> > data. [... So we must] Use ‘Thing’ for the real-world (including
>>> > fictional) thing, and ‘feature’ for an information object that describes
>>> > it, according to some viewpoint.
>>> >
>>> >  > regarding Jeremy’s ‘what is the subject’ question, a case could be
>>> > made for using a URI for the real-world thing as the subject in RDF
>>> > statements in all cases, regardless of the model or ‘feature-type’ in
>>> > use, while the set of statements relating to a specific viewpoint
>>> > (feature-type) comprises a graph. The URI for a graph identifies the
>>> > ‘feature’, while the URI for a thing in the world can be subject of
>>> > statements from all viewpoints.
>>> >
>>> > +1 from me. This is the conclusion that I had also reached ...
>>> >
>>> >  1. We identify the real-world (including fictional) Thing.
>>> >  2. We identify a collection of statements (e.g. a graph) that describe
>>> >     the Thing according to a given perspective; the Feature. The Thing
>>> >     is the subject of the statements.
>>> >
>>> > This works for me.
>>> >
>>> > Regarding point (2) it's worth noting that (at least from my pov) it is
>>> > best practice for Application Schema to be solely concerned with the
>>> > conceptual model (the 'universe of discourse'); attributes of the Thing
>>> > that are deemed important in the application domain. That said, I often
>>> > see Application Schema with Feature Types that conflate the 'Thing' and
>>> > 'Feature' (aka information resource) subjects so that the collection of
>>> > properties defined by the Feature Type are a mixture of those that talk
>>> > about the 'Thing' (e.g. height; an instance might assert height = 37ft
>>> > ... this is clearly about the 'Thing') and those that are metadata about
>>> > the 'Feature' (information object) itself (e.g. creation date, last
>>> > update time, license, owner, maintainer etc.). This makes it very
>>> > difficult to merge data from such instances of those Feature Types
>>> > because the subject isn't clear.
>>> >
>>> > [OK- if that passed you by, don't worry]
>>> >
>>> > @Josh ... you said:
>>> >
>>> >  > We can happen to recognize two things that have close the same
>>> > spatial extent (and temporal extent). That doesn’t make them the same
>>> > “thing”. [...] We learn something by interpreting the collocation, just
>>> > as layering features in a map brings insight.
>>> >
>>> > Indeed. Collocation is a useful indicator but, by itself, is often
>>> > insufficient to determine 'sameness'.
>>> >
>>> > If we apply Simon's proposal that the 'Thing' is the subject of the
>>> > statements in the Feature, two (or more) Features may use the same
>>> > 'Thing' as their subject. This is an explicit assertion of sameness and
>>> > is achieved either by both Features using the same identifier for their
>>> > subject, or by using the 'sameAs' assertion to say that the two
>>> > identifiers actually refer to the same Thing. These are very strong
>>> > assertions, not to be taken lightly.
>>> >
>>> > Regarding the reconciliation of data that is apparently talking about
>>> > the same thing, Ed previously said "here be dragons" [1].
>>> >
>>> > @Lars ...
>>> >
>>> >  > Does that mean that if I want to express this in RDF, I need three
>>> > URIs? One for the real-world-thing, one for the feature and one for the
>>> > feature representation?
>>> >
>>> > Hopefully you're a little less confused. In my mind we have just two URIs:
>>> >
>>> >   * URI identifying 'Thing'
>>> >   * URI identifying 'description of Thing' / 'Feature' / 'graph'
>>> >
>>> > Why two URIs? Why can't we just have one? It's clear that we have two
>>> > resources: the 'Thing' and 'description of Thing'. The Web Architecture
>>> > [2] (that we agreed forms a foundational aspect of our best practice)
>>> > states:
>>> >
>>> > */Constraint: URIs Identify a Single Resource/*
>>> >
>>> > Assign distinct URIs to distinct resources.
>>> >
>>> > Furthermore, the need to treat 'Thing' and 'description of Thing' as
>>> > disjoint resources is the subject of W3C URLs in Data Primer [3].
>>> > 'Feature' is synonymous with the term 'Record' [4] defined therein.
>>> >
>>> > Section 4 'Documenting Properties' [5] notes that:
>>> >
>>> > "A data format that mixes properties about [...] records and properties
>>> > about the things those [...] records describe is not necessarily
>>> > ambiguous: all that's required for developers to understand what the
>>> > properties actually apply to is for the meaning of the property to be
>>> > documented."
>>> >
>>> > This is exactly the situation we have with many existing (GML)
>>> > Application Schema. URLs in Data proposes how to declare which property
>>> > is which type. Section 5.3 'Publishing Data' [6] says that:
>>> >
>>> > "Publishers can help enable more accurate merging of data from different
>>> > sites if they support URLs for each entity
>>> > <http://www.w3.org/TR/urls-in-data/#dfn-entity <http://www.w3.org/TR/urls-in-data/#dfn-entity>> they or other sites may
>>> > wish to describe, separate from the [...]records
>>> > <http://www.w3.org/TR/urls-in-data/#dfn-record <http://www.w3.org/TR/urls-in-data/#dfn-record>> that they publish."
>>> >
>>> > So it's best two have 2 URIs; one for each of Thing and Feature.
>>> >
>>> > Jeremy
>>> >
>>> > [1]: http://lists.w3.org/Archives/Public/public-sdw-wg/2015Sep/0059.html <http://lists.w3.org/Archives/Public/public-sdw-wg/2015Sep/0059.html>
>>> >
>>> > [2]: http://www.w3.org/TR/webarch/#id-resources <http://www.w3.org/TR/webarch/#id-resources>
>>> >
>>> > [3]: http://www.w3.org/TR/urls-in-data/ <http://www.w3.org/TR/urls-in-data/>
>>> >
>>> > [4]: http://www.w3.org/TR/urls-in-data/#dfn-record <http://www.w3.org/TR/urls-in-data/#dfn-record>
>>> >
>>> > [5]: http://www.w3.org/TR/urls-in-data/#documenting-properties <http://www.w3.org/TR/urls-in-data/#documenting-properties>
>>> >
>>> > [6]: http://www.w3.org/TR/urls-in-data/#publishing-data <http://www.w3.org/TR/urls-in-data/#publishing-data>
>>> >
>>> > On Thu, 22 Oct 2015 at 07:37 Svensson, Lars < <mailto:L.Svensson@dnb.de>L.Svensson@dnb.de <mailto:L.Svensson@dnb.de>
>>> > <mailto:L.Svensson@dnb.de <mailto:L.Svensson@dnb.de>>> wrote:
>>> >
>>> >     On Wednesday, October 21, 2015 10:38 PM, Joshua Lieberman wrote:
>>> >     [...]
>>> >
>>> >     [Clemens]
>>> >      > > But first of all, the feature is an information object
>>> >     describing a real-world
>>> >      > thing.
>>> >      >
>>> >      > That's consistent with the definition of Spatial Object in
>>> >     INSPIRE. Restated:
>>> >      > • Feature != Real-World Thing
>>> >      > • Feature = Information Resource that _describes_ Real-World Thing
>>> >      > @Josh, @Simon: can you confirm this meets your expectations?
>>> >
>>> >     [Josh]
>>> >      > Almost. There are two feature statements needed to get from the
>>> >     world to
>>> >      > spatial data:
>>> >      >
>>> >      > 1. Feature = discernment of a type of Real-World Thing (as
>>> >     distinct from Not
>>> >      > Thing)
>>> >      > 2. Feature Data = representation of a Feature (as an information
>>> >     resource)
>>> >
>>> >     Does that mean that if I want to express this in RDF, I need three
>>> >     URIs? One for the real-world-thing, one for the feature and one for
>>> >     the feature representation?
>>> >
>>> >     Best,
>>> >
>>> >     Lars (who starts to feel confused...)
>>> >
>>> 
>>> 
>>> -- 
>>> Ed Parsons
>>> Geospatial Technologist, Google
>>> 
>>> Google Voice +44 (0)20 7881 4501
>>> www.edparsons.com <http://www.edparsons.com/> @edparsons
>>> 
>> 
>> 
>> -- 
>> Krzysztof Janowicz
>> 
>> Geography Department, University of California, Santa Barbara 
>> 4830 Ellison Hall, Santa Barbara, CA 93106-4060 
>> 
>> Email: jano@geog.ucsb.edu <mailto:jano@geog.ucsb.edu>
>> Webpage: http://geog.ucsb.edu/~jano/ <http://geog.ucsb.edu/%7Ejano/>
>> Semantic Web Journal: http://www.semantic-web-journal.net <http://www.semantic-web-journal.net/>
> 
> 
> -- 
> Krzysztof Janowicz
> 
> Geography Department, University of California, Santa Barbara 
> 4830 Ellison Hall, Santa Barbara, CA 93106-4060 
> 
> Email: jano@geog.ucsb.edu <mailto:jano@geog.ucsb.edu>
> Webpage: http://geog.ucsb.edu/~jano/ <http://geog.ucsb.edu/~jano/>
> Semantic Web Journal: http://www.semantic-web-journal.net <http://www.semantic-web-journal.net/>