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

> On Oct 21, 2015, at 1:26 PM, Clemens Portele <portele@interactive-instruments.de> wrote:
> 
> Hi Jeremy,
> 
>> On 21 Oct 2015, at 14:42, Jeremy Tandy <jeremy.tandy@gmail.com <mailto:jeremy.tandy@gmail.com>> wrote:
>> 
>> Hi Clemens ... 
>> 
>> > In the "light house" and "vertical obstruction" example you have two different features - in two datasets and of different feature types, but they describe the same real-world thing. Yet, these are still separate features.
>> 
>> 'Light house' and 'vertical obstruction' are the _things_ talked about; they occur in the "universe of discourse" for the associated application domains.
>> 
>> Using Josh's terminology, we are _discerning_ that there are two Features. Why two? Because we have two domains that are interested in different aspects of the real-world thing.
> 
> So, I think we are saying the same thing, two features - one real-world thing. Or am I missing something?

The point is that there is no “thing” until we recognize it. 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”. Suppose the lighthouse is turned into a B&B. It’s no longer a lighthouse - a navigational aid. It’s an abode with property, outbuildings, but it’s still a vertical obstruction. Lighthouse, vertical obstruction, B&B are overlapping in space and time but not identical in either domain. We learn something by interpreting the collocation, just as layering features in a map brings insight.

> 
> 
>> 
>> In your statement above you say "_in_ two datasets" ... I would prefer to say _described_ by two datasets. It is likely that within each dataset a different identifier would the assigned to the Feature.
> 
> What I meant is that we have feature A in dataset 1 and feature B in dataset 2. I would still use "in" as the dataset is a collection of features (plus other information).

More accurate to say that it’s a shorthand for feature description A or feature representation B in each dataset.

> 
> 
>> 
>> It may be that I am taking an RDF-centric approach here, but I see this as saying:
>> i) there are two _subjects_ 
>> ii) there are a set of properties assigned to each of those subjects (e.g. height = 34ft)
>> iii) the set of properties assigned are those that are of interest in the "universe of discourse" for each associated application domain
> 
> I would say that ISO 19101/19109 say the same (with subject = feature).
> 
>> 
>> Because both features describe the same real-wold thing, we are safe to reconcile these identifiers ... all the properties from the "light house" Feature _and_ all the properties from "vertical obstruction" Feature are valid properties of _the_ (single) real-world thing.
>> 
>> ... So it's safe to use the _same_ identifier for both _subjects_ (or assert the sameness using the sameas relationship).


> 
> Now this is where the differences between RDF and the feature model become relevant. There is nothing like sameAs in the feature model and there is no concept that would support using the same identifier for both features that I am aware of - both in the standards and in GIS implementations. 
> 
>> 
>> I expect you already know this, but ... in RDF it is possible for a Subject to be many things. RDF Classes equate to the "set of things for which these axioms are true" (I've probably got this a little wrong - apologies to those who know better!). So my Subject, the real-world Thing, can be in _both_ the set of "light houses" and the set of "vertical obstructions".
> 
> And this is another difference. 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.

Discernment is being confused with inheritance. One might assert a third feature that is a type of (derived from) both lighthouse and vertical obstruction (in RDF and/or ISO). This is in fact one way to reconcile overlapping and conflicting instances of feature recognition. It’s still a feature assertion, though, not an a priori Thing.

> 
>> 
>> > 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?

Almost. There are two feature statements needed to get from the world to spatial data:

Feature = discernment of a type of Real-World Thing (as distinct from Not Thing)
Feature Data = representation of a Feature (as an information resource)

>> 
>> > When representing it in RDF, it may be more natural to distinguish the [Thing and Information Resource describing Thing]. I have some doubts that this would help to make spatial data easier to use for the broader web community, but that will be an interesting point to discuss and learn from existing practice.
>> 
>> Agreed. Personally, I think that conflating the concerns of "Thing" and "Information Resource describing Thing" is not helpful. I think this is echoed by the earlier comment from @Bill:
>> 
>> > Most common applications will want to ask questions about real world Things and we may often be able to assign attributes directly to them (location etc) [...].
>> 
>> I look forward to dissecting existing practice :-)
>> 
>> (Whilst this might seem like an academic discussion, I think that this is one of the things at the root of the impedance mismatch between web and geo communities)
> 
> Yes, I agree - although I would probably have used "semantic web community", not "web community" :). I would welcome it, if the best practice would provide guidance on this subject.

