I think that's fine, Peter. I think it underscores our need to provide a simple, lightweight mapping solution in the future. One advantage of having a relationship type defined as an object is that permissions on types of relationships does make sense (think of a rating package and perhaps the desire to limit an entire class of ratings to, say, professors or students). One might not know in advance whether or not a future package customizer might want to do that ...
Perhaps there should be a couple of different mapping paradigms available, a heavyweight one like the current acs-rels (while having each row in the map be an object is annoying it does allow for extending the map with additional information) and a lightweight facility for basic mapping.
A major advantage of a centralized lightweight facility lies in maintainability. If 30 packages each have their own simple mapping tables that means we have 30 table names to remember, 30 (probably slightly different) sets of PL/SQL procs to add entries to remember (or you have to remember which packages just use "insert", which provide a Tcl API, which provide a PL/[pg]SQL API) etc etc.
Consistency is my main argument for central facilities of this sort. They certainly shouldn't be so complex and involved that writing 30 different mapping tables and APIs is easier than using the central facility. acs-rels probably isn't that bad but you get the idea ...
