I'm modelling a class diagram and I'm absolutely stuck with this issue:

My new web application has "cards" (entries about a subject) which can be modified by the users, à là wiki. But unlike wikis, different cards hold different data. Also unlike wikis, cards are interrelated with other cards explicitly in the database. Let me show you how I initially designed it using a dummy example:

```
/** Similar to strategy/bridge pattern */
class Card<T extends CardInfoVersion> is composed of T // container of versions
class CardInfoVersion // one version
class Painting extends CardInfoVersion 
class Museum extends CardInfoVersion is composed of Paintings

```

Elegant, clean, but **wrong**. Using this approach, **museums are tied to painting versions, not to the painting itself**. The first solution that came off my head was this one:

```
class Card<T extends CardInfoVersion> is composed of T
class CardInfoVersion
class Painting extends CardInfoVersion
class Museum extends CardInfoVersion is composed of Card<Painting>

```

This approach smells. Class hierarchy under CardInfoVersion is huge, so UML model would be unreadable and Card class would be filled with ORM references to CardInfoVersion subclasses. Then I came up with this:

```
class Card is composed of proposedModifications: Set<Card>
class Painting extends Card
class Museum extends Card is composed of Paintings

```

Which also smells. In fact, this is all messed up since the version vanishes. It also requires administrators to validate proposed modifications to cards.

I don't really know how to solve this problem. **Remember: original design would be OK if CardInfoVersion subclasses weren't interrelated.**

Please help!