BOA-0000U
December 20, 2006
Grants are the lifeblood of most nonprofit organizations. Without these funds, the vast majority of these groups would have no way of achieving their social missions. Not surprisingly, the grant application and grant-making process are both difficult and time-consuming affairs. Organizations applying for grants first need to identify the philanthropic foundations that align with their values and goals, which in and of itself is tremendously challenging. Foundations disbursing funds need to carefully evaluate hundreds, sometimes thousands of grant applications every year. This holds true even for foundations that do not accept unsolicited applications. (5RD)
These challenges would be greatly alleviated if there were a comprehensive, up-to-date online database of grants made by philanthropic foundations. Such a database would enable grant-seekers to identify potential sources of funding more easily and quickly. It would help eliminate redundancy by surfacing potential for collaboration among projects with similar goals. More informed seekers would also result in better and fewer grant applications for foundations. Furthermore, such a database would be a valuable source of data for studying important trends in philanthropy. (5RE)
Some online databases of grants information do already exist, but they all rely heavily on manual collection, aggregation, and categorization. As a result, these databases tend not to be current or comprehensive. Ideally, grant-makers would publish their own information on their web sites, which could then be automatically aggregated. (5RF)
Because some foundations are already publishing grants information on their web sites, a microformat for grants information (hGrant) would enable the automatic aggregation of this data in a useful manner, while requiring minimal additional labor on the part of foundations. (5RG)
There is no industry standard schema for grants information. The Foundation Center and other organizations that currently aggregate grants information all have schemas for their databases. Some grants-management software export to these schemas. (5RI)
In November 2006, representatives from the Community Technology Foundation of California, Mott Foundation, the Hewlett Foundation, Solpath (an open source grants management solution), and Blue Oxen Associates (research and consultancy in collaboration) met to start formulating a data model for hGrant, which resulted in the first version of this proposed specification. We plan on continuing to engage both foundations and grants management vendors to make sure that the specification is broadly useful. At the same time, we want to continue to engage with the microformats community to make sure that the proposed specification conforms to the underlying philosophy of this technology. (5RJ)
Foundations that publish grants information: (5RK)
hgrant
title
URL
description
amount (currency)
period
dtstart (datetime)
dtend (datetime)
grantee
contact info (hCard)
grantor
contact info (hCard)
rel-tag (5RQ)
Except for URL (which should use the <a> element), publishers have flexibility as to which XHTML elements to use for each field. (5RR)
Ruby parsing code for this proposal is available. (5RS)
Foundations will generally not want to list the grantor (themselves) next to each grant. We expect these groups to use the include-pattern for grantor. (5RU)
The URL field should be used for a permalink. (5RV)
There is currently a standard for categorizing grants ([ NTEE]), but many organizations are using their own taxonomies. rel-tag and namespacing will allow these grants to accomodate multiple taxonomies and folksonomies. (5RW)
We would like to include EIN information for both grantees and grantors. It would allow aggregators to identify organizations more accurately, and it would also enable mashups with other databases (such as GuideStar). However, this information is rarely included on existing pages today, and invisible metadata is frowned upon by the microformats community. It should probably be an optional field, and we should outline the best practices associated with it. (5RX)
It would be very useful to geotag grants information. This is potentially different from both the grantee and the grantor's contact information. At minimum, we should allow support for identifying the applicable countries using ISO country codes. However, for this to be useful, we definitely want finer-grained location. What's the right granularity? State/province? County name? Zip code? City name? (5RY)
Contributors to this proposal include: (5S3)