It's a problem that has frustrated me also. Despite the option for "relational storage" whose meaning still escapes me, I haven't seen any clean way to create a foreign-key relationship between two classes. The usual way to do this in relational databases would be to duplicate the fields comprising the primary key of the Person relation/class in the Media class, thus making it a foreign key. Formally speaking, this is the correct way to do it; several practical problems present with this approach, however: * first, it's wasteful - though RDBMSs routinely do it, they are also optimized for it; * second, because XWiki classes are, effectively, dynamic or virtual "relations" and not true database-table relations, the DBMS's referential-integrity mechanism can't be called into play, necessitating added template code if referential integrity is desired; * third, as a result of the first two, there is added coding effort, which leads to increased risk of errors, which requires added time for test planning and execution, all for a solution that costs more at runtime. What I have done in one case is a hack that I'm sure will come back to haunt me, unless one of the developers can assure me that this implementation-specific feature is likely to stay: I made a field in the "child" or referring class (like your Media class) of the same type as the ID field from the xwikiobjects table, so that I could link it, not to a value or a primary-key-composing collection of XWiki object fields, but to an actual XWiki object. No referential integrity or type safety is included with this, but these can be achieved with generic code that can be written - and tested - once, and though the runtime penalty doesn't go away, it is reduced. I hope some day soon to investigate adding a new entry to the xwikiclassesprop table, with a custom property class to do all of this. Its property type would be "XWiki object"; it would have a field naming the XWiki class of the object, and its value field would be of the same type as the xwikiobjects table's xwo_id field. The display modes would effectively work like a dblist field, displaying the keyfields of the target object but storing its ID field. How to specify the primary key fields of the referenced object is problematic, and I would like to see it supported by XWiki natively in the class editor, along with the usual null-value-permitted option and whether the object's containing document should participate in the primary key (to allow choosing whether a combination of values must be unique globally or only within a document. In this way, it would be possible to add a reference to an XWiki object of a given class as a field in another XWiki object. That, of course, brings up the question of subclassing or inheritance, but I'll save that for another time - what I think it would require is the ability to add a reference to another XWiki class to a class definition, causing the referred class's properties to be imported into the referring class's definition. In the meantime, however, is there anyone who can provide some tutorial material on how to extend the property classes? This would help make "some day soon" come sooner... brain[sic]