Draft API Catalog metadata schema

Draft version of the potential metadata schema that describes APIs

Digital Strategy Requirements

The only requirement per the Strategy is tagging of existing APIs. See action item 2.2. The idea being that if both Commerce and DOI both tag their fisheries API "salmon", to use a popular example, a developer building an API can find salmon-related data across agency lines allowing the government to absorb the complexity.

While it would be a fool's errand to try to predict in advance every such tag, a folksonomy would allow agencies to describe their APIs as they see fit, and disambiguation can occur on the data.gov CMS/catalog level as necessary.

Proposed Fields

• Name (dcterms:title)
• Description (dcterms:description)
• URL to Documentation (dcat:dataDictionary)
• Service Endpoint URL (dcat:WebService)
• Tags (dcat:keyword)
• Agency (datagov:Agency)

Best Practices from ProgrammableWeb

Primary fields (the MVAP -- minimum viable API profile)

• Summary
• Category
• Tags
• Description
• API Home Page
• Logo

Technical fields

• Protocols
• Data Formats
• Service Endpoint
• WSDL (for SOAP APIs)
• Authentication model
• SSL Support

Secondary fields

• Official client libraries
• Community client libraries
• Company Blog URL
• API Blog URL
• Announcement URL
• Company Twitter URL
• API Twitter URL
• Contact Email
• API Gallery URL
• Developer support URL/Email
• Console URL
• Signup requirements
• Developer key required (Y/N)
• Account with service required (Y/N)
• Commercial licensing
• Non-commercial licensing
• Data licensing
• Usage Fees
• Program Fees
• Certification Program
• Usage Limits
• Terms of Service URL