NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
Hi, Ron, Ron Lake wrote:
Hi Gerry et al: I think part of the problem is a misunderstanding of the OGC as taking geospatial concepts and applying them elsewhere. Nothing could be further from the truth. OGC has been much more about deriving and applying appropriate abstractions that are intended to be common to many domains. It began by looking at traditional geographic information as in mapping but quickly was extended to other "real" domains, because there is really no such thing as a geospatial domain. The whole approach to observations for example has its roots in measurement theory from people like Luce and Fowler who had nothing to do with anything geospatial.
This is a problem in perception. And part of the problem is in the origins of the organization and some of its leading membership's principle line of business. However, stated this way, we can agree to proceed.
The notion of feature (read application object) is key point in all of this. In the early days of computing, the word data referred to the available abstractions - the numeric or text etc values that could be stored and moved about. What these values really meant was not captured in the computing system. This was true in all areas of science/engineering (I spent more than a decade in research automation for wind tunnels), mapping, surveying, computer aided drawing/design, etc etc.
Very true.
As people began to share information between machines it was of course initially very bottom up since that was the available representation and the machine resources could not cope with anything else.
Ah, but I'd offer that the need for bottom-up integration hasn't decreased today. However, what we can facilitate is meeting in the middle with the scientists who still feel they must start bottom-up.
In the early 80's it began to become clear that a deeper representation of things was needed - not only to share information across domains but even to make it more generally possible to share information between programmers/users in one domain or even in one enterprise. This rise of the object oriented viewpoint, changed the meaning of the word "data" from simple primitive types to objects - things that model as closely as possible what we are doing and talking about. This modeling approach had of course actually started earlier in the world of databases, but until the 1980's the idea of transporting these models about was not in the cards.
This is a different religious war. OOP has been discussed and redefined several times. The concept of reusable objects in programming, from code elements to data, is an overall good idea, but still not completely embraced in the real world. I think what you are suggesting has merit, though.
Today we see the world in terms of objects, entities or features - and much of the OGC is concerned with what are the appropriate such things for a given domain or class of domains. This is not a geospatial viewpoint. It is more that of knowledge engineering.
Agreed.
It is worth noting that the world of building/structure design (computer
aided design) has been going through a similar transformation to the one
being discussed. CAD started as noted above with a focus on geometric
primitives - points, lines etc. Soon, however, it became clear that to
exchange this information with others in a design team - one needed to
know what these things meant - that this line was the edge of a door,
that the door was made of wood etc. Gradually (and I would say the
transformation is not at all complete) this meant switching the
representation so that we start with meaningful entities in the domain
(like door, wall etc) and then describe these things in terms of
geometric and other characteristics. This is the point of the Building
Information Model (BIM) which has been making a lot of noise these days
and is of course leading to the possibility of CAD/GIS integration in a
meaningful way.
I think this same thinking is behind the modeling of observations and
was the origin of my comment that triggered this discussion.
In very crude terms it is something like:
<Point>
<temperature>30</temperature>
<coordinates>50,20</coordinates>
</Point>
vs
<Observation>
<location>
<Point>
<coordinates>50,20</coordinates>
</Point>
</location>
<result>
<temperature>30</temperature>
</result>
</Observation>
Again, though, this will require that we convert a large group of other fields to our way of thinking. I can see the benefits to this -- that's why I've been involved -- but suggest that we have to remain cautious of how we represent our plans and methods here.
I suspect we're evolving to arguing on the same side: Simon and I have had a sidebar conversation where we're also likely in violent agreement. I'm just trying to be the advocate here for the folks who aren't spending their lives looking at the knowledge-engineering aspects of making their data interoperable. A lot of them may not realize the benefits accrued by coming to a common representation method.
gerry
galeon archives: