A AcDbBlockTableRecord will be the TYPE of OWNER of all things graphical.
Now for a little lesson in CLASSICAL INHERITANCE. I'm sure you're familiar with inheritance, so I won't go into the nitty gritty, however, when designing class heirarchies, it's often useful to SAY your inheritance out loud to see if it makes sense.
For example, let's say we have 3 classes - 1 base class, called CAR, and 2 derived classes called SPORTSCAR and FAMILYCAR. SportsCar and FamilyCar both derive/inherit from Car. In classical inheritance, you can now say, a SportsCar is a type of Car, also, a FamilyCar is a type of Car. However, you could not say a Car is a SportsCar nor is a Car a FamilyCar...it doesn't make sense. Does that make sense?
Right, back to our little problem. I said above an AcDbEntity is graphical, but......an AcDbObject is not! Now seeing as everything graphical must have an owner of type AcDbBlockTableRecord, which in turn derives from AcDbSymbolTableRecord, which in turns derives from............AcDbObject!!!
Now, is an AcDbBlockTableRecord a graphical entity? No it certainly isn't. So, in your function, you could specify the return type as AcDbBlockTableRecord or, more generically, as AcDbObject and cast appropriately.
Apologies for the hasty reply, but I've just gotten up, am hungry and going for breakfast.
Cheers,
Glenn.