2.6.1 How do you replace the geopolitical tables?
In previous versions of PPDM, there were a whole bunch of tables that captured geopolitical areas.  We know them as countries, provinces, states, city, districts.  Well, that's a pretty limited list and it's really orientated on the North American naming model.  Here is a snippet from Wikipedia on the following term: 'List of Countries' or at this web page: http://en.wikipedia.org/wiki/List_of_countries  
So, you can see that a series of tables could be created called R_NATION, R_FEDERATION, R_AUTONOMOUS_AREAS, etc.  And no matter what you do, it's not viewed as correct in a different part of the world.  And that's okay. Because it's just semantics.  And semantics aren't that important, are they? :)
What to do?  Well, I believe that the PPDM has come up with a pretty good solution.  It involves the Area & Area_Contain tables and how you set them up.  First of all, let's look at the basic structure of the Area table.  The basic column structure is:
The primary key is composed of the first two columns; Area_ID & Area_Type.  Area_Type is a foreign key from the R_AREA_TYPE table and the key to this.  It's here where you can store the different values, like country, nation, federation, etc.  Put in whatever you want.  Now, to store it in the AREA table, you need to decide if you are going to use real values/names for the Area_ID column.  The column length is 20 characters and I have found that you will always find a value that is 21 (or greater) and then what do you do? My preferred method is to create a sequence (in Oracle) and just assign a surrogate key to this column.  The real key is storing the full name in the Preferred_Name column.  It's 255 characters and that should be big enough for everyone.  
Now that you have this table populated with regions and continents and countries and provinces and cities and districts and fields and geological areas and whatever else you want, you want to relate them.  How?  Well the AREA_CONTAIN table is just the item for you.  It's key structure:
shows that you can relate any area_id/type combination to any other one. Think about that.  It's limitless.  So you can create your own hierarchy of anything; say country --> province,  province --> city, field --> pool, region --> continent, geological basin --> field;  it's limitless.  Now, to relate these data entities, like facilities, fields, land, production entity, well, etc there are a series of tables that are basic cross references between AREA and the data entity.  Here is a list of some of the tables:
I think a bigger issue here might be working with existing applications or mind sets that want or need to see a table called R_COUNTRY or R_PROVINCE_STATE.  Well, here is a trick on how to create that object. Create it as a view that is built on the AREA table.  For example, if we wanted to create the R_COUNTRY object, the view would look like this:
create or replace view r_country as
 substr(preferred_name,1,20) country,
       substr(preferred_name,1,12) abbreviation,
       preferred_name long_name,
       substr(preferred_name,1,30) short_name,
from area
where area_type = 'COUNTRY'
That's it.  Now, if your application requires that it Insert, Update or Delete Countries, you would have to write the correct trigger for it, but it can be done.  Even delete, but you would have to walk the AREA tree to make sure that you deleted all occurrences in all of your tables that have a Foreign key from AREA.  That's a tip for another day.
So, armed with this knowledge, it should be no problem for you to go through and create views for the following list of deprecated tables.
By the way, that's not a complete list.  If you want to see the complete list, query the PPDM_GROUP_OBJECT table with the Group_ID of 'DEPRECATE'.