- Galdos Systems Inc. - https://www.galdosinc.com -

Technology and Social Perception

A well known philosopher, commenting on the vagaries of human interaction, once made the remark that, on seeing another person coming towards him, he thought either “not me” or “another me”.  I believe that this simple and, I suppose, obvious distinction has far reaching implications for the adoption of technology, and even more so in this age of the Internet and the global village.

One might think that the adoption of technology and, by extension, technology standards, would be governed by pure rationality, or at least pure rationality moderated to some degree by enlightened commercial interest.  I will argue that, while such considerations do play a role, that role is relatively small compared to the role played by social and cultural factors – the social dynamics.  The technology that we get is not so much the right technology as it is the technology which, at a given point in time, is the most socially acceptable.

Contemporary development of information technology is very much a group process, whether we are talking about open standards such as the OGC or ISO TC/211, open source projects (e.g. OSGEO), or trying to gain the adoption for closed source proprietary technology.  In all cases, group perceptions dictate the final outcome, and this often has only a small amount to do with technical feasibility or capability and a huge amount to do with social and group dynamics.

In the OGC, for example, decisions are to be obtained by consensus.  This generally argues against radical ideas or ideas which substantially change the status quo.  It also argues in favour of ideas that are presented by likeable personalities or by those perceived as having authority, or ideas that are most readily understood.

Consider the Capabilities document interface (GetCapabilities) developed at the OGC.  From a rational IT perspective today, it does not make a great deal of sense.  No tools exist to parse and process capabilities documents, and no “theory” exists that describes how to construct a capabilities document for a new web service, other than to imitate ones that already exist.  When the OGC web services were just getting started, this was a reasonable idea.  The service construct was a new one, and the idea that a service could advertise what it could do was a perfectly sensible one.  At that point in time there were few, if any, web services (I don’t think the term was even used in the OGC) and ideas in the broader web world around Web Interface Description Language (WIDL), an evolution from CORBA IDL, were just getting underway.

The situation today is somewhat different.  Whatever the problems in the evolution of the Web Services Description Language (WSDL) specification (the W3C is captive to the same principles of evolution as the OGC), we now have a situation where WSDL (version 1.1) is supported in a variety of tools, and the creation of usable stubs is generally possible.  At the same time, the OGC capabilities documents have become even more complex, and the gap between OGC web service descriptions and those of the wider IT world has further widened.

Consider, for example, the now venerable Web Map Service (WMS).  To determine the list of map layers advertised by a WMS, one issues the GetCapabilities call and is returned a capabilities document.  One then parses this document to obtain the list of supported map layers.  Would it not make more sense simply to introduce a new operation into the service interface, something like “GetMapLayerList” which, as the name suggests, would return a list of map layers?  This would then appear in the WSDL description of the interface, and hence be usable by general web service tools.

The same situation applies to the Web Feature Service (WFS).  To obtain the schema description for a given feature type requires that one issue first a GetCapabilities request, then parse out the list of feature type names supported, then issue a DescribeFeatureType request for the selected feature type name or names.  It is strange that the first part (the list of feature type names) is part of the capabilities, while the request for the schema information is a separate operation.  This makes perfect sense when you realize that the WFS was developed after the WMS and used the latter as its point of departure.  Of course it would be entirely more sensible if the WFS (like the WMS) had provided a GetFeatureTypeNameList operation instead of burying this in the capabilities document.

At this point in time, such things are difficult to change.  Vested interests in the status quo will argue to keep things as they are or, even worse, do things like enabling parameterized requests for part of the capabilities document, thus completely missing the point about alignment with tools in the broader IT world.

The importance of social and group dynamics is even greater in the world of so called “neo-geography”, with some adherents of this completely undefined “discipline” labeling their non-adherents as “paleo-geographers” – whatever that might mean.  It harkens back to the days of believers and heretics, and I expect that much of the same social dynamic is at work.  It is no accident that the IT world labels certain types of debates as “religious”.  What is “neo-geography”?  At best, it amounts to looking at geo-processing from a new perspective and championing things like user-created data (although, to some degree, data is always user-created).  At worst, it adopts the notion that whatever idea is most widely held is likely to be correct – even if it is factually, and even mathematically, incorrect.  I have had innumerable discussions where neo-geographers want to wish away coordinate systems (“we don’t need polar projection”), or think that one coordinate system can suffice for the entire earth, or that polygons don’t need holes, and so on.  None of these considerations are based on reasoned argument, but rather on an appeal to “what the common man may understand”.  Similar arguments are raised to attempt to eliminate any level of complexity, in spite of the fact that the common man does not understand the operation of his watch or his telephone or his automobile.  Confusing internal complexity with external ease-of-use is a common outgrowth of these viewpoints.

None of this is to argue that groups cannot create useful advances in technology and in technology standards.  It is, rather, to try and make each of us aware of the foundation for the arguments that we are making.  Perhaps, had others done so in the past, Galileo would not have been declared to be guilty of heresy!