The case for keys (and against InverseFunctionalProperty)

IMHO  OWL's  InverseFunctionalProperty  is confusing
and dangerous, and ought to be eliminated (in favor of keys, which
are straightforward).  Here is an example of the problem:

Suppose I have an OWL-lite employee database with class
Employee and property 'hasSSN' (social security number).
'hasSSN' is a key for this class, so I declare statements that
include the following:

    Employee rdf:type rdfs:Class
    hasSSN rdfs:domain Employee
    hasSSN rdf:type InverseFunctionalProperty

Now I decide to build another class, EmployeeHistory,
which has data about employees, indexed by SSN
and date.  Should I reuse the 'hasSSN' property, or invent
a new one?  I decide that it would be hard for users to 
remember which was which if I have two different 
properties to point to SSNs.  However, I need to widen
the domain of 'hasSSN' if I want to attach it to EmployeeHistory
as well as Employee.

If I'm using OWL-DL, I could replace the domain statement by
a restriction.  If I'm using OWL-cool, I could switch to subdomains.
But, I'm using OWL-lite,  so I guess I'll use the blank node trick:

    Employee rdf:type rdfs:Class
    hasSSN rdfs:domain _:domainOfHasSSN
    hasSSN rdf:type InverseFunctionalProperty
    Employee rdfs:subClassOf _:domainOfHasSSN

    EmployeeHistory rdf:type rdfs:Class
    EmployeeHistory rdfs:subClassOf _:domainOfHasSSN
    hasDate rdfs:range Date
    hasDate rdfs:domain EmployeeHistory

Oops, almost surely I want to widen the domain of 'hasDate' as well.
Pretend that I use the blank node trick for that as well.

Now I'm happy.  Or am I.  Turns out that I have unwittingly screwed
up badly, because while 'hasSSN' is a proper key for Employee, 
EmployeeHistory needs to have either no key at all, or have 
the compound key  <hasSSN, hasDate>.

Summarizing, InverseFunctionalProperty is confusing, may 
be misused, with serious consequences, and if used properly,
may cause ontologies to become unnecessarily bloated.

Suppose instead we had a property  owl:simpleKey. If I assert

     Employee  owl:simpleKey  hasSSN

this means that no two distinct employees can have the same
value for the attribute  'hasSSN'.  Almost the same thing
as if I used InverseFunctionalProperty, except that the
restriction attaches to the class instead of to the property.
Hence, my EmployeeHistory class is not impacted by
my asserting a key for the class Employee.

Of course, I'd really like to be able to assert the compound
key restriction for EmployeeHistory.  I'll leave that as
an exercise (as I did before).

Cheers, Bob