Hi Dan,
representing the class hierarchy is not really the focus of Soplets for now, especially since enums do not support inheritance (much to my dismay...); but doing that with regular Java objects (as you do with Naked Objects) is just fine, often there is no need to replicate this semantic information in an additional metamodel.
For representing a relation between two classes, I just name the classname of the target type (interface or actual class), as an example see the customer field in SopOrder (I'm aware that this is not entirely type safe, but that is the best what you get with the current language spec):
https://github.com/sopletmaster/org.soplets.petstore/blob/master/src/org/petstore/soplets/SopOrder.javaRegarding your second question: Soplets do not provide a runtime object management on its own, they are conceived solely for the purpose of representing (static) semantic information. However, you can combine them with existing solutions like Hibernate. Just have a look at the SopOrder class mentioned above: there is a regular Hibernate annotation next to the Soplet annotation, which will be woven (via byte-code) into the getter method of the target entity, and acts just as you would expect it.
@ManyToOne( //this annotation will be woven into the MOrder class
targetEntity=MCustomer.class)
Of course, the information "targetEntity=MCustomer" is a duplicate of the "javaType=MCustomer.class" attribute of the regular Soplet annotation below. In that sense I'm envisioning an run-time adapter which would translate the Soplet metadata to Hibernate semantics, so the additional Hibernate annotations could be dispensed of eventually.
Did that answer your questions?
regards, Chris