WID API: Design, Specifications, and Use Cases
Delve into the world of the WID API, exploring its design goals, API specifications, primary functions, use cases, and naming conventions. Learn how the WID API can be leveraged for data access, integration, and end-user products, ensuring consistency, clarity, and stability in your API implementations.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
APIs AI LMI and the WID April 2024 Gary Sincick Oregon Employment Department
WID Quick Review Database specification overseen by the ARC Individual WID databases are created and populated by the states Includes data, lookup, and crosswalk tables
What is the WID API? API specification based on the WID database structure Provide a standard suite of data access functions Implement in Oregon, provide specification to ARC
What is an API Specification? Blueprint of the API Describes what the API does Shows how to call the API Lists any query parameters available Shows the schema of the JSON that will be returned Swagger / OpenAPI 3.0
What can you do with it? Do design first API development Generate client or server code Generate documentation Communicate your API to others Connect to AI
WID API Use Cases Run web applications against it Integrate LMI into other sites Data transfer End-user product LLM / AI integration
WID API Design Goals Consistency, Clarity, Stability Designing for End Users and Implementers Data-Driven API vs Application-Driven API Leverage Existing Data Models Leverage Existing Standards: OpenAPI JSON:API
API Primary Functions Data access by key fields Lookup table access for data sets Min/max years for time series data Data paging Other possibilities? Sparse fieldsets, filters, search
Naming Conventions Match parameter names and JSON field names Make names intelligible (if possible) Avoid acronyms, abbreviations, truncations Use camel case for concatenated names
API Response Payload { "meta": {}, "data": [], "links": [] }
Data data": [ } ] { type: cesEmployment , id: 41-01-000000-2019-01-00-false , attributes: { stateFips: 41 , areaType: 01 , area: 000000 etc .
Meta Data "meta": { pageSize: 500, hasMore: true, widVersion: 2.8 apiVersoin: 1.0 dataSource: Oregon Employment Dept } totalCount: 6282, pageNumber: 1,
Links links": [ type: GET , } ] { href: http://localhost:8080/widapi/.. , rel: next ,
Whats Been Done Lately? Spec cleaned up naming consistency schema structure synced to implementation Oregon implementation moved to public server
Core Data Tables Available LABFORCE (LAUS labor force and unemployment data) CES (Current Employment Statistics) IOMATRIX (Industry and occupational employment and projections) IOWAGE (Occupational wages) INDUSTRY (QCEW industry employment and payroll) [still need to do licensing .]
Whats Next? Add support for additional WID tables GitHub? WID 3.0 Branch? ARC Involvement? AI integration
AI and LMI Not an obviously great combination Time lag of AI training set Inaccurate, obsolete, or fabricated data Possible fixes: AI web browsing capability Plug-ins Custom GPTs
Custom GPTs GPT-4 dedicated to specific function Allows custom instructions Can use uploaded files/documents Allows API access No coding required!
Example 1: Unemployment by Area Data is current and accurate (!) GPT can figure out which data set it needs GPT can plan a multi-step process GPT can fill in the blanks (sometimes)
Example 2: Occupational Wages Again, data is current and accurate Figures out correct region
Are there problems? A few Inconsistency Context window confusion Laziness ( Here s 10% of what you asked for ) Random stupidity Performance variability LMI data challenges Code hierarchies Seasonal adjustment, etc
Hints and Tips Give it a good API Be forgiving with parameter formatting Provide good default values for parameters Validate parameters and return good error messages Provide lookup values Give it a good API Spec Document operations in the specification List parameter values where possible Provide instructions and rules of thumb Don t make it work harder than it needs to
Whats the Big Picture? What problem are we solving? Overcoming user interface limitations Accessibility Scaling of personalized assistance What other compelling use cases? How good is good enough?
Whats Next? Continued work in Oregon Experiments with other APIs? Career Onestop O*NET Experiments with other LLMs Llama3 Open Source
Questions? Gary Sincick Oregon Employment Dept. Gary.M.Sincick@employ.oregon.gov QualityInfo.org
