The Open Proficiency Model (OPM) is an open definition for quantifying an individual's familiarity with skills, capabilities, and other abilities.
Definitions to define the knowledge space:
- Topic - a defined unique area of knowledge for gaining experience and becoming proficient.
- Topic List - A list of topics provided by an issuer.
- Issuer - A verified entity that can provide a topic list and/or create transcript entries.
Definitions to define and store proficiency:
- Experience Source - activities a user can complete to increase proficiency in topics. (regular work, projects, tutorials, etc.)
- Topic Score - a label indicating the degree of understanding for a specific topic.
- Transcript Entry - a topic score assigned to a specific user, claimed by an issuer.
- Transcript - a collection of transcript entries for easier portability.
Definitions to interpret proficiency:
- Topic Score Interpretation - a standardized interpretation for a set of topic scores.
- Topic Score Interpretation List - a collection of topic score interpretations. Examples:
- Verified - All proficiency is signed by the issuer.
- Distributed - All transcript records are independent of the issuer and learning source.
- Never Repeat - Knowledge topics and proficiency are transferrable. New courses on the same topics don't invalidate old courses.
The Works With Open Profiency badge helps indicate to users of your platform, that their (new) proficiencies will be easy to manage, distribute, and validate across ecosystems.
If your product or service follows all or most of the expectations in the specifications, then yes.
Tip
A "Works With" program is planned but not in development yet. Self-regulation by the community is the preferred method for now.
flowchart BT
subgraph knowledge-domain["Knowledge Domain"]
%% Components
topic[/topic\]
pretopic[/pretopic*\]
subtopic[/subtopic*\]
topic-list@{ shape: docs, label: "topic-list" }
dependency-list@{ shape: docs, label: "topic-list<br/>dependency" }
%% Mapping
topic --"N Topics"--> topic-list
subtopic --> topic
pretopic -.-x topic
dependency-list -.-x topic-list
end
subgraph tracking-and-verification["Tracking and Verification"]
%% Components
topic-score[/"topic-score"\]
transcript-entry@{ shape: subproc, label: "transcript-entry" }
transcript@{ shape: div-rect, label: "transcript" }
issuer@{ shape: flag, label: "issuer" }
%% Mapping
issuer --"adds signature"--> transcript-entry
topic-score ---> transcript-entry
transcript-entry --"N entries"--> transcript
%% Mapping - External
topic-list --"1 topic"--> topic-score
end
subgraph official-interpretation["Official Interpretation"]
direction BT
%% Components
score-requirement[/score-requirement\]
score-interpretation{{"score-interpretation<br/>"}}
score-interpretation-list@{ shape: docs, label: "score-interpretation-list" }
%% Mapping
score-requirement --"N requirements"--> score-interpretation
score-interpretation --"N interpretations"--> score-interpretation-list
%% Mapping - External
topic-list --"1 topic<br/>1 score"--> score-requirement
issuer --"adds signature"--> score-interpretation-list
end
%% ----- YOUR RESOURCES ----- %%
subgraph experience-sources["Experience Source"]
%% Components
tutorial
product-usage
test
etc.
end
%% Mapping
topic-list -."N Topics from N Lists".-x experience-sources
experience-sources --"1 score<br/>1 user"--> topic-score
subgraph your-application["Your Services"]
%% Components
web-app@{ shape: stadium, label: "Web App" }
mobile-app@{ shape: stadium, label: "Mobile App" }
desktop-app@{ shape: stadium, label: "Desktop App" }
database@{ shape: lin-cyl, label: "Database" }
end
%% Mapping
score-interpretation-list --> your-application
transcript --> your-application
* The pre- and sub- prefixes only indicate relationships between topics. They are not a different component.
