AIRS Style Guide – Resource Specialist Version
Final: August 2009
COPYRIGHT Ó 2007 and 2009 by the Alliance of Information and Referral Systems (AIRS). All rights reserved. No part of this publication may be reproduced in any form or by any means without the express written permission of AIRS, except for the nonprofit purpose of education, and scientific advancement.
AIRS Style Guide
Scope of the AIRS Style Guide 5
Benefits of the AIRS Style Guide 6
Principles of AIRS Style Guide 6
Software Variations 7
I&R Database Structures 8
Data Structure: Agency 9
Data Element: Agency – Unique ID Number (Key) 11
Data Element: Agency – Record Ownership Code 12
Data Element: Agency – Agency Name 13
Data Element: Agency – AKA (Also Known As) Names 16
Data Element: Agency/ Phone Number(s) including Extensions, Phone Types and Phone Functions 18
Data Element: Agency – Web Site(s)/URL(s) 22
Data Element: Agency – E-MailAddress(es) 23
Data Element: Agency – Name and Title of the Director or Administrator 24
Data Element: Agency – Description 26
Data Element: Agency – Licenses or Accreditations 27
Data Element: Agency – IRS Status 28
Data Element: Agency – Federal Employer Identification Number (EIN-FEIN) 29
Data Element: Agency – Year of Incorporation 30
Data Element: Agency – Annual Budget Total 31
Data Element: Agency – Legal Status 32
Data Element: Agency – Source of Funds 33
Data Element: Agency – Date of Last Interim Modification/Partial Update; Contact for Updating Purposes 34
Data Element: Agency – Exclude from Web Site 36
Data Element: Agency – Exclude from Directory 37
Data Structure: Site 38
Data Element: Site – Unique ID Number (Key) 40
Data Element: Site – Site Name 40
Data Element: Site – Description 41
Data Element: Site – AKA (Also Known As) Names 42
Data Element: Site – Street/Physical Address 42
Data Element: Site – Mailing Address 47
Data Element: Site – Other Addresses 48
Data Element: Site – No Physical Address 48
Data Element: Site – Phone Number(s) including Extensions, Phone Types and Phone Functions 49
Data Element: Site – Web Site(s)/URL(s) 49
Data Element: Site – E-Mail Address(es) 50
Data Element: Site – Name and Title of Site Manager 50
Data Element: Site – Administrative Hours/Days of Operation 51
Data Element: Site – Physical Access 53
Data Element: Site – Travel Information 54
Data Element: Site – Languages 57
Data Element: Site – Year Incorporated 57
Data Element: Site – Annual Budget Total 58
Data Element: Site – Legal Status 58
Data Element: Site – Exclude from Web Site 59
Data Element: Site – Exclude from Directory 59
Data Structure: Service/Program (SiteService) 60
Data Element: Service/Program – Unique ID Number (Key) 63
Data Element: Service/Program – Program Name 63
Data Element: Service/Program – Service Group Name 64
Data Element: Service/Program – AKA (Also Known As) Program Name 65
Data Element: Service/Program – Service Group Description 65
Data Element: Service/Program – Hours of Service 68
Data Element: SiteService/Seasonal 68
Data Element: SiteService/Not Always Available 69
Data Element: Service/Program – Phone Number(s) including Extensions, Phone Types and Phone Functions 69
Data Element: Service/Program -- Eligibility 70
Data Element: Service/Program – Target Populations 72
Data Element: SiteService/Age Requirements 72
Data Element: SiteService/Gender Requirements 73
Data Element: SiteService/Family Requirements 73
Data Element: SiteService/Income Requirements 73
Data Element: SiteService/Residency Requirements 74
Data Element: SiteService/Other Requirements 74
Data Element: Service/Program – Geographic Area Served 75
Data Element: Service/Program – Application/Intake Process 77
Data Element: Service/Program – Documents Required 78
Data Element: Service/Program – Fee Structure 79
Data Element: Service/Program – Taxonomy Term(s) 80
Data Element: SiteService/Resource Info 81
Data Element: Service/Program – Web Site(s)/URL(s) 81
Data Element: Service/Program – E-Mail Address(es) 82
Data Element: Service/Program – Title of the Service Contact Person 82
Data Element: Service/Program – Service Capacity and Type 83
Data Element: Service/Program – Method of Payment Accepted 84
Appendix A: Preferred Human Services Spellings and Usages 85
Appendix B: Preferred Language Spellings 92
Appendix C: Official Post Office Abbreviations 99
Scope of the AIRS Style Guide
q The AIRS Style Guide is a collection of recommended best practices rather than a set of prescriptive (or absolute) solutions and as such may change over time.
q If a state/provincial collaborative (or an individual agency) has invested significant resources in setting up their own style guide, there is no reason to change to the AIRS model. I&R agencies are free to extract any portions of this Style Guide that meet their needs and to ignore one that do not.
q The AIRS Standards continues to require the use of a style guide, not the use of a specific style guide.
q The AIRS Style Guide uses, for a base, the field structure of the AIRS XSD. In a few instances, data elements might not be included in the XSD, or elements may be in the XSD that are not standard I&R concepts but are needed to tie objects together
q The development of this Style Guide was overseen by a team of experienced Resource Specialists from across North America. Style is often a subjective matter. In this area, there is rarely a decision that can ever be unanimous. There is often no inherently “right” way to style a certain data element. There is, however, a right way to apply those decisions, once made, as consistency as possible.
q Visual inconsistency is often most apparent in service description fields with some agencies using formal sentences and others using point formats. When the databases are merged, it makes it more difficult for users to understand. The AIRS Style Guide attempts to provide some suggestions for the creation of “good” service descriptions.
q The AIRS Style Guide includes guidance on organizational naming conventions. However, every “rule” in this area, inevitably results in some local exceptions.
q Appendix A includes a “preferred language” guide (for example, when to use drop in and when to use drop-ins; child care instead of childcare; southwest instead of south-west, etc.). This language guide is edited by Georgia Sales in order to align it as closely as possible with the preferred style language within the AIRS/211 LA County Taxonomy.
q Appendix B includes a guide to language usage (for example, using Farsi instead of Persian, using Pashto instead of Pushto, etc.).
q Appendix C contains a listing of postal abbreviations for states and territories, and Canadian provinces and territories; together with a listing of official abbreviations for mailing addresses.
Benefits of the AIRS Style Guide
q There is a need to establish material that clearly outlines quality expectations.
q There are not enough dedicated resource managers or skilled resource staff to consistently devise local quality solutions. People need to better understand what is involved. The AIRS Style Guide documents practical suggestions to database editing issues, so that those looking for off-the-shelf guidelines will not have to start from scratch in making those decisions.
q As I&R and 2-1-1 grows, access to other databases and the ability to search them effectively becomes more important, especially in disaster scenarios. Consistency of data entry helps.
q When promoting public online databases that involve resource material maintained by different organizations, variations in style make the data appear disorganized and confusing. Even if the information is correct, the overall look can diminish its credibility for public use.
Principles of AIRS Style Guide
The following factors are all influences on style issues and decisions, and are listed in an approximate order of importance. All of these factors are important but sometimes they might also be contradictory. For example, a desire for brevity may be countered by the need for clarity of meaning.
q Clarity.
q Accessibility. Resource information should be understandable to as broad a section of the public as possible. Information should not be only comprehended by people with higher literacy levels.
q Ease of training. Training needs must be recognized. The more complicated an option, the harder it will be for people to understand and implement.
q Brevity/concision.
q Naturalness of language.
q Accuracy in the sense of containing enough breadth and depth of information for an informed decision. It is possible to be too concise.
q Consistency. But consistency for a purpose.
q Relevance. Sometimes a “lesser” field may not be worth a vast amount of investment of time and effort to attain perfection.
q Consensus does not mean correctness. Even if a clear majority of existing style guides have made a particular decision about a data element, it does not necessarily mean that this must be deemed as the best solution.
Software Variations
Notwithstanding this Style Guide, every I&R agency will invariably still require their own style manual or similarly named document, as every I&R software program differs in the fields that it provides and the manner that it handles different data elements/database fields.
The most obvious variation concerns the ways in which database records are constructed in terms of the data relationships between agencies, their site(s) and their services/programs.
Internal database administrative policies and procedures may also influence the area of database style.
Data Elements/Data Fields
These two terms are sometimes used (even in this document) interchangeably. But they are different in meaning.
Data elements refer to specific kinds of information (for example, a “mailing address”) while data fields refer to what have been decided as the “containers” in a specific database for one or more specific types of information.
In some cases that “container” (that is, a data field) might contain a single data element (for example, when the data element “mailing address” is contained in the data field “Mailing Address”). In other cases, a single data field may contain more than one data element (for example, the data elements “service capacity” and “source of funds” may both be included within a data field called “Service Description”).
The AIRS Standards only deals with “data elements” (whether required or recommended) and leaves decisions as to how that information is incorporated into a database to the individual I&R agency based usually on the database design of their I&R software.
I&R Database Structures
The AIRS XML Schema is used to facilitate data exchange, particularly among users of different I&R software programs. An I&R provider could export their Resource Data using this format if their software supports this option. The export creates an XML (Extensible Markup Language) document which contains information structured in a certain way so that data can be imported with greater ease than if an XML Schema were not used.
The AIRS XML Schema defines the elements that are expected from a resource database and the format and/or content of the information.
The AIRS XML Schema is structured so that each Agency (usually defined as an independent organization) has at least one Site (a physical location which provides a service), and at least one SiteService (a way to link a service or program to a site).With AIRS XSD 3.0 all Services are tied to the physical location where it is offered. Therefore if and Agency has two site that offer the same service, in AIRS XSD 3.0 the format would be one Agency with two Sites and each Site would have SiteService that described the service.
Data Structure: Agency
Definition
An agency is a legally recognized organization, either incorporated or a division of government, that delivers services. An agency can be incorporated, a division of government, or an unincorporated group that offers, for example, a food pantry or support group. The agency is the main location of the resource where the administrative functions occur, where the organization’s director is generally housed and where it is licensed for business. An agency may or may not deliver direct services from this location. On occasions, I&R services may choose to designate a middle level of the organization as the agency. For example, a city Department of Human Services may offer hundreds of services but is often recognized by the names of its component programs: Social Services, Health Department, etc. It is acceptable to use those components as agencies as long as their relationship to the larger Department of Human Services is acknowledged in the description or by the way the database is structured.
Summary of Agency Data Elements
AIRS Standards Name / AIRS Standards Requirement / AIRS XSD NameUnique ID Number / Required / Key
Record Ownership Code / Required / Record Owner
Agency Name / Required / Name
AKA (Also Known As) Names / Required / AKA
Phone Number(s) including Extensions, Phone Types and Phone Functions / Required / Phone
(See full information for more details on structure on Phone)
Web Sites/URLs / Required / URL
E-mail Address(es) / Required / Email
Name and Title of the Director or Administrator / Recommended / Contact (See full information for more details on structure of Contact)
Agency Description / Required / Agency Description
Licenses or Accreditations / Recommended / License Accreditation
IRS Status / Recommended / IRS Status
Federal Employer Identification Number (EIN/FEIN) / Recommended / FEIN
Year of Incorporation / Recommended / Year Inc
Annual Budget Total
Legal Status / Required / Legal Status
Source of Funds
Date of Last Interim Modification/Partial Update; Contact for Updating Purposes / Required / Resource Info
(See full information for more details on structure on Resource Info)
Exclude From Website
Exclude From Directory
Data Element: Agency – Unique ID Number (Key)
Definition
The record ID number is a unique numerical code that is affixed to every single record within a resource database (whether that is an agency record, a site record or a program record). Although the organization’s name might change, its unique number will remain the same.
AIRS Standards Reference: Unique ID Number (Required Element)
AIRS XML Reference: Agency/Key
Preferred style
For example, between 00001 to 99999
01641
12579
There is no “official” limit to the number of digits that can be used (although five should be more than sufficient).
Additional information