This is a good point, c.f. the Infamous Issue 14 that Phil brought up ("What is the range of the HTTP dereference function?”). The semantic web community cares to some extent about ontological commitment (a concept inheres to the real world). The broader web community sees that somehow people manage to interpret web pages in terms of real world experience and not get burned too often, so feels that explicit assertions about Things are superfluous.

> 
> Clemens
> 
> 
>> 
>> Jeremy
>> 
>> On Wed, 21 Oct 2015 at 00:20 Clemens Portele <portele@interactive-instruments.de <mailto:portele@interactive-instruments.de>> wrote:
>>> I think you're saying Feature = Real World Thing ... and Feature Description = Information object that describes Real World Thing. Makes sense to me.
>> 
>> This is not how ISO/OGC use the term "feature", or "feature instance" to be more specific (and "feature description" is not a term I have seen used in ISO/OGC standards). 
>> 
>> In the "light house" and "vertical obstruction" example you have two different features - in two datasets and of different feature types, but they describe the same real-world thing. Yet, these are still separate features.
>> 
>> The language is not always clear and "feature" is sometimes also used for the real-world thing and not the information object. I think the reason is that the distinction is blurred in the General Feature Model of ISO/OGC. There will be properties that describe the real-world thing (e.g. height, year of construction, etc.) and those should be consistent between the "light house" and the "vertical obstruction" features. At the same time there will be properties that describe the information object (e.g. provenance information) and these will differ between the datasets. In the General Feature Model these properties are all associated with the feature. So, sometimes when we talk about the feature, we talk about the information object ("last updated today") and sometimes about the real-world thing ("it is 34ft high"). But first of all, the feature is an information object describing a real-world thing.
>> 
>> When representing it in RDF, it may be more natural to distinguish the two subjects. I have some doubts that this would help to make spatial data easier to use for the broader web community, but that will be an interesting point to discuss and learn from existing practice.
>> 
>> Clemens
>> 
>> 
>>> On 20 Oct 2015, at 17:57, Jeremy Tandy <jeremy.tandy@gmail.com <mailto:jeremy.tandy@gmail.com>> wrote:
>>> 
>>> Bill, Andrea, Josh, Simon ... 
>>> 
>>> All great points; thanks!
>>> 
>>> @bill ... understanding the relationship between Thing and Feature is crucial; this echoes the discussions we've had regarding Thing vs. [INSPIRE] Spatial Object within the UK Location Programme. That said, let's bottom out the definitions of both first ...
>>> 
>>> @andrea ... I think that fictional things (like Dicken's London) count as 'real-world Things'. OK; that's counter intuitive :-) ... but I'm implying that we _talk_ about them in the real world; they are part of the "universe of discourse".
>>> 
>>> @josh ... feature _discernment_ vs. feature _representation_; excellent & articulate description. You raise the example of "light house" ... the same physical thing is _discerned_ as, say, "navigation aid" for maritime and "vertical obstruction" for aviation. Clearly, these are both valid 'views' of the light house with respect to their domain of application. Each 'view' of the light house will, necessarily, contain the information which is pertinent for that application ... using your terms, there will be two _representations_ of the lighthouse.
>>> 
>>> However, I think that your conflation of the _discerned_ feature and its representation is problematic. Since working with RDF, I've learned that it's very useful to be specific about the subject of each triple. For example, attributes such as 'owner' could apply to both the light house (physical Thing) _and_ the representation (information resource). It makes sense to identify these separately. This is the advice from W3C URLS in Data (FPWD) <http://www.w3.org/TR/urls-in-data/>.
>>> 
>>> Going back to the point that there are two _discerned_ features (navigation aid & vertical obstruction) it is highly likely that the parties from the responsible communities will mint their own identifiers for the light house. This happens all the time ... the "non-unique-naming" problem. We have to have mechanisms in place to allow those discerned features to be reconciled.
>>> 
>>> That said, I think your point is that (discerned) Feature = Real World Thing. (more or less).
>>> 
>>> @simon ... I think you're saying Feature = Real World Thing ... and Feature Description = Information object that describes Real World Thing. Makes sense to me. I would still say that we need to identify both the Thing and the Information Resource - not conflate them.
>>> 
>>> Jeremy
>>> 
>>> On Tue, 20 Oct 2015 at 04:05 <Simon.Cox@csiro.au <mailto:Simon.Cox@csiro.au>> wrote:
>>> I like to use ‘feature description’ to refer to the digital representation.
>>> 
>>> Elide ‘description’ when it is obvious from context and does no other harm.
>>> 
>>> Or use ‘description’.
>>> 
>>>  
>>> 
>>> Ø  Different features, same real world thing...
>>> 
>>>  
>>> 
>>> Different descriptions, same feature? 
>>> 
>>>  
>>> 
>>> Simon
>>> 
>>>  
>>> 
>>>  
>>> 
>>> From: Linda van den Brink [mailto:l.vandenbrink@geonovum.nl <mailto:l.vandenbrink@geonovum.nl>] 
>>> Sent: Monday, 19 October 2015 6:24 PM
>>> To: SDW WG Public List <public-sdw-wg@w3.org <mailto:public-sdw-wg@w3.org>>
>>> Subject: RE: Does 'Feature' = 'Real World Thing'?
>>> 
>>>  
>>> 
>>> Hi all,
>>> 
>>>  
>>> 
>>> IMO what we call features in the geospatial domain are usually abstractions of representations on maps of real world things; not abstractions of real world things themselves. I see this a lot in information models in the Netherlands. For example, we have two information models that have features of class Building. They both model exactly the same set of objects, but one model captures the building geometry as seen from above, the other from ground level. Different features, same real world thing...
>>> 
>>>  
>>> 
>>> Linda
>>> 
>>>  
>>> 
>>> Van: Jeremy Tandy [mailto:jeremy.tandy@gmail.com <mailto:jeremy.tandy@gmail.com>] 
>>> Verzonden: maandag 19 oktober 2015 8:43
>>> Aan: SDW WG Public List
>>> Onderwerp: Does 'Feature' = 'Real World Thing'?
>>> 
>>>  
>>> 
>>> Hi-
>>> 
>>>  
>>> 
>>> I've been working through the discussion on Linking-Data and this uncovered (or, really, re-found) this issue.
>>> 
>>>  
>>> 
>>> By OGC terminology, Feature is "an abstraction of a real world phenomenon". Linked Data folks like to talk about Real World Things (both physical and abstract).
>>> 
>>>  
>>> 
>>> There's a disjoint here that we need to resolve.
>>> 
>>>  
>>> 
>>> I've captured the question on the wiki [1] and included the content below.
>>> 
>>>  
>>> 
>>> Jeremy
>>> 
>>>  
>>> 
>>> [1]: https://www.w3.org/2015/spatial/wiki/Linking_Data#Question:_is_a_Feature_the_Real_World_Thing.3F <https://www.w3.org/2015/spatial/wiki/Linking_Data#Question:_is_a_Feature_the_Real_World_Thing.3F> 
>>> 
>>>  
>>> 
>>> Question: is a Feature the Real World Thing?
>>> ISO 19101 -- Geographic information - Reference model states: 
>>> ·         [4.11] feature: abstraction of real world phenomena
>>> ·         [4.12] feature attribute: characteristic of a feature ...
>>> ·         EXAMPLE 2 A feature attribute named ‘length’ may have an attribute value ’82.4’ which belongs to the data type ‘real’.
>>> The definition of feature attribute is clear- it's a piece of information about the feature.
>>> 
>>> feature is not quite so clear. In this context, what does abstraction mean?
>>> 
>>> Typically, the Linked Data community refer to Real-world ‘Things’ (see Designing URI sets for the UK public sector <https://www.gov.uk/government/publications/designing-uri-sets-for-the-uk-public-sector>); real-world Things (or just Things) are "are the physical and abstract ‘Things’ that may be referred to in statements". Examples include a school, a road, a person (physical); a government sector, an ethnic group, an event (abstract).
>>> 
>>> A commonly used example is Manchester Piccadilly Railway Station. A URI for Manchester Piccadilly Railway Station would refer to the real station, constructed from steel and concrete with thousands of people passing through it each day. Clearly one cannot expect an HTTP request to return the real railway station (!); it returns an information object about the railway station.
>>> 
>>> W3C URLS in Data (FPWD) <http://www.w3.org/TR/urls-in-data/> discusses the need to differentiate between the real Thing and the information resource that describes it. The Publishing Data <http://www.w3.org/TR/urls-in-data/#publishing-data> section provides three strategies for doing so.
>>> 
>>> In the Geographic Community, the Feature is seen as an information resource - which is, in some way, related to the real-world Thing. INSPIRE (Generic Conceptual Model <http://inspire.ec.europa.eu/documents/Data_Specifications/D2.5_v3.4.pdf>) refers to these resources as Spatial Objects: "abstract representation of a real-world phenomenon related to a specific location or geographical area". It notes that the term is "synonymous with "(geographic) feature" as used in the ISO 19100 series" and, later, talks about versioning the Spatial Objects. Clearly, you can only version the record of information held about a real world Thing, not the Thing itself?
>>> 
>>> So the question remains: are we identifying real-world Things (both physical and abstract) or information objects that describe them? Once that's decided, we need to get our terminology clear and stick to it!
>>>