Metaverse Design and Attribute Names

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”; “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 they 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.