AIRS XML Capability

Several years ago AIRS embarked on a project that would hopefully provide a vehicle for the different I&R software system to share resource data regardless of the I&R software's data structure.   From this project came the AIRS XML Data Transfer protocol.  The current AIRS XML Transfer protocol is based on the ServiceSite data structure, which by the way was the best possible choice.

Approximately four years ago, four I&R software vendors were paid $4000.00 each by the United Ways of Michigan to implement import and export utilities in their software system (RTM Designs was one of the four) using the AIRS XML Transfer protocol with the stipulation that the functionality be finished within six months of receiving payment.

When evaluating I&R software systems, be sure to have each vendor display how the user's of their software can import and export data using the AIRS XML transfer protocol.

RTM Designs Position

It's RTM Designs opinion that the AIRS XML Data Transfer protocol is a marvelous tool.  In the near future all RTM Designs software will use this protocol as the sole importing and exporting tool for resource data.  

RTM Designs was also the first and only vendor to offer a user operated AIRS XML importing and exporting feature in the software within the agreed time frame of six months.   It is also the opinion of RTM Designs that as of this writing  (8/4/2006), no other I&R software vendor offers a user operated AIRS XML Data Transfer import and export utility.  (One has to wonder if these vendors returned the $4000.00 to the United Ways of Michigan).

RTM Designs has studied and experimented with the XML protocol since it's inception in order to validate the possibility of having a successful exchange of data from another non-RTM Designs software systems.  

When possible, RTM Designs would downloaded XML data dumps from the XML committee's web site in order to test the XML import functionality.  In other cases RTM Designs had to develop XML data export utilities for other I&R software systems when an export (data dump) wasn't available.   

As of this writing, RTM Designs has experimented with exports from IRis, Resource House, Service Point, Tapestry as well as our own software systems.

With the exception of importing data from another RTM Designs system, results weren't promising.

Due to the vastly different data structures utilized by the various I&R software vendors, it is virtually impossible to import data from another vendor's software without seriously compromising the integrity of the destination database (the destination database in this case being an RTM Designs ServiceSite database).

Inversely, importing data into an Agency-Program database from a ServiceSite structured database resulted in a loss of critical data items. Once again the integrity of the destination database was compromised.

Further testing revealed more obstacles.

1.   The differences in geographic systems employed by the various I&R software vendors made accurate Area Served translation impossible to reconstruct.  Some vendors offer "User-defined" geographic systems or have no structured Area Served searching component therefore leaving it to the whim of each user to use or not to use some sort of geo searching functionality.  This will also make it impossible for a vendor to accurately exchange data between their own systems. 

The merged database will be riddled with False Negative and False Positive search results.

2.  Taxonomy Level Coding differences provide another obstacle when merging data, Once again, for most I&R systems merging data, the service search quality will suffer.   This problem is has more to do with the differences in resource maintenance practices at the individual I&R organizations than with the data structure.    While RTM Designs software offers the "Virtual Term" search methodology which minimizes the negative impact of a merged double indexed database, all other I&R system don't offer this feature.

3.  Missing Data is another major issue when import data form a dissimilar database structure, as found when importing data from an Agency-Program database into a ServiceSite database.   In simple terms, an Agency-Program database offer two levels of data (Agency and Program). A ServiceSite database requires four levels of data.  Where are the two other data levels?   

Importing of data from a ServiceSite database into an Agency-Program database requires putting four levels of data into two.  The only option in this case is to exclude data - not a good idea.                    

Previous                                             Start Over                                           Next