In testing, I realized that it makes sense to be able to assign subjects to image groups. For example, I have an image group from the time I spent in Los Angeles. All of those pictures should have Los Angeles as a subject, so it makes sense that they should inherit the subject from the parent group. A defining image for an image group doesn't sound like a bad idea, either.
I've spent a lot of development time recently thinking about the interaction of PhotronObjects and Collections. I've also been thinking about how Collections interact with StorageMangers and the GUI through the CollectionManager. My current thinking is that all PhotronObjects should be created by the Collection object, which would imprint each with an underlying Resource node in the collection model. From that Resource node, it should be possible to detect all existing properties (if, for example, the Collection model is being loaded from a persistent source). PhotronObjects, then, aren't tied to the GUI, which is a lot more logically consistent than what I was trying to do before. The CollectionManager will handle all of the GUI mojo, and the StorageManager attached to the Collection will handle loading and storage of all of the image data. PhotronObjects will never have to make references back to the model or collection, since they'll be in control of their own resource nodes.
All of this also greatly simplifies the job of the StorageManagers and the CollectionManager. The StorageManager interface will need to handle fewer events, and the CollectionManager will be much less tightly bound to the Collection.
So here's a thought: rather than having PhotronObjects hang onto a reference to a Resource object, why not have PhotronObjects simply extend Resources? At a first glance, it seems logically consistent. PhotronObjects are just representations of a node with attached properties. All of the methods within a PhotronObject are centered around manipulating the underlying node's properties. Turning PhotronObjects into descendants of Resources would also mean that they could be (more practically) direct objects of properties.
I'll have to think about this one a bit to make sure that it's actually something worth doing, but I can't think of any disadvantages that don't already exist as a result of holding on to a reference to a Resource. The only thing I'm really worried about is constructing new PhotronObjects, since Jena [intentionally] obfuscates the creation of Resources a bit, and I'm not really sure what's involved in extending them.
I thought of this just after writing the previous entry: Jena Resources are interfaces, not classes. It's therefore impossible to extend one, and PhotronObjects therefore need to keep a reference to the underlying Resource.