A data model describes the organization of data. It is composed of a defined set of elements and structures along with valid operations which can be performed on those elements and structures. All programming languages incorporate a data model in their design. For example the C programming language defines a set of types which can be used to build programs (int, double, ...); that set of types and their associated operations is the data model for C programs. Similarly, while not full-fledged programming languages, APIs define a data model for the resources to which they provide access by defining a set of functions (which are analogous to operators in a programming language) and defining types which are passed to, or returned from, those functions.
Data models are important because they provide a way to describe the types of information that can (or cannot) be described using a given programming language or API. Thus a data model can be used to compare the applicability of two such systems to a particular problem. In addition, if a single data model is supported by two APIs then it is possible to translate information represented using that data model from one API to an equivalent representation in the other API. Knowing which data model or models are supported by a set of APIs enables a scientist to choose the API best suited to a given type of information. It also provides a means for programmers to build translators for certain types of data represented using those APIs.
As is often the case with semantic descriptions, a formal description of a data model is hard to produce for many existing systems. This is true because many APIs do not rigorously define their operators. Instead they rely on conventions with ill specified boundary conditions. Thus the exact semantics of many data types are hard to formalize.
The lack of formal data model semantics is further complicated when new types are added (ad hoc) to an API. The `data type' exists only in so much as users of the API agree to be bound by convention. A user may abuse the convention or they may ignore, out of ignorance, a widely used convention. Either case creates data that is hard to use. This problem create special difficulties for people writing data translators since important conventions have not been followed. For this reason, it is impossible to write perfect translators even for a subset of data types.
Lack of formal data model semantics makes it hard to build translators to or from an API or programming language even for a small set of well defined objects. Thus for many APIs, while it is possible to build translators for data represented using a core set of data models common to those APIs, it is not in general possible to build translators for any arbitrary object represented in one API to every other API4.