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

Yes! +1
On Thu, 22 Oct 2015 at 17:06, 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>
> 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
>>
>>
>
> --
> 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
>
>