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

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