On Roles, Attributes, and Definitions

Dave Hay commented on my post How Many Attributes Do I Have?  Dave notes that there is a difference between me and the roles that I play.  This is an important point that I struggled with previously.  Dave states "most of the examples are attributes of my role as a customer", meaning the examples I provided in my post.

"Role" is a term that gets bandied around a lot in data modeling.  In my previous post on Role vs. Relationship I argued that roles really refer to certain kinds of relationships.  However, Dave's point is one that I have heard on a lot of occasions and has to be taken seriously.

Let's state the question this way: is the attribute Customer Lifetime Value to Hardbitten Liquors an attribute of me, or an attribute of my role as a customer of Hardbitten Liquors?  And if the latter, just what do we mean by "role".

There is no doubt that I am an instance of a concept.  The concept is human being.  Further, Customer Lifetime Value to Hardbitten Liquors can be predicated of me, strongly suggesting it is an attribute I possess.  

But now let us think of the role that is being suggested in this discussion.  What is it?  Is this role "Customer of Hardbitten Liquors"?  If so, I would argue that this is a relationship between me and Hardbitten Liquors.  And if an entity type has attributes, and relationships do not, then we cannot say that a role has any attributes.

But suppose Dave is right and the role does have attributes.  It will have to be an entity of some kind.  What other thing could the role be - apart from "human being".  There is a possibility.  Suppose I only ever bought one bottle of Grandpa's Tipple from Hardbitten Liquors.  Then, my entire relationship with Hardbitten Liquors could be encompassed by this one event - the purchase of this one bottle.  Now, Purchase is an entity type, albeit non-material, so it can at least be a candidate for the role.

But can Purchase really be the same as role?  I do not think that an event can have an attribute such as Customer Lifetime Value to Hardbitten Liquors, which really refers to the individual customer.  And I do not think this can be true of any aggregate of instances of Purchase events either, supposing, for instance, that I buy one bottle of Grandpa's Tipple every week.  

So if role is not to be identified either with me or my purchases, what other entity types can it be identified with?  I need to do some more research to be able to answer that.  However, for now I am still going to stick with attributes like Customer Lifetime Value to Hardbitten Liquors as being an attribute of me.  So my original point provisionally remains: a concept can have a vast number of attributes and some methodology is needed to decide which ones to include in a definition.

Role versus Relationship - What Does it Mean for Definitions?

A couple of days ago I was reading some material on a semantics product and came upon the term "role".  We see role used in data modeling where a primary key migrated into a child entity can be assigned a "role name".  This is the name by which the attribute is known in the child entity, and is useful to disambiguate the same attribute migrated for other relationships between the same two entities.

You also hear about "role" in the party model.  Rather than say that Unindicted Broker is a client of Overleveraged Bank, and that Unindicted Broker is a prime broker for Overleveraged Bank, we can say that Unindicted Broker is a party that plays two roles with Overleveraged Bank: (a) client; and (b) prime broker.

I think that there are deeper issues here.  We think of a relationship in a data model as a line between two entities.  We cannot allocate attributes to the relationship as we can to entities.  Our notations, methodologies, and tools will not allows it (at least the commonly used ones).  Furthermore, it is relatively rare to find multiple relationships between the same entities.  When we do find quite different relationships between the same two entities we seem to start thinking of roles.

Now, a relationship is a concept, and therefore must have a description and hopefully a definition.  If a relationship can have a definition, it must have characteristics (qualities, i.e. attributes). This worries me somewhat as relation and quality are two Aristotelian categories and one should not be reducible to the other.  However, I cannot find the theoretical foundation for what I am describing.

A further issue is that what we are calling a relationship such as "Unindicted Broker is a client of Overleveraged Bank" is a generalization about a lot of processes.  Unindicted Broker had to be solicited to be a client, then onboarded as a client, and then assessed in terms of how the relationship would be managed.  All of these processes come under the umbrella of "Unindicted Broker is a client of Overleveraged Bank" but break down to many more detailed entities and relationships. So "Unindicted Broker is a client of Overleveraged Bank" is a generalization, although it is valid.

So where does this leave us?  Not very far I am afraid, but we can begin to see the outlines of the problem.  The term "role" is used in semantics, but it is not clear if it is used technically or informally.  "Role" exists in data modeling, but is for refining names of attributes associated with relations.  And "role" exists in the party model, for "high-level" relationships.  There is some evidence that relations can be broken down into more detailed entities and relations that may serve to describe a role.  Ultimately it does seem that roles can be resolved into sets of entities and relationships at the data model level.  However, at the level of semantics it is not clear how they can be treated as other than relationships.

A role does seem to demand a definition that is greater than what is to be supplied for a "regular" relationship.  A role must be distinct from other roles, or you could argue it should be collapsed with its sibling roles into one role. So at least we can conclude that if we have identified a role we need to provide it with a good enough definition to provide such distinction.  Obviously, there is a lot more to this, but that is enough for now.