The question (and your answer) invoke Stevens' theory of levels of measurement. This thread perhaps is not the place for a critical evaluation of that (old) theory, which has subsequently been found to be limited and counterproductive in many (but not all) applications. The question, though, implicitly suggests that this theory would provide a basis for software design and development, most likely as a scheme for class inheritance.
Maybe it would work, but I think not.
It makes sense to have an abstract universal or base data class from which all others will inherit, and to supply some default methods for testing equality, printing values etc. Feel free to call this the "nominal" class. In this sense, the answer to the question as stated is "yes," you can think of every data type as (at least) nominal. But what next? Let's consider where the following types of data might properly lie within Stevens' taxonomy and the implications that might have for software design:
Relative orientations: these are ordered but not totally ordered and they enjoy a large continuous group of meaningful transformations (rotations). The lack of total order prevents them from being ordinal, yet they enjoy all the other properties of interval data.
Geographic locations: distances between them make sense, but most transformations do not. Thus, by Stevens, it seems they would be nominal and interval but not both.
Image data: once again, many kinds of distances make sense. There is no intrinsic ordering. Various forms of transformations and comparisons arguably make these a complex and richer form of data than ratio data, though. (What about an image that represents an entire field of ratio data?)
Complex numbers, representing locations on the plane or Euclidean transformations thereof. Richer than ratio data but without an ordering.
Interval-valued data, representing both censored data and data known only to lie between definite bounds. Should these inherit from the type of data whose ranges they represent (ordinal or ratio) or, given that even inequality tests often are indefinite, should they be considered purely nominal (which would strip them of almost all the information they contain)?
Percentages and counted ratios. Such numbers have some characteristics of all of Stevens' types as well as peculiarities of their own. They clearly do not qualify as either interval or ratio data, but treating them as such is commonplace (and can be effective in analysis).
These and other examples suggest it would be limiting to force a hierarchy on the Stevens taxonomy or to use it to design a class for representing data.
Another problem--a big one--with viewing Stevens' taxonomy as a hierarchy is that it just ain't so. For example, data that appear purely ordinal can often be analyzed as interval or ratio (e.g., using ordered logistic regression). Thus, if you want to support effective data analysis, you must not compel the user to view data at one level, nor should you arbitrarily or unnecessarily limit what can be done with data based on the level at which it has been assigned.
One thing you do want to do is to make sure that internal representations used to encode nominal values ("factors," often) never get confused with actual numbers. This is a basic mistake made by many users of systems that use numerical codes to represent factors but then allow those codes to be calculated with (as in regression) as if their actual values were meaningful. I don't think this is a question of class design or of placing data in a hierarchy. A better way to view it may be that of attaching semantic tags to the data to give clues about their proper use, display, or interpretation.
Because the question expresses no design goals, it is not possible to suggest alternatives, but it does appear wise just to ignore the Stevens approach unless the software is intended to limit the usability of the data it works with. Instead, do the software design using good engineering practice: start from a clear statement of the software's purpose and how it will be used. What kinds of data must it store and manage? What kinds of operations does it need to perform on those data? To what extent must it be extensible? What performance requirements might constrain the methods of internal data representation? And so on... This line of inquiry will be more relevant and more productive than trying to adhere to Stevens' system (or anybody else's).
