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

@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> 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> 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 - identifying the thing/me
>> as a person
>> * 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
>>
>> On 10/22/2015 11:39, 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 is a URI denoting a thing
>> > in the world
>> >
>> > 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.ttl are URIs for
>> > different serializations of the feature, so
>> >
>> > http://example.org/feature/eddystone-lighthouse foaf:primaryTopic
>> > http://places.net/thing/eddystone-lighthouse .
>> >
>> > http://example.org/feature/eddystone-lighthouse prv:serializedBy
>> > http://example.org/feature/eddystone-lighthouse.xml
>> >
>> > http://example.org/feature/eddystone-lighthouse.xml dct:hasFormat
>> > 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:jeremy.tandy@gmail.com]
>> > *Sent:* Thursday, 22 October 2015 8:30 PM
>> > *To:* Svensson, Lars <L.Svensson@dnb.de>; Joshua Lieberman
>> > <jlieberman@tumblingwalls.com>
>> > *Cc:* 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> they or other sites may
>> > wish to describe, separate from the [...]records
>> > <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
>> >
>> > [2]: http://www.w3.org/TR/webarch/#id-resources
>> >
>> > [3]: http://www.w3.org/TR/urls-in-data/
>> >
>> > [4]: http://www.w3.org/TR/urls-in-data/#dfn-record
>> >
>> > [5]: http://www.w3.org/TR/urls-in-data/#documenting-properties
>> >
>> > [6]: http://www.w3.org/TR/urls-in-data/#publishing-data
>> >
>> > On Thu, 22 Oct 2015 at 07:37 Svensson, Lars <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 @edparsons
>
>
>
> --
> 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
>
>