Are all attributes/data points inherently nominal? I'm trying to design a statistics package in .NET, and I'd like to apply object-oriented design principles to some of the data structures that I'm developing.
As I look through sample data sets for simple classifiers, even though there exist other types of attributes (ordinal being the only other one I've seen, with discrete and continuous being variations on that), ultimately they are all able to be classified by a distinct value in some way.
This makes me think that all attribute types are inherently nominal, and that there should be a base type for nominal attributes, as the statement for all other attributes seems to hold true:

<attribute type> is a nominal type

(Note this doesn't mean it's mutually exclusive) 
If that's the case, then the class that represents the type of an attribute on a fundamental level would be a nominal attribute type, with the certain methods/properties that are inherent to all attribute types.
Off the top of my head, the first method would be to be able to determine whether or not an instance of the variable type is the same as another instance of the same attribute type.
Given the above, is every attribute type inherently nominal, even if it might possess other qualities beyond nominal qualities (e.g., ordinal attributes could have the concept of distance between two instances)?
 A: 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).
A: Stanley Smith Stevens proposed a level of measurement in 1946 which is used by many statisticians today.
In it, there are four different scale types proposed:


*

*Nominal Scale

*Ordinal Scale

*Interval Scale

*Ratio Measurement
With each scale type building on the foundations of the other.  For example, ratio measurements can have all of the operations of all of the other scales applied to values of that scale type.
That said, it stands to reason that the hierarchy tree for a type system would be like so:


*

*Nominal Attribute

*

*Ordinal Attribute

*

*Interval Attribute

*

*Ratio scale




