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

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...)
>

Received on Thursday, 22 October 2015 11:15:58 UTC