The issue about whether ORM uses attributes often comes up, and ORM's position in this regard is sometimes misunderstood by people who are used to other approaches. The following explanation will hopefully shed some light on this issue.
If you think in terms of the relational model, then ORM object types are like Domains on which attributes are based, where the domains are semantic domains rather than the merely syntactic domains supported by most SQL systems.
For example, in UML or ER we might have a Class called Employee, with birthdate and hiredate as attributes. These attributes should be based on a Date domain or type. In ORM, we instead represent this example with two fact types: Employee was born on Date; Employee was hired on Date. ORM also requires value-based reference schemes for these object types. Here Employee and Date are object types, and "was born on" and "was hired on" are predicate readings. There are two roles (relationship parts) in this fact type, one played by Employee and one played by Date.
In ORM, a fact type must have at least one predicate reading, but role names are optional. If you consider binary fact types only, and name a role, then in one sense you can think of that as naming an attribute of the object type that plays the other role. For example, I might name the roles played by Date in the two fact types above as "birthdate" and "hiredate". This can be handy for specifying rules in FORML in "attribute-style", e.g. For each Employee, hiredate >= birthdate.
In principle, you could name the roles played by Employee as "employeeBornOn" and "employeeHiredOn", and think of them as multi-valued attributes of Date, but this is unnatural. As an aside, one of the annoying aspects of UML is that in that UML requires every role (association end) to have a name. Having to invent a meaningful role name can sometimes be challenging and unnatural.
For example, consider the following two associations in UML:
Person is brother of Person; Person is mother of Person.
Here Person is a class, and all four roles must be named. It's easy to name the left-hand roles (e.g. "brother", "mother"), but the right-hand roles are awkward and unnatural to name (e.g. "siblingOfMale", "childOfFemale"). ORM avoids such impositions on the modeler by not forcing you to name roles (because you can always navigate using predicate readings instead).
Note that roles in unary fact types (e.g. Employee smokes), roles are not attributes at all, even though you can transform a unary to a binary (e.g. Employee has SmokingStatus) where one could treat a role as an attribute.
If you name roles in ternary or longer fact types (e.g. Company supplied Product to Customer; Person introduced Person to Person), these may be thought of as "attributes" of the whole relationship (which may be implicitly or explicitly objectified), rather than as attributes of one of the participating object types.