Is a Relationship Just a Special Case of an Attribute?

Lets look at the properties that define an attribute as opposed to a relationship to see how well they combine:

Attribute ::= Name [ShortDescription] DataType Required
Relationship ::= RelatedObjectName Required Multiple Composed

The RelatedObjectName really maps to the data type of attribute. Relationships typically don’t have a short description (which is fine as it is optional for attributes). They both have “Required”, and attributes could usefully have a Multiple for some use cases to distinguish between single and multiple selects within value lists. Attributes are by definition composed (delete an object and it’ll delete its attribute values) and you could add a Name to a relationship – perhaps driven by descriptive purposes, so a User might have a WorksFor attribute with a data type of Company. In short, there are enough similarities between the initially proposed concept syntaxes that it would be possible to combine them. Interesting . . .

The next question is how you would distinguish attributes from relationships for the operations that might only be performed on one or the other. If you had a list of object names, if there was never a custom data type with a name identical to that of an object, you could figure out fairly easily whether an attribute was pointing to an object or not, but I’m not sure that would be a good limitation, so I’d probably want an Object Boolean to distinguish relationships from attributes.

So, the data is similar enough that we could merge it, but we’re going to use a Boolean to distinguish the two types of attributes (looking at this from an object modeling perspective you might decide that conceptually PrimativeAttribute and ObjectAttribute both subclass an abstract Attribute class). The question then is whether there would be any benefits at all in going down from three concepts to two. How many operations would be perform on both attributes and relationships? Initially I can’t really think of many (the generation of getters and setters for attributes irrespective of data type is the one thing that comes to mind).

Another way of looking at this would be to distinguish between composed objects that from an OO perspective are really just attributes with a complex data type and associated objects that are something “outside” of the object they are associated to. However, while conceptually this is an interesting approach, the code you write to pull related object data is actually pretty much the same whether the object is associated or composed (the only difference is cascading deletes for composed objects) so it isn’t really as useful as other distinctions.

You could square the circle conceptually by imagining composed relationships to have a data type of the composed object(s) and associated relationships to have a data type of a pointer to the associated object(s) (we’re talking conceptual model here – the way most of the code base is implemented it won’t treat composed and associate objects any differently from each other except is a small set of special cases). However, I’m not sure that we get any benefits by doing so.

In the end, while it is interesting to consider the idea of treating relationships as a type of attribute, I don’t yet see any compelling benefits so I’m going to go with the standard convention in ODL of having Objects, Attributes and Relationships and I’ll just keep my mind open to refactoring the grammar if it makes sense down the line.

Anyone else got any thoughts on this?!