Hi Mark,
What about when the repository is being used instead of a database? User stores a bunch of contacts User stores a bunch of buildings User wants to link each building to a contact. Different buildings may want to refer to same contact.
From my gut feeling I would recommend something like...
/buildings/mainbuilding /buildings/th14 /buildings/th5 and /contacts/jack /contacts/joe /contacts/jill where the contacts have a multivalue "name" property called "buildings" containing strings like "mainbuilding", "th14", ... This is working off the assumption that the buildings are more static/stable than contacts. So I would choose the "link" pointing to the buildings. The reason why I chose a "name" property rather than a "reference" is really because I think the application could gracefully fail a dangling link to a building and because i think that the list of buildings is very static. Opposed to a "uuid" stuck in a reference the string "mainbuilding" will mean something to someone looking at it.
Isn't this a perfect use case for using a reference?
If your application cannot afford dangling references and the building names are dynamic I would employ references. I think it is important to think about the other options that a content repository offers to link content before defaulting to the most rigid and expensive one (which is a reference). regards, david
