Page Comparison

...

No, not as long as there is another collection to incorporate or another system to integrate. Having the building blocks of the Id OSID and Ontology OSID incorporated into the application is helpful in dealing with many of the common integration problems often ignored until we have a pile of unmanaged codes and a bad software investment to interpret them.

Retrospective

1. Most Many people think in terms of data fields so codes make sense to them. Incremental development quickly runs into a brick wall because the first iteration stores and retrieves the data field. This is followed by the need to normalize, automate, delegate, and group this information and the "just a data field" approach doesn't hold up.
2. A code that doesn't uniquely define an entity in its own domain is an entity relation. In the OSIDs this is often the Subject in an Ontology OSID. Having one of these in your toolkit can help get here easier and greatly simplify the addition of other classification or tagging schemes.
3. It's easy to chase symptoms of other problems and solve those. In this case, the code was a solution to the problem of location and was expanded to solve the problem of validation. The project began by solving the problem of the code without questioning its purpose. Any new system does things differently than old systems (else we just be rebuilding the same thing over and over again). So, it's important to get to root problems to the business and see how a new framework can address them directly.
4. The service architect took risks in expanding development scope. It can be a difficult set of changes when working with existing code and assumptions but laying out the design based on a longer term view can help set expectations and establish an incremental development approach along this path.
5. The OSIDs aren't very clear in this area. 
   1. The OSIDs surface the concept of Id aliasing in each admin session, but functionality is limited such that heavy lifting requires the Id OSID. 
   2. A small set of OsidObjects define codes, but he semantics are unclear. Often they are numbers or some other mnemonic that is more universally appropriate and not a "tag" or alternate "identifier" that needs qualification. 

...