Peter Wills, MD at Mercator, the producers of SNAP, presented a paper to the Association for Survey Computing (ASC) back in 1992 on the need for a common standard for exchanging survey data. He invited others to join him in the quest for a standard. In 1993, two other suitors emerged in Merlinco and Pulse Train Technology. Regrettably, Quantime withdrew after initial interest for reasons that are unclear. Many producers have a tendency to view their own data formats as a standard in their own right. Cynics point out that it is one way of ensuring loyalty to your products.
Representatives from the three participating companies met regularly to work out how to represent market research survey data in a way that would work across vendor boundaries. In due course, they published the SSS standard in 1995. Those involved worked with a commendable spirit of co-operation which is rare among rivals. As Geoff Wright, Pulse Train's SSS rep. pointed out, each firm had to take a share of the burden. "The expenses have not been great, but the amount of time each company has put in has been significant."
If, like me, you were ignorant of what the three S's stood for, you may be reassured by the response from Merlinco's SSS rep. Keith Hughes. He confessed "They don't actually stand for anything. The name came about because all the things we were talking about: standardisation, surveys, software, systems, simplicity; all started with S, so we settled for SSS. It made a nice file extension (.SSS) we could use, and if you pronounce it triple-S, it rolls off the tongue quite nicely."
SSS is a kind of Esperanto for market research data. If a software package implements it, SSS appears in the menu of options for saving or loading data. When you save to triple-S, two files are produced: one containing the data, another containing what they call the "metadata". This means the definition of the data in terms of what is where, what the codes mean and the texts or labels associated with the questions and answers. At the other end, when you open the SSS data, it will be read and converted automatically into the format usually used by that package.
The standard is published and is available to any software producer without charge. Peter Wills tells me they had over a hundred enquiries for the standard, and that probably dozens of firms have implemented it. Usually, they only find out because someone hits a snag and phones the SSS Hotline for help. There is an impressive roll of packages supporting it: Bellview, Blaise, In2Quest, Merlin, Pollux, Pulsar, QPS, SNAP, Trax and probably more besides. For the list to grow, researchers and consumers of data must continue to ask their suppliers to support it.
Most software packages include some capability to export to other packages, but they are vulnerable to the other vendor changing his proprietary data format in the meantime. It all gets very complicated for manufacturers and users to stay up to date. SSS, being an external standard, is fixed. When the standard is updated, everyone involved is aware of the change and can respond, and the old standard still exists as a fallback. Furthermore, as Geoff Wright pointed out, people have found it simple to write their own standalone routine to convert SSS metadata into a proprietary definition for other packages such as SAS or SPSS that do not read triple-S.
Peter Wills explained: "We have made great strides in getting many of the software suppliers to support the standard. It has always been our intention that SSS should be a feature within developers' software and not an extra piece of software for which a charge is made. We are increasingly encouraged when we see tender documents that specify the data should be in SSS format."
ASC committee member Andrew Westlake praised the efforts of the SSS team. "It is very important that this sort of thing is done. The whole business of transferring data independently of the systems used to collect it goes back a long way. But there had been no practical attempts to solve the problem among the manufacturers until SSS." After the standard was published, Andrew Westlake made a number of suggestions to the SSS team about improvements that could be made to broaden the focus of SSS. "There were some assumptions about survey data that were true for the developers' packages but which were not true universally. We pointed out a small number of recommendations for changes to make the standard more universal."
Three years after version 1.0, the SSS group are about to publish a revised standard, version 1.1. This has partly come about as a result of input from the ASC, and partly from the practical experiences of SSS being implemented by a wide range of manufacturers. The ASC look certain to endorse this version as it meets almost all of their suggestions. Quite intentionally, it is backwards compatible with the old format. Steve Jenkins, the third member of the team has been working on implementing it in SNAP now. If the change does its job, it will make it easier for a wider range of manufacturers to implement it, and make life simpler for the rest of us. And as for what the three S's really stands for, I can now reveal it is for three "Smart" manufacturers.
Tim Macer provides independent advice and training in market research software applications. Web: www.meaning.uk.com
Triple S information from Mercator 01454 281211 or www.mercator.com or from the ASC at www.assurcom.demon.co.uk.
© Copyright Tim Macer 1998. All rights reserved. Reproduced with permission.
Top | Index