HI,
See comments inline.
Ron
From: galeon-bounces@xxxxxxxxxxxxxxxx
[mailto:galeon-bounces@xxxxxxxxxxxxxxxx] On Behalf Of John Graybeal
Sent: October 7, 2008 12:03 PM
To: Ben Domenico
Cc: Unidata GALEON
Subject: Re: [galeon] Features and Coverages
Ben's clarification from O&M also helps minimize or avoid a possibly
approaching train wreck. The initial definition was feature: just a geographic
thing the next definition was feature: abstraction of real-world phenomena (so it
is no longer the physical thing, just the abstraction), and the discussion after
that suggested to me feature: a digital artifact, possibly with associated digital
services and attributes.
I would say a feature can be quite abstract like a political boundary,
congressional district as well as being some physical thing. I think it can
also be a phenomenon or process. I think the idea of having identifiers for
real world things is ESSENTIAL and a key missing bit in most of our discussions
of information infrastructures. Gazetteers are starting points, but are
usually very restrictive. We often have no way to say that two computer
representations are about the same real world entity. Only a published registry
of identifiers can make that possible.
The distinction between a data structure and a feature seems pretty slippery.
I would say any data structure that has application meaning is a feature.
Coverages describe the variation in space/time (or other domain) of some
property or quality. I personally think the Space/time aspect of this is
paramount - since even in cases where we have other domains (say pressure) we
usually want to know that two measurements were or were not taken at the same
time/place EVEN if we do not know what that time/place is. This seems pretty
intrinsic to physical phenomena.
Since in many standards the term 'feature' or similar is (arguably) referring
to the thing being observed, and is referenced by a URI that names that
physical entity, it will be helpful to keep the following concepts distinct:
a) the real-world entity (this would be something wet, for example)
b) a URI-style or other computationally usable reference to that real-world
entity (this is just an identifier), and
c) an abstraction of this (or any) real-world entity that lives in a model or
computer program and describes the entity
I think the fact that an observation may be targeted to the obtaining one or
more properties of a feature is more a mission objective. I don't think it is
an intrinsic part of the observation itself. It may even be more important to
connect the features back to the observations on which they are based.
Sometimes such a feature of interest is known at observation time (and their
may be MANY such features of interest), but sometime it is not known until much
later on, even long after the observation.
Things like points, lines, areas, and volumes seem to be solidly in the third
category.
I tend not to think of geometry (or time) as features since they have in
themselves no application meaning - they describe properties of features.
Features of interest seem solidly in the first category, until you have to
refer to them with a 'name', then the name itself is in the second category.
(There is a long list of possible definitions of the term in the Oceans IE
report submitted to OGC, 08-124 if you have access; list is appended below).
Coverages and sampling features also are of the third class, though possibly
containing reference to an actual entity by location or name.
I apologize if I didn't get those divisions exactly right, but I'm sure at
least these 3 concepts usefully co-exist.
