Here’s something I wish I’d known at the start: it’s ok to delete all the default objects and attributes from the metaverse, and just create the ones you need.
And here’s something else I wish I’d figured out earlier: you need less object types in the metaverse than you may think.
When I first started with MIIS I thought it safer to use the existing schema until I got a bit more used to it. But this meant I was doing things like flowing StudentNumber to employeeID, PhoneExtension to telephoneNumber and Surname to sn. Once I got the hang of things a bit more I realised the whole tangle would have been much clearer if I’d just named the metaverse attributes exactly as they are in the source.
The next thing I got hung up on was the object type in AD. Some people were going into AD as Users, and some as Contacts. I thought this meant I had to have object types of “user” and “contact” in the metaverse (though actually I used the default “person” object for users because I was too paranoid to delete it, and then created the extra “contact” object).
The big problem this caused me should be pretty obvious: what to do when someone needs to change from being a User to a Contact? And apart from that it was short-sighted of me. MIIS quickly became joined to systems apart from AD, and a person could be connected to a variety of Connector Space object types, such as inetOrgPerson, record, homedir, nisMailAliases, website. Why, with all this going on, did I want to shackle the metaverse schema to one particular CDS?
The happy ending is that I did, before it was too intimidating to back out, see the light and recognize that a person is a person, whatever objects their Metaverse representation may be joined to about the place. After that my metaverse schema got real simple – just two object types: “person” and “group”, with most of the attributes clearly named after their precedent data source.
