Registry Assistant Handbook

Overview

The Credential Engine offers the Registry Assistant API as a way to streamline publishing to the Credential Registry. The Registry Assistant uses a simplified version of the CTDL schema designed to be easy to map your data to. This guide is a step-by-step walkthrough for using the Registry Assistant API.

To use the Registry Assistant API, you will need:

• A Credential Engine Account, including an Organization account that has been approved to publish via the Registry Assistant API
• Your API key (obtainable via your Credential Engine Account)
• A working knowledge of CTDL and related concepts
• Programmatic read/write access to your data to generate and store CTIDs and retrieve the data for publishing
• The ability to update your website or system to publish data to the Registry

Overview Presentation

Working Knowledge

This guide assumes a working knowledge of:

• Computer programming, including the use of APIs
• JSON
• Metadata
• The Mapping, Object Types, and CTID sections of the Registry Guide

Additionally, it is recommended to be familiar with:

• Credential Transparency Description Language (CTDL)
• The Credential Engine Registry
• JSON-LD
• RDF

Getting your API Key

In order to publish/consume data using the Registry Assistant API, you will need an API Key. This key is connected to your organization in the Credential Engine Accounts site. If you do not already have an account and/or an approved organization:

1. Navigate to the Credential Engine Accounts site.
2. Create an account. After registering, you will receive an email to confirm your account.
3. After confirming your account, you can add your organization.
4. Complete the required information for the organization, along with publishing roles and methods, and submit the organization for approval.

A member of the CE team will review the organization request. Upon approval, an API key will be generated for your organization's account. This API key will be used for publishing and consuming (Note: You will not need the API key for requests to the Format endpoint).

Your organization's CTID and API key will be available on the organization dashboard on the accounts site, as shown below:

Managing your CTIDs

The CTID serves as the primary, unique identifier for all major objects in the Credential Registry. As such, it is critical that your system is able to associate each credential with its CTID, as this is the only way to update or delete the credential's data once it is published to the Registry.

CTIDs can be easily generated by concatenating ce- and a UUID or GUID. For example:

Most programming languages have methods to create a GUID.

• Microsoft C#
  var myCTID = "ce-" + Guid.NewGuid().ToString().ToLower();
• Java
  import java.util.UUID; var myCTID = "ce-" + UUID.randomUUID().ToString().ToLower();
• SQL Server
  declare @CTID varchar(50) set @CTID = 'ce-' + Lower(convert(varchar(50),newID()))

API and Registry Features

This section describes features of the API and the environments to which you can publish.

Publishing Environments

The Credential Engine maintains two environments for publishing:

• The sandbox environment, for testing your system and your data
• The production environment, for real data

Sandbox

The Credential Engine offers a sandbox environment for both initial testing of publishing an organization's data and to allow feedback from CE on the range and type of data published. The sandbox should be used for all initial testing. An API key is normally not required for publishing to the sandbox. A partner who anticipates acting as a third party publisher may wish to use the sandbox environment to better understand the workflow. In this case, the CE team will work with the partner to simulate an environment in the sandbox similar to the anticipated workflow in production, including the use of API keys and identifying the CTIDs for 'client' organizations. The pattern for the sandbox URLs are as follows:

Format Data (no publishing)

Publish Data (automatically formats first)

Delete Data

The majority of the code samples in this section will use the sandbox URLs.

Production

The production environment, naturally, is used to publish data to the production registry. Typically an organization will be required to use the sandbox environment first to validate how their data is retrieved, and formatted for publishing. The pattern for the sandbox URLs are as follows:

Format Data (no publishing)

Publish Data (automatically formats first)

Delete Data

Services

The Registry Assistant API provides three main services related to the credential registry:

• Formatting your data in CTDL JSON-LD
• Publishing your data in the Credential Registry
• Deleting your data from the Credential Registry

Request/Response

Request

The Publish and Format endpoints use an HTTP POST request. Each endpoint type will have a custom input class. The input object will be provided in the body of the Post request.

Response

Response class returned from publish endpoints.

NOTE: If the document being published has the same contents as the currently published one, the envelope last updated_at date on the envelope will NOT be updated. As well a warning message will be returned.

Response class returned from format endpoints.

Response class returned from delete endpoints.

Format Endpoints

The primary purpose of the formatting endpoints are to be able to 'test' making publishing calls. These endpoints are called with the same data that would be provided when publishing. The format endpoints do the same data validation as happens when calling the publish endpoints, and then formats the data as JSON-LD - as would be found in the registry. However, instead of publishing the data, it is returned to the caller.

Note that the Publish endpoint will format the data first, so you do not need to call both.

You can access these services by making HTTP POST requests to:

Format Data (only)

Example: Format Credential

Publish Endpoints

The publishing endpoints are used when you are ready to actually publish data to the registry.

You can access these services by making HTTP POST requests to:

Publish Data (automatically formats first)

Example: Publish Organization

Delete Endpoints

The delete endpoints are used when you want to remove a document from the registry.

NOTE: Generally data in the registry is meant to be permanent. For example if a credential is no longer offered it should not be deleted. Rather it should be republished with a status of Deprecated. If bad data like duplicates has been published, then these should be deleted.

You can access these services by making HTTP DELETE requests to:

Delete a Document

Example: Delete Credential

The requirements for a delete request are as follows. Note: The API key is passed in the header of the request (see the Getting Your API Key section for details)

• Your API Key
• The CTID of the document to be deleted
• The CTID of the organization making the request

Below is some example code to delete a credential, see github for the complete example.

Sample credential delete code (C#)

Publishing Process

This section describes the process for publishing to the Registry via the Registry Assistant API.

Quick Start

The remainder of this document provides the details for publishing data to the registry. This section provides a quick start of the steps.

All publishing starts with the organization. An organization must always be published first before any credentials, etc. that it may own are published.

• First register your organization in the Credential Engine Accounts site.
• If your organization is planning on publishing as a third party on behalf of other organizations, a permissions relationship must be set up and approved with thoses organizations before able to publish (see the following section on workflows).
  • The Accounts API can be used to register an organization and set up the publishing relationship.
    • If your organization has been approved as trusted third party publisher, the relationship is immediately approved
    • Otherwise the target organization and Credential Engine must approve the relationship.
  • Otherwise an organization can manually set up/request publishing permissions in the accounts site.
  • While an API key is created for every organization registered in the account system, a third party publisher will ALWAYS use their own API key even when publishing data on behalf of other organizations.
• Once registered in the accounts site and approved, then the organization can be published.
• Each section on publishing will start with a list of references including the class definition on https://credreg.net, the latest version of the request class on Github, and sample publishing code on Github. For example, the Organization section has the following:
  • • Organization class on credreg.net
    • See github for the Organization Request class used by the Assistant API.
    • See more detailed ready to run examples in github.
• After successfully publishing the organization, then credentials, learning opportunities, etc. can be published.

Workflows

There are different types of workflows related to publishing:

• First Party
• Third Party
• Trusted Third Party with Authority

First Party Workflow

First Party workflow is defined as: The owner of the data to be published also performs the publishing.

1. The organization registers with the CE accounts site.
2. A CTID is created for the organization. This CTID will used when publishing the organization, the PublishForOrganizationIdentifier property for all publishing requests, and the OwnedBy property when publishing credentials, etc.
3. Upon approval, the organization will be given access to an API key (see Getting your API Key), that is used along with the CTID for their organization when calling the API to publish their data.
4. The API process will validate whether a particular API key can be used to publish data for a particular organization CTID.

Third Party Workflow

Third Party workflow is defined as: The data organization has decided to have a third party publish data on their behalf.

1. The organization, such as a state body, registers with the CE accounts site. Under their organization information, they would indicate that they plan to act as a third party publisher.
2. The latter organization identifies 'client' organizations, and these bodies also register on the CE accounts site.
3. As above, a CTID is created for the organization. This CTID will used when the third party publishes data for the organization
4. After approval, a 'client' organization can submit a request to designate the third party organization to publish on their behalf.
5. The third party organization must approve the request. Then CE staff will approve the completion of a third party publishing permission.
6. Upon approval, the third party organization will be given access to an API key (see Getting your API Key).
7. When publishing the third party organization would use their API key and the CTID for one of the client organizations.
8. The Assistant API process will validate whether a particular API key can be used to publish data for a particular organization CTID.
9. NEW - batch registration
   • A third party organizaion can register multiple organizations at one time, using either a bulk upload from the accounts site, or using an Accounts API (separate from the Assistant API).
     • Bulk Upload: A third party or trusted partner will see a Third Party Publishing tab on their account dashboard. Click the Upload/Register Organization link for Bulk Upload instructions (see image below).
     • Alternately, a Web API can be used to register organizations. See the Trusted Partner Publishing page for details.

Trusted Third Party with Authority Workflow

Trusted Third Party with Authority workflow is defined as: The trusted third party has authorization to publish for the data organization, without the data organizations having to first create an account and give explicit authorization to the third party.

1. The trusted organization, such as a state body, registers with the CE accounts site. Under their organization information, they would indicate that they plan to act as a third party publisher.
2. This organization will likely have already had meetings with the CE team to discuss their plans. A CE team member has to designate an organization as a trusted partner.
3. The trusted partner is responsible for validation of the organizations for whom they will be publishing.
4. Typically the trusted partner will use either the accounts API endpoint or a bulk upload in the accounts site to register the organizations for whom they will be publishing.
5. Both the API endpoint or bulk upload process will:
   • Validate the data
   • At least one contact is required. This person will be added as an administrator for the new organization.
   • The administrator will receive an email requesting confirmation of their account. This administrator can add additional contacts as needed.
   • The organization will be created, approved, and assigned an API key for publishing.
   • A third party relationship will be created and approved for publishing.
   • The provided contact will receive an email as notification that their organization has been added by the trusted partner.
6. When publishing the third party organization would use their API key and the CTID for one of the client organizations as the PublishForOrganizationIdentifier parameter when publishing to the registry.
7. The Assistant API process will validate whether a particular API key can be used to publish data for a particular organization CTID.

Sequence of Publishing

The Organization is always the first class to be published. It must exist in the registry before any credential, or learning opportunity, etc. can be published. The API has validation checks:

• Checks if the organization has been registered and approved in the CE accounts site. If not the request will be rejected.
• If a CTID is provided for the properties like owned by, offered by, accredited by, etc. the Assistant API will check if the record exists in the credential registry
• If not found, an error will be returned

The Credential is typically the next document to publish. A credential can refer to a required learning opportunity or assessment using a condition profile. Example of a credential that references a required learning opportunity using a 'requires' condition profile:

The API will check if the learning opportunity for the provided CTID (ctidForLearningOpportunity in the example above) is in the registry. If not, the publish request will still continue and a Warning will be returned as a reminder that the related learning opportunity should be published.

Required and Recommended Properties

Credential Engine has a minimum data policy for data being published to the credential registry.

This Credential Minimum Data Policy defines the requirements for publishing to the Credential Registry. Use the Benchmark Models to improve transparency of information beyond this policy. The Credential Transparency Description Language (CTDL) is the common language by which credentials and credentialing organizations are described. We don’t expect organizations to include information about each term in the language; however, some terms will be required, while others are recommended.

Each publishing section in this handbook will include a link to the related section for the minimum data for that class. The minimum data policy also includes sections on Recommended Benchmarks:

These terms are not required, but is a best practice to include them in order to improve transparency and connections.

Data Requirements

There are very few data restrictions.

• URLs, such as for a subject webpage must be publically available and resolvable
• URIs (CTIDs) for registry related resources USUALLY must aleady exist and be resolvable. There are exceptions such as where an organization owns or offers credentials. The organization must be published before the credential, so references to owns a credential, etc. are not expected to exist in the registry yet.
• Descriptions, where required, have a minimum length of 15 characters. This restriction means values like N/A or Not Applicable are not valid.

Registry Resources Life Cycle

Data in the registry is meant to be permanent. For example, even though a credential is no longer offered, a holder of that credential should be able reference the credential information, like competencies.

Rather than deleting a resource, it should be published with an update to its related status:

• For Credentials no longer offered use: CredentialStatusType: Deprecated
• For Competency Frameworks no longer offered use: PublicationStatusType: Deprecated
• For Organizations, Learning Opportunities, Assessments, Transfer Value Profiles, and Collections use LifeCycleStatusType: Ceased

Pattern for Calling the Publishing API

All publish requests follow the same pattern. A publish request consists of three main parts:

• The API key for your organization, passed in the header (see below)
• The CTID of the organization that owns the data (If you are publishing on behalf of another organization, use that organization's CTID. Otherwise, use your organization's CTID)
• The data itself

Passing Your API Key

The API key will be provided in the header of the request using the Authorization header and a label of ApiToken.

Adding an API key to an HTTP Request using HttpClient (C#)

The CTID for the data owner is provided in the body of the request along with the main data class.

Creating a request body for an organization (C#)

Serializing to JSON

While creating a JSON document is fairly straightforward, there should not be a need to manually code the JSON format. Libraries are available in most high level languages to serialize a class into JSON. For example The Newtonsoft library can be added to a C# project, and with one line a C# class can be serialized to JSON:

Sample showing one-line serialization of a C# class to JSON using the Newtonsoft library

Assistant Key Input Classes

API Input Classes

When calling endpoints in the API, you only have to include the properties that are needed, or that you have available. Some of the samples in this section may reference related profiles such as condition profiles. If your process will not provide condition profiles, you don't need to include these properties in the classes that you use to fill out data to send to the API. Following are references where you may view or download sample input classes (in C# at this time).

• C# API Input Classes from Github

The API input classes clarify the multiplicity of the input properties, which is not immediately clear by just reviewing the CTDL terms. As well special classes are used to organize some of the CTDL properties. For example:

• Use of single multiplicity for Jurisdiction.MainJurisdiction
• FrameworkItem for known Occupations, Industries, and Instructional Programs frameworks

Language Maps

October 31, 2018. Several major updates were made to how data is stored in the registry. These changes, for the most part, were transparent to API users. One of the additions was to store simple strings as language maps. For example, previously the ceterms:name property was formated as:

Previous name format

Language Strings

Properties defined as a language map (rdf:langString) are now an object with a value for each language provided. The property name is the BCP 47 language code (optionally can include the region, e.g. "en" versus "en-US"). This allows describing data for the same property in multiple languages, which in turn allows a system consuming the data to select the language(s) it wants to display.

Sample language map with one language

Sample language map with multiple languages

Array Language Strings

A list of values can also be provided in multiple languages.

Sample keyword language map list with multiple languages

Language Usage Options

As noted, one of the main tenets of the API is to simplify publishing to the Credential Registry. To this end, users of the API can choose to provide data as a simple string or as a language map. Each applicable property will include two options: the actual CTDL name and the latter with a suffix of map. Example Name and Name_map:

If all of your data is in one language, the language provided in the request DefaultLanguage property will be used when formatting a language map for publishing to the registry.
If DefaultLanguage is not provided, en-US (United States english) will be used.

In the API input classes, the language Map is defined as Dictionary with string keys and values (expressed in C# as Dictionary<string, string>).

See github for full LanguageMap class

Sample language map usage (C#)

Organization and Entity References

The Reference classes, EntityReference and OrganizationReference, were created to enable three scenarios:

• Just the CTID of the resource in the registry. (RECOMMENDED)
  The API will insert the correct domain name and path, based on the target server, to enable independence from the publishing environment.
• The URI to an Organization (or credential, etc.) in the registry (rarely necessary/used)
• A reference to an organization that has not been published to the registry

Entity Reference

When referencing a property that refers to a credential, assessment or learning opportunity, the assistant API uses an EntityReference. See the Entity Reference class in Github for all available properties.

This class, and the organization reference class enable a flexible approach to providing references to other entities, depending on what is available in the publishing system. There are three approaches:

1. Provide just CTID (recommended):
   • If the related entity is in the registry, or soon will be, then just the CTID can be provided.
   • The preference between providing a CTID or Id would be the CTID. Then the API can format the URL correctly based on the target credential registry and community/private registry where applicable.
   • There may be a case where a reference is needed for an entity that is in a different community/private registry than the current target (rare, and not yet completely handled). In this case, then the full URL should be provided in the Id property.
   • Example myData.AccreditedBy.Add( new OrganizationReference() { CTID = "ce-541da30c-15dd-4ead-881b-729796024b8f" } );
2. Provide just Id:
   • If the entity being referenced is already published in the registry, the full URI can be provided, like: https://sandbox.credentialengineregistry.org/resources/ce-a4041983-b1ae-4ad4-a43d-284a5b4b2d73.
   • Note: The convention is to provide the /resources URI, not the /graph URI.
3. Provide Reference Properties:
   • A reference can be made to an entity that doesn’t exist in the registry but does have a URL. In this case, the following can be provided:
     • Type (required). This would be one of ceterms:AssessmentProfile, ceterms:LearningOpportunityProfile, or one of the Credential subclasses such as ceterms:Badge, ceterms:Certification, etc.
     • Name (required)
     • SubjectWebpage (required)
     • Description (optional)
     • May 18, 2020. Several additional properties were added to the Entity Reference class
     • See the Entity Reference class in Github for all available properties.

Note: only one of the three options should be provided. Just the CTID (checked first), or just the Id (checked second), or the external reference.

Sample usage (C#). See the Entity Reference class in Github for all available properties.

Partial EntityReference class. See the Entity Reference class in Github for all available properties.

Organization Reference

An OrganizationReference has a small number of required properties, plus the additional optional property of SocialMedia. The Organization reference is used in properties like ownedBy, offeredBy, accreditedBy, etc.

Like the EntityReference class, and the organization reference class enable a flexible approach to providing references to other entities, depending on what is available in the publishing system. This class will be commonly used for referencing QA organizations where the partner may not (and should not) know if the organization exists in the registry.
There are three approaches:

1. Id:
   • If the entity being referenced is already published in the registry, the full URI can be provided, like: https://sandbox.credentialengineregistry.org/resources/ce-a4041983-b1ae-4ad4-a43d-284a5b4b2d73.
   • Note: The convention is to provide the /resources URI, not the /graph URI.
2. CTID:
   • Again, if the related entity is in the registry, or soon will be, then just the CTID can be provided.
   • The preference between providing a CTID or Id would be the CTID. Then the API can format the URL correctly based on the target credential registry and community/private registry where applicable.
   • There may be a case where a reference is needed for an entity that is in a different community/private registry that the current target (rare, and not yet completely handled). In this case, then the full URL should be provided in the Id property.
3. External Reference:
   • A reference can be made to an entity that doesn’t exist in the registry but does have a URL.
   • This class inherits from the EntityReference and adds one property: SocialMedia (a list of URLs to sites like LinkedId, Facebook, Twitter, etc.).
   • In this case, the following can be provided:
     • Name (required)
     • Organization type (class): (required): CredentialOrganization or QACredentialOrganization
     • SubjectWebpage (required)
     • Description (optional)
     • SocialMedia (optional)

Note: only one of the three options should be provided. The CTID is checked first, then the Id, then the external reference.

Sample Properties (C#). See full class in github.

Sample Usage (C#)

Occupations, Industries and Instructional Programs

Occupations, Industries and Instructional Programs that are related to credentials, learning opportunities, and others may be published to the credential registry. There are three ways to provide the latter data to the API, as shown below.

• Using a structured class
• Using a list of codes from a known framework
• Using a list of text where the topic is not part of a framework

Items From a Formal Framework

The full details of a framework item can be published as credential alignment objects (see: CredentialAlignmentObject). The commonly used properties are:

• framework - URL for the framework
• frameworkName - the name of the framework
• codedNotation - for example a SOC code of 49-9081.00 (Wind Turbine Service Technicians)
• targetNode - public URL to this code
• targetNodeName - name of this code
• targetNodeDescription - a description of this code

The equivalent class in the API is FrameworkItem:

Helper for O*Net/NAICS and CIP Codes

The API has short cut properties for handling occupations from the O*Net framework, industries from NAICS, and instructional programs from Classification of Instructional Programs (CIP). These properties only require the entry of a list of items using the coded notation only. The API will validate the codes, format the framework and target node data, and publish the data as a CredentialAlignmentObject. The helper properites are:

• ONET_Codes
• Naics
• CIP_Codes

Alternative Framework Items

Feb. 22, 2019.

The API has helper properties for handling occupations, industries and instructional programs that are not part of a formal framework. The new properites are:

• AlternativeIndustryType
• AlternativeOccupationType
• AlternativeInstructionalProgramType

Framework Examples

Following are examples of the different properties that can be used to publish framework data.

Example for adding Occupations using a FrameworkItem, a SOC list or alternate occupations to a credential request

Example for adding Industries using a FrameworkItem, NAICS list or alternate industries to a credential request

Example for adding Instructional Programs using a FrameworkItem, a SOC list or alternate instructional programs to a credential request

Duration Items

DurationItem - used with DurationProfile class for the property EstimatedDuration. Rather than providing data in the ISO 8601 duration format (ex. for 10 hours, the format would be PT10H

The DurationItem has properties for Years, Months, Weeks, Days, Hours, and Minutes.

Duration Profile:

Duration Item:

Sample Usage:

Getting Started

To call the publish API, you will need to make an HTTP POST request to the API endpoint specific to the data type being published. For example, to publish a credential you would use:

NOTE: The remaining examples on this page will use URLs for the sandbox version of the credential registry.

With your request, include two things: First, you will need to pass your organization's API key (see Getting your API Key) as a request header using the format:

Sample:

Second, a JSON object with properties to publish. The provided JSON object will be specific to the type of data being published. The following sections will have examples of the properties for each data that may be published.

Top level classes in the Registry often need to reference one another. For example, a Credential might need to reference both the Organization that owns it, and an Assessment that it requires. The easiest way to provide valid references to these things is to ensure that things which need to be referenced are published before things that are doing the referencing. Usually this means that you should publish the Organization first, any required entities like assessments or learning opportunities second, and the credential(s) that reference these entities last. These references are all handled via the URIs explained in the CTID section of the Registry guide page.

The Registry Assistant API uses simiplified and flexible input classes. While all properties of CTDL are available, the input properties represent a Registry specific profile.

Examples of special or simplified classes and properities, follow below.

The Registry Assistant accepts data formatted using ordinary JSON. A special variant of JSON, JSON-LD, is used within the Registry. One of the features of the Registry Assistant API is that it handles conversion of ordinary JSON to JSON-LD for you. Explanations of JSON and JSON-LD are beyond the scope of this guide, but the remainder of this guide assumes at least a basic working knowledge of standard JSON. Note that the API does not care about the presence or lack of additional whitespace (sometimes known as "pretty printing") within your JSON, but for the purposes of readability, this guide will include it.

In some cases, a property can have multiple values. In these cases, you must always use an array if any values are present, even if there is only one value.

Upon successfully publishing data to the Registry, you will receive the resultant CER Envelope. The CER Envelope contains the entity that was published (the "payload") along with various other data about the publish event, such as the date and time the publish happened, the account responsible for it, cryptographic signature data to enable validation of the payload against tampering, and the identifier for the envelope itself (this is not the same as the CTID). While it is not necessary to reference a particular envelope in order to use the Registry, it may be useful to maintain a record of the envelope's ID within your system should you need to access a specific envelope in the future.

The general approach for each of the top level classes in the sections below works like this:

1. Introduction to a top level class in CTDL and its Registry Assistant equivalent
2. Required properties for that class
3. Publishing a basic record using just the required properties and conversion of raw data to Registry Assistant API class to actual CTDL
4. Recommended and optional properties for that class
5. Summary

The high level steps for using the API include:

• Determine the source of the target data from your environment
• Develop process to retrieve the data
• Get/View the latest input classes from Github: View/Download the C# API Input Classes here
• These reference classes are in a C# syntax but can be easily adapted for alternate evironments
• Map your to the latter input classes
• Call the API

Sample Publishing of an Organization

To publish an organization, your system will need to:

• Create an Organization object used for the publishing request
• Populate the object with data from your system
• Create the API request object including the organization object and minimally the CTID of the organization that owns the resource being published
• Serialize the request object
• Call the appropriate API publish (POST) endpoint

Sample organization publishing code (C#)

Prototyping With Postman

Postman is a popular tool for building and testing APIs. It can be used to prototype the publishing of resources before implementing programming based publishing. Postman is a powerful tool for testing. Variables can be set by environment (sandbox, production, etc.) for many scenarios including:

• For the API URLs - {{base_AssistantUrl}}organization/format
• An organization's API key ApiToken {{myOrgApiKey}}
• An organization's CTID "PublishForOrganizationIdentifier": "{{myOrgCTID}}",

Sample Postman Header

The API request class includes the required parameter: PublishForOrganizationIdentifier, and the JSON for the resource to be published.

Sample organization wrapper:

Sample credential wrapper:

Sample Postman Publish

Publishing Your Organization

Introduction

Usually, the first class you will want to publish is the Organization class. This is the class that represents your organization, and you will use its CTID to reference the data within it. There are two types of organization classes, the most common is the CredentialOrganization class. If your organization focuses on providing quality assurance, you will want to publish the ceterms:QACredentialOrganization class instead.

NOTE: The Assistant API uses a simplied approach for publishing organizations. There is a single organization endpoint with a single Organization class. A Type property (like you will see used with Credentials) is used to designate the type of organization to publish. The type of organization is one of:

• CredentialOrganization
• QACredentialOrganization
• Organization

References

• Organization class on credreg.net
• See github for the Organization Request class used by the Assistant API.
• See more detailed ready to run examples in github.

To format or publish an Organization, use the following endpoints:

Format Data (only)

Publish Data (automatically formats first)

Required Properties

The Registry Assistant API uses a simplified version of the equivalent CTDL class to convey the data for an organization. This class is the same regardless of whether the resulting CTDL class is a QA Organization or not. Refer to the Minimum Data Policy for the required properties for the Credential Organization and QA Credential Organization classes.

Publishing a Basic Record

Your system will need to output the data in JSON format:

• Create an Organization object used for the publishing request
• Populate the object with data from your system
• Create the API request object including the organization object and minimally the CTID of the organization that owns the resource being publishe
• Serialize the request object
• Call the appropriate API POST endpoint

Serialized request

Recommended Properties

In order to maximize the utility of the Organization data in the Registry, we recommend you also include data for the recommended properties for the organization classes. See the recommended properties for the Credential Organization and QA Credential Organization classes. For example:

Multiple Locations

As a general rule organizations are published to the registry once and if the organization has multiple locations include each location's name and complete address with the organization.

An organization object with multiple locations (C#)

Sample

To publish the data, you will need to wrap it in an object that also contains a PublishForOrganizationIdentifier property. Naturally, this is where you specify the CTID of the owning organization (from the accounts site). The organization data itself will go in an Organization property:

Sample organization wrapper:

Below is some example code to publish a simple organization object, see github for the complete Organization Request class.

Sample organization publishing code (C#)

Summary

As you can see, once you get past the most basic properties, the Registry Assistant API alleviates a great deal of the complexity of the CTDL structure. This reduces the likelyhood of errors and ensures your data will be compatible with systems that consume data from the Registry.

Publishing Your Credential

Introduction

Once your organization has been published, you will often want to publish your first credential. For each credential you want to publish, you must first consider which type of credential it is. These types are defined by the subclasses of "Credential" in CTDL. Select the type that is most appropriate for your credential - note that you must pick exactly one type.

Note that some credentials may be one type and also include a badge to represent them. In these cases, the badge is considered a type of verification, and is handled elsewhere in CTDL. The badge credential types (ceterms:Badge, ceterms:OpenBadge, and ceterms:DigitalBadge) are reserved for credentials that are exclusively defined as badges.

NOTE: The Assistant API, like for organization, uses a simplied approach for publishing credentials. There is a single credential endpoint with a single Credential class. A Type property is used to designate the type of credential to publish. Again refer to the credential type definitions to ensure that you’ve selected the most appropriate credential type.

References

• Credential class on credreg.net
• See github for the Credential Request class used by the Assistant API.
• See more detailed ready to run examples in github.

To format or publish a Credential, use the following endpoints:

Format Data (only)

Publish Data (automatically formats first)

Required Properties

Once you have selected a type for your credential, your system will need to output at least the required properties. Refer to the Minimum Data Policy for the required properties for the Credential classes.

Publishing a Basic Record

Your system will need to output the data in JSON format.

Recommended Properties

In order to maximize the utility of the Credential data in the Registry, we recommend you also include data for the following properties. See the recommended properties for the Credential.

Sample

To publish the data, you will need to wrap it in an object that also contains a PublishForOrganizationIdentifier property. Naturally, this is where you specify the CTID of the owning organization (from the accounts site). The credential data itself will go in an Credential property:

Sample credential wrapper:

Below is some example code to publish a simple credential object, see github for the complete Credential Request class.

Sample credential publishing code (C#)

Below is an example for a more detailed credential. (C#)

Credential Connections

Connections between credentials can be published using properties such as:

• isPreparationFor
• preparationFrom
• isAdvancedStandingFor
• advancedStandingFrom
• isRequiredFor
• isRecommendedFor

Below is an example of a connection to a credential for which the current credential will prepare a student:

Summary

As you can see, the Registry Assistant API greatly reduces the amount of data your system needs to carefully construct by abstracting away many of the intricacies of JSON-LD. However, it is very useful to learn about and understand JSON-LD for the benefit of your own system and to aid in any further development or debugging or usage of the data you get back from the Registry Assistant API.

This section has introduced publishing credentials with the more common properties. There are a lot of other properties that may be published for a credential, including:

• Provide details such as required or recommended criteria using Condition Profiles
• Provide information on estimated costs with Cost Profiles
• Provide information on available financial assistance using Financial Assistance Profiles
• Provide estimated duration to achieve a credential using Duration Profiles
• Coming soon, information on publishing outcome data, using AggregateDataProfile. See sample code for publishing a credential with outcome data.

Publishing Your Assessment

Introduction

The Assessment Profile class represents a description of a specific assessment related in some way to a credential. An assessment can be written, performance, and/or artifact-based. Generally, you only need to describe assessments that are significant and/or standalone (assessments such as exams, tests, and quizzes included in a learning opportunity do not need to be described unless there is a good reason to do so). For more information, review the CTDL Guide.

References

• Assessment class on credreg.net
• See github for the Assessment Request class used by the Assistant API.
• See more detailed ready to run examples in github.

To format or publish an Assessment, use the following endpoints:

Format Data (only)

Publish Data (automatically formats first)

Required Properties

The Registry Assistant API uses a simplified version of the Assessment Profile class to convey the data for an assessment. Refer to the Minimum Data Policy for the required properties for the Assessment class.

Publishing a Basic Record

Your system will need to output the data above in JSON format. For example:

Recommended Properties

In order to maximize the utility of the Assessment Profile data in the Registry, we recommend you also include data for the following properties. See the recommended properties for the Assessment Profile

Sample

To publish the data, you will need to wrap it in an object that also contains a PublishForOrganizationIdentifier property. Naturally, this is where you specify the CTID of the owning organization (from the accounts site). The assessment data itself will go in an Assessment property:

Sample assessment wrapper:

Below is some example code to publish a simple assessment object, see github for the complete Assessment Request class.

Sample assessment publishing code (C#)

Summary

The Registry Assistant API makes it easier to publish data about assessments.

Publishing Your Learning Opportunity

Introduction

The Learning Opportunity Profile is used to describe learning opportunities. In CTDL, a learning opportunity is a blanket term used to describe any significant educational experience, whether it is a one-day training class, a full degree program, or anything in between. For more information, review the CTDL Guide.

There are two subclasses of Learning Opportunity Profile: .

• Learning Program Set of learning opportunities that leads to an outcome, usually a credential like a degree or certificate.
• Course Single structured sequence of one or more educational activities that aims to develop a prescribed set of competencies of learners.
  Course is distinct from Program, which aggregates several courses.

Currently the properties are identical for the three classes, except the property School Courses for the Exchange of Data code (SCED) which is only valid for Course.

References

• Learning Opportunity class on credreg.net
• Learning Program class on credreg.net
• Course class on credreg.net
• See github for the Learning Opportunity Request class used by the Assistant API. As for the CTDL classes, the Learning opportunity related endpoints all use the same input class.
• See more detailed ready to run examples in github. There is one method for each of publishing a learning opportunity, a learning program and a course.

To format or publish a Learning Opportunity, Learning Program, or Course use one of the following endpoints:

Format Data (only)

Publish Data (automatically formats first)

Required Properties

The Registry Assistant API uses a simplified version of the Learning Opportunity Profile class to convey the data for a learning opportunity. Refer to the Minimum Data Policy for the required properties for the Learning Opportunity class.

Publishing a Basic Record

Your system will need to output the data above in JSON format. For example:

Recommended Properties

In order to maximize the utility of the Learning Opportunity Profile data in the Registry, we recommend you also include data for the following properties. See the recommended properties for the Learning Opportunity Profile.

Sample

To publish the data, you will need to wrap it in an object that also contains a PublishForOrganizationIdentifier property. Naturally, this is where you specify the CTID of the owning organization (from the accounts site). The learning opportunity data itself will go in an LearningOpportunity property:

Sample learning opportunity wrapper:

Below is some example code to publish a simple learning opportunity object, see github for the complete Learning Opportunity Request class.

Sample learning opportunity publishing code (C#)

Summary

The Registry Assistant API makes it easier to publish data about learning opportunities.

Publishing Your CostManifest

Introduction

The Cost Manifest Profile class represents a description of a specific Cost Manifest for an organization. Generally, you only need to describe Cost Manifests that are used for many credentials, assessments or learning opportunities. Use of cost manifests will remove or reduce the reference to costs in many entities. For more information, review the CTDL Guide.

References

• CostManifest class on credreg.net
• See github for the CostManifest Request class used by the Assistant API.
• See more detailed ready to run examples in github.

To format or publish an Cost Manifest, use the following endpoints:

Format Data (only)

Publish Data (automatically formats first)

Required Properties

The Registry Assistant API uses a simplified version of the Cost Manifest Profile class to convey the data for an Cost Manifest. Refer to the Minimum Data Policy for the required properties for this class.

Publishing a Basic Record

Your system will need to output the data above in JSON format. For example:

Recommended Properties

In order to maximize the utility of the Cost Manifest Profile data in the Registry, we recommend you also include data for the following properties:

Sample

To publish the data, you will need to wrap it in an object that also contains a PublishForOrganizationIdentifier property. Naturally, this is where you specify the CTID of the owning organization (from the accounts site). The cost manifest data itself will go in an CostManifest property:

Sample cost manifest wrapper:

Below is some example code to publish a simple cost manifest object:

Sample cost manifest wrapper, see github for the complete Cost Manifest Request class.

Summary

The Registry Assistant API makes it easier to publish data about Cost Manifests.

Publishing Your Condition Manifest

Introduction

The Condition Manifest Profile class represents a description of a specific Condition Manifest for an organization. Generally, you only need to describe Condition Manifests that are used for many credentials, assessments or learning opportunities. Use of condition manifests will remove or reduce the reference to conditions in many entities. For more information, review the CTDL Guide.

References:

• ConditionManifest class on credreg.net
• See github for the ConditionManifest Request class used by the Assistant API.
• See more detailed ready to run examples in github.

To format or publish an Condition Manifest, use the following endpoints:

Format Data (only)

Publish Data (automatically formats first)

Required Properties

The Registry Assistant API uses a simplified version of the Condition Manifest Profile class to convey the data for an Condition Manifest. Refer to the Minimum Data Policy for the required properties for this class.

Publishing a Basic Record

Your system will need to output the data above in JSON format. For example:

Recommended Properties

In order to maximize the utility of the Condition Manifest Profile data in the Registry, we recommend you also include data for the following properties. See the recommended properties for the Condition Manifest Profile.

Sample

To publish the data, you will need to wrap it in an object that also contains a PublishForOrganizationIdentifier property. Naturally, this is where you specify the CTID of the owning organization (from the accounts site). The condition manifest data itself will go in an ConditionManifest property:

Below is some example code to publish a simple condition manifest object, see github for the complete Condition Manifest Request class.

Sample condition manifest publishing code (C#)

Summary

The Registry Assistant API makes it easier to publish data about Condition Manifests.

Publishing Your Competency Frameworks

Introduction

The Competency Framework class represents a description of a specific Competency Framework for an organization. For more information, review the CTDL Guide.

References

• Competency Framework class on credreg.net
• See github for the Competency Framework Request class used by the Assistant API.
• See more detailed ready to run examples in github.

To format or publish an Competency Framework, use the following endpoints:

Format Data (only)

Publish Data (automatically formats first)

Required Properties

The Registry Assistant API uses a simplified version of the Competency Framework class to convey the data for an Competency Framework. Refer to the Minimum Data Policy for the required properties for a competency framework and Minimum Data Policy for a competency.

Publishing a Basic Record

Your system will need to output the data above in JSON format. For example:

Recommended Properties

In order to maximize the utility of the Competency Framework data in the Registry, we recommend you also include data for the following properties. See the recommended properties for the Competency Framework.

Sample

To publish the data, you will need to wrap it in an object that also contains a PublishForOrganizationIdentifier property. Naturally, this is where you specify the CTID of the owning organization (from the accounts site). The competency framework data itself will go in an CompetencyFramework property:

Sample competency framework wrapper:

Below is some example code to publish a simple competency framework object, see github for the complete Competency FrameworkRequest class.

Sample competency framework publishing code (C#)

Summary

The Registry Assistant API makes it easier to publish data about Competency Frameworks.

Publishing Your Collections

Introduction

A Collection is defined as an aggregation of related member resources. As the name of the class indicates, it is a resource that "collects" already existing instances of resource types including Competency, Course, Job, Learning Opportunity Profile, Learning Program, Task and Work Role. These instances may be members of one or more Collections. A Collection may be defined for any useful purpose. For more information, review the CTDL Guide.

There are three main properies that are used to reference the members of a collection:

• Collection.HasMember - a list of CTIDs for resources that already exist in the registry
• Request.CollectionMembers - a list of CollectionMember objects that minimally include ProxyFor containing a CTID for a resource that already exists in the registry and at least one of Start Date or End Date
• Request.Members - list of objects for supported resource types

Generally

References

• Collection class on credreg.net
• See github for the Collection Request class used by the Assistant API.
• See more detailed ready to run examples in github.

To format or publish an Collection, use the following endpoints:

Format Data (only)

Publish Data (automatically formats first)

Required Properties

The Registry Assistant API uses a simplified version of the Collection class to convey the data for an Collection. Refer to the Minimum Data Policy for the required properties for a collection and Minimum Data Policy for a collection member.

Publishing a Basic Record

Your system will need to output the data above in JSON format. For example:

Recommended Properties

In order to maximize the utility of the Collection data in the Registry, we recommend you also include data for the recommended properties. See the recommended properties for the Collection.

Sample

To publish the data, you will need to wrap it in an object that also contains a PublishForOrganizationIdentifier property. Naturally, this is where you specify the CTID of the owning organization (from the accounts site). The collection data itself will go in an Collection property:

Sample collection wrapper:

Below is some example code to publish a simple collection object, see github for the complete CollectionRequest class.

Sample collection publishing code (C#)

Summary

The Registry Assistant API makes it easier to publish data about Collections.

Publishing Your Concept Schemes

Introduction

The Concept Scheme class represents a description of a specific Concept Scheme for an organization. For more information, review the CTDL Guide.

References:

• ConceptScheme class on credreg.net
• See github for the ConceptScheme Request class used by the Assistant API.
• See more detailed ready to run examples in github.

To format or publish an Concept Scheme, use the following endpoints:

Format Data (only)

Publish Data (automatically formats first)

Required Properties

The Registry Assistant API uses a simplified version of the Concept Scheme class to convey the data for an Concept Scheme. Refer to the Minimum Data Policy for the required properties for a Concept Scheme and Minimum Data Policy for concepts.

Publishing a Basic Record

Your system will need to output the data above in JSON format. For example:

Recommended Properties

In order to maximize the utility of the Concept Scheme data in the Registry, we recommend you also include data for the following properties:

Sample

To publish the data, you will need to wrap it in an object that also contains a PublishForOrganizationIdentifier property. Naturally, this is where you specify the CTID of the owning organization (from the accounts site). The concept scheme data itself will go in an ConceptScheme property:

Sample concept scheme wrapper:

Below is some example code to publish a simple concept scheme object:

Sample concept scheme publishing code (C#)

Summary

The Registry Assistant API makes it easier to publish data about Concept Schemes.

Publishing Your Progression Models

Introduction

The Progression Model class represents a model of identifiable points along a developmental progression including increasing levels of competence, achievement or temporal position (e.g., "Second Quarter"). For more information, review the CTDL Guide.

References:

• ProgressionModel class on credreg.net
• See github for the ProgressionModel Request class used by the Assistant API.
• See more detailed ready to run examples in github.

To format or publish an Progression Model, use the following endpoints:

Format Data (only)

Publish Data (automatically formats first)

Required Properties

The Registry Assistant API uses a simplified version of the Progression Model class to convey the data for an Progression Model.

ProgressionModel: Refer to the Minimum Data Policy for the required properties for a Progression Model

• CTID
• Name
• Description
• PublicationStatusType
• Publisher
• HasTopConcept
• InLanguage. Required unless DefaultLanguage is provided
• ProgressionLevels

ProgressionLevel: Refer to the Minimum Data Policy for progression levels.

• CTID
• PrefLabel

Publishing a Basic Record

Your system will need to output the data above in JSON format. For example:

Recommended Properties

In order to maximize the utility of the Progression Model data in the Registry, we recommend you also include data for the following properties:

Sample

To publish the data, you will need to wrap it in an object that also contains a PublishForOrganizationIdentifier property. Naturally, this is where you specify the CTID of the owning organization (from the accounts site). The progression model data itself will go in an ProgressionModel property:

Sample progression model wrapper:

Below is some example code to publish a simple progression model object:

Sample progression model publishing code (C#)

Summary

The Registry Assistant API makes it easier to publish data about Progression Models.

Publishing Your Pathway

Introduction

The Pathway class represents a description of a specific pathway. In the context of Credential Engine, a pathway consists of structured sets of objectives and qualifying conditions defining points (milestones) along a route to fulfillment of a job, occupation or career. Qualifying conditions include homogeneous or heterogeneous sets of prescribed, preferred or recommended evidentiary artifacts such as competencies attained (knowledge, skills, abilities), relevant awards, other forms of recognition such as credentials earned and relevant experience. For more information, review the CTDL Guide.

To format or publish an Pathway, use the following endpoints:

Format Data (only). Recommended to use the format endpoint to validate the data without publishing.

Publish Data (automatically formats first)

Delete Data

References

See:

• Pathway class on credreg.net
• The Pathway Minimum Data Policy for the required properties for the pathway class.
• The Pathway Component Minimum Data Policy for the required properties for the pathway component class.
• The Registry Assistant API Pathway request input class in Github.
• Sample code to publish Pathways in Github.

Required Properties

The Registry Assistant API uses a simplified version of the Pathway class to convey the data for an pathway. Refer to the Minimum Data Policy for the required properties for the Pathway and Pathway Component classes.

Publishing a Basic Record

Your system will need to output the data above in JSON format. For example:

Recommended Properties

In order to maximize the utility of the Pathway data in the Registry, we recommend you also include data for the following properties:

Sample

To publish the data, you will need to wrap it in an object that also contains a PublishForOrganizationIdentifier property. Naturally, this is where you specify the CTID of the owning organization (from the accounts site). The pathway data itself will go in an Pathway property:

Sample pathway wrapper:

Below is some example code to publish a simple pathway object:

Sample pathway publishing code (C#)

Summary

The Registry Assistant API makes it easier to publish data about pathways.

Publishing Your Pathway Set

Introduction

The PathwaySet class represents a description of multiple related pathways. A pathway set must include at least two pathways. A publish request can include the actual pathway data (using the Pathway input class in Github) or a reference to a pathway that has already been published. For more information, review the CTDL Guide.

To format or delete a PathwaySet, use the following endpoints:

Format Data (only). Recommended to use the format endpoint to validate the data without publishing.

Publish Data (automatically formats first)

Delete Data

References

See:

• PathwaySet class on credreg.net
• The Pathway Set Minimum Data Policy for the required properties for the pathway set class.
• The Pathway Minimum Data Policy for the required properties for the pathway class.
• The Pathway Component Minimum Data Policy for the required properties for the pathway component class.
• The Registry Assistant API PathwaySet request input class in Github.
• Sample code to publish Pathway Sets in Github.

References

The Registry Assistant API uses a simplified version of the Pathway Set class to convey the data for a pathway set. Refer to the Minimum Data Policy for the required properties for the PathwaySet.

Sample

To publish the data, you will need to wrap it in an object that also contains a PublishForOrganizationIdentifier property. Naturally, this is where you specify the CTID of the owning organization (from the accounts site). The pathwaySet data itself will go in an PathwaySet property:

Sample PathwaySet wrapper:

References

Below is some example code to publish a simple PathwaySet object:

Sample PathwaySet publishing code (C#)

Summary

The Registry Assistant API makes it easier to publish data about pathway sets.

Publishing Your Transfer Value Profiles

Introduction

The Transfer Value Profile class represents a description of a specific Transfer Value Profile. In the context of Credential Engine, a transfer value is used in education, training and credentialing to determine qualification for advanced standing. CTDL defines advanced standing as, reduces the time or cost required to earn or complete the referenced credential, assessment, or learning opportunity.

Transfer value can be determined based on a number of factors such as: completion of learning opportunities or assessments, work experience (e.g., military), demonstration of knowledge, skills or abilities. For more information, review the CTDL Guide.

References

• TransferValueProfile class on credreg.net
• The Transfer Value Profile Minimum Data Policy for the required properties for the transfer value profile class.
• See github for the TransferValueProfile Request class used by the Assistant API.
• See more detailed ready to run examples in github.

To format or publish a Transfer Value Profile, use the following endpoints:

Format Data (only)

Publish Data (automatically formats first)

Bulk Publish Data (allows publishing multiple transfer value profiles at one time.)

Required Properties

The Registry Assistant API uses a simplified version of the Transfer Value Profile class to publish the data for a Transfer Value Profile. Refer to the Minimum Data Policy for the required properties for the Transfer Value Profile class.

Publishing a Basic Record

Your system will need to output the data above in JSON format. For example:

Recommended Properties

In order to maximize the utility of the Transfer Value Profile data in the Registry, we recommend you also include data for the following properties:

Sample

To publish the data, you will need to wrap it in an object that also contains a PublishForOrganizationIdentifier property. Naturally, this is where you specify the CTID of the owning organization (from the accounts site). The transfervalueprofile data itself will go in an Transfer Value Profile property:

Sample TransferValueProfile wrapper:

Below is some example code to publish a simple TransferValueProfile object:

Summary

The Registry Assistant API makes it easier to publish data about TransferValueProfiles.

Publishing Your Transfer Intermediaries

Introduction

The Transfer Intermediary class represents a description of a specific Transfer Intermediary. In the context of Credential Engine, a transfer intermediary is a surrogate resource to which other resources are mapped in order to indicate their common transferability. It is used when multiple resources such as courses are grouped together to indicate they have mutually agreed upon transfer value.

References

• Transfer Intermediary class on credreg.net
• The Transfer Intermediary Minimum Data Policy for the required properties for the transfer intermediary class.
• See github for the TransferIntermediary Request class used by the Assistant API.
• See more detailed ready to run examples in github.

To format or publish a Transfer Intermediary Profile, use the following endpoints:

Format Data (only). Note the format endpoint for transfer intermediary only handles a request with just the IntermediaryFor property, not with embedded transfer values like the bulk publish endpoint.

Publish Data (automatically formats first)

Publish Bulk Data (enables publishing transfer value profiles in the same request as a transfer intermediary)

Required Properties

The Registry Assistant API uses a simplified version of the Transfer Intermediary class to publish the data to the registry. Refer to the Minimum Data Policy for the required properties for the Transfer Intermediary Profile class.

Publishing a Basic Record

Your system will need to output the data above in JSON format. For example:

Recommended Properties

In order to maximize the utility of the Transfer Intermediary data in the Registry, we recommend you also include data for the following properties:

Sample

To publish the data, you will need to wrap it in an object that also contains a PublishForOrganizationIdentifier property. Naturally, this is where you specify the CTID of the owning organization (from the accounts site). The transfer intermediary data itself will go in an Transfer Intermediary property:

Sample Transfer Intermediary wrapper:

See more detailed ready to run publishing example in github.

Bulk Publish of Transfer Intermediary with Transfer Value Profiles

There is a separate endpoint that can be used to publish a list of transfer value profiles in the same request as a transfer intermediary:

This endpoint may be useful where there is a smaller number of transfer value profiles and it would be considered more efficient to be able to publish all or some of the transfer value profile in one request.

Below is some example code to publish a list of Transfer Value Profiles with a Transfer Intermediary:

See more detailed ready to run publishing example in github.

Summary

The Registry Assistant API makes it easier to publish data about TransferIntermediaries.

Publishing Your Support Services

Introduction

The SupportService references resources and assistance that help people overcome barriers to succeed in their education and career goals.

Support services can be provided at any stage of an individual's education or career, and may be targeted towards people with or without direct affiliation with an organization. The goal of support services is to provide people with the assistance they need to achieve their full potential. Examples of Support Services include career advice, job placement, childcare, transportation, tools, mentorship, counseling, and other forms of aid.

References

• SupportService class on credreg.net
• The Support Service Minimum Data Policy for the required properties for the support service class.
• See github for the SupportService Request class used by the Assistant API which includes the SupportService class.
• See more detailed ready to run examples in github.

To format or publish a SupportService Profile, use the following endpoints:

Format Data (only).

Publish Data (automatically formats first)

Required Properties

The Registry Assistant API uses a simplified version of the SupportService class to publish the data to the registry. Refer to the Minimum Data Policy for the required properties for the SupportService Profile class.

Publishing a Basic Record

Your system will need to output the data above in JSON format. For example:

Recommended Properties

In order to maximize the utility of the SupportService data in the Registry, we recommend you also include data for the following properties:

Sample

To publish the data, you will need to wrap it in an object that also contains a PublishForOrganizationIdentifier property. Naturally, this is where you specify the CTID of the owning organization (from the accounts site). The SupportService data itself will go in a SupportService property:

Sample SupportService wrapper:

See more detailed ready to run publishing example in github.

Summary

The Registry Assistant API makes it easy to publish data about SupportServices.

Publishing Your Verification Service Profiles

Introduction

The Verification Service Profile class is used in describing the means by which someone can verify whether a credential has been attained.

As well, it includes, but is not limited to, verification of whether quality assurance credentials have been issued for organizations, learning opportunities, and assessments.

References

• Verification Service Profile class on credreg.net
• The Verification Service Profile Minimum Data Policy: CTID, Description, and OfferedBy are the only required properties.
• See github for the VerificationServiceProfile Request class used by the Assistant API and the input class.
• See more detailed ready to run examples in github.

To format or publish a Verification Service Profile Profile, use the following endpoints:

Format Data (only).

Publish Data (automatically formats first)

Required Properties

The Registry Assistant API uses a simplified version of the Verification Service Profile class to publish the data to the registry. Refer to the Minimum Data Policy for the required properties for the Verification Service Profile Profile class.

Publishing a Basic Record

Your system will need to output the data above in JSON format. For example:

Recommended Properties

In order to maximize the utility of the Verification Service Profile data in the Registry, we recommend you also include data for the following properties:

Sample

To publish the data, you will need to wrap it in an object that also contains a PublishForOrganizationIdentifier property. Naturally, this is where you specify the CTID of the owning organization (from the accounts site). The Verification Service Profile data itself will go in a Verification Service Profile property:

Sample Verification Service Profile wrapper:

See more detailed ready to run publishing example in github.

Summary

The Registry Assistant API makes it easy to publish data about Verification Service Profiles.

Publishing Your Occupations

Introduction

The Occupation references a profession, trade, or career field that may involve training and/or a formal qualification.

References

• Occupation class on credreg.net
• The Occupation Minimum Data Policy for the required properties for the Occupation class.
• See github for the Occupation Request class used by the Assistant API which includes the Occupation class.
• See more detailed ready to run examples in github.

To format or publish a Occupation Profile, use the following endpoints:

Format Data (only).

Publish Data (automatically formats first)

Required Properties

The Registry Assistant API uses a simplified version of the Occupation class to publish the data to the registry. Refer to the Minimum Data Policy for the required properties for the Occupation Profile class.

Publishing a Basic Record

Your system will need to output the data above in JSON format. For example:

Recommended Properties

In order to maximize the utility of the Occupation data in the Registry, we recommend you also include data for the following properties:

Sample

To publish the data, you will need to wrap it in an object that also contains a PublishForOrganizationIdentifier property. Naturally, this is where you specify the CTID of the owning organization (from the accounts site). The Occupation data itself will go in a Occupation property:

Sample Occupation wrapper:

See more detailed ready to run publishing example in github.

Summary

The Registry Assistant API makes it easy to publish data about Occupations.

Publishing Your Jobs

Introduction

The Job references a set of responsibilities based on work roles within an occupation as defined by an employer./p>

References

• Job class on credreg.net
• The Job Minimum Data Policy for the required properties for the Job class.
• See github for the Job Request class used by the Assistant API which includes the Job class.
• See more detailed ready to run examples in github.

To format or publish a Job Profile, use the following endpoints:

Format Data (only).

Publish Data (automatically formats first)

Required Properties

The Registry Assistant API uses a simplified version of the Job class to publish the data to the registry. Refer to the Minimum Data Policy for the required properties for the Job Profile class.

Publishing a Basic Record

Your system will need to output the data above in JSON format. For example:

Recommended Properties

In order to maximize the utility of the Job data in the Registry, we recommend you also include data for the following properties:

Sample

To publish the data, you will need to wrap it in an object that also contains a PublishForOrganizationIdentifier property. Naturally, this is where you specify the CTID of the owning organization (from the accounts site). The Job data itself will go in a Job property:

Sample Job wrapper:

See more detailed ready to run publishing example in github.

Summary

The Registry Assistant API makes it easy to publish data about Jobs.

Publishing Your WorkRoles

Introduction

The WorkRole references a set of responsibilities based on work roles within an occupation as defined by an employer./p>

References

• Work Role class on credreg.net
• The Work Role Minimum Data Policy for the required properties for the WorkRole class.
• See github for the Work Role Request class used by the Assistant API which includes the Work Role class.
• See more detailed ready to run examples in github.

To format or publish a WorkRole Profile, use the following endpoints:

Format Data (only).

Publish Data (automatically formats first)

Required Properties

The Registry Assistant API uses a simplified version of the WorkRole class to publish the data to the registry. Refer to the Minimum Data Policy for the required properties for the WorkRole Profile class.

Publishing a Basic Record

Your system will need to output the data above in JSON format. For example:

Recommended Properties

In order to maximize the utility of the WorkRole data in the Registry, we recommend you also include data for the following properties:

Sample

To publish the data, you will need to wrap it in an object that also contains a PublishForOrganizationIdentifier property. Naturally, this is where you specify the CTID of the owning organization (from the accounts site). The WorkRole data itself will go in a WorkRole property:

Sample WorkRole wrapper:

See more detailed ready to run publishing example in github.

Summary

The Registry Assistant API makes it easy to publish data about WorkRoles.

Publishing Your Tasks

Introduction

The Task references a specific activity, typically related to performing a function or achieving a goal.

References

• Task class on credreg.net
• The Task Minimum Data Policy for the required properties for the Task class.
• See github for the Task Request class used by the Assistant API which includes the Task class.
• See more detailed ready to run examples in github.

To format or publish a Task Profile, use the following endpoints:

Format Data (only).

Publish Data (automatically formats first)

Required Properties

The Registry Assistant API uses a simplified version of the Task class to publish the data to the registry. Refer to the Minimum Data Policy for the required properties for the Task Profile class.

Publishing a Basic Record

Your system will need to output the data above in JSON format. For example:

Recommended Properties

In order to maximize the utility of the Task data in the Registry, we recommend you also include data for the following properties:

Sample

To publish the data, you will need to wrap it in an object that also contains a PublishForOrganizationIdentifier property. Naturally, this is where you specify the CTID of the owning organization (from the accounts site). The Task data itself will go in a Task property:

Sample Task wrapper:

See more detailed ready to run publishing example in github.

Summary

The Registry Assistant API makes it easy to publish data about Tasks.

Publishing Your Quality Assurance Actions

Introduction

The Quality Assurance Action (Credentialing Action) references an action taken by an agent affecting the status of an object entity..

References

• Credentialing Action class on credreg.net
• The Quality Assurance Action Minimum Data Policy for the required properties for the Quality Assurance Action class.
• See github for the Quality Assurance Action Request class used by the Assistant API which includes the Quality Assurance Action class.
• See more detailed ready to run examples in github.

To format or publish a Quality Assurance Action Profile, use the following endpoints:

Format Data (only).

Publish Data (automatically formats first)

Types of credentialing actions

Required Properties

The Registry Assistant API uses a simplified version of the Quality Assurance Action class to publish the data to the registry. Refer to the Minimum Data Policy for the required properties for the Quality Assurance Action Profile class.

Publishing a Basic Record

Your system will need to output the data above in JSON format. For example:

Recommended Properties

In order to maximize the utility of the Quality Assurance Action data in the Registry, we recommend you also include data for the following properties:

Sample

To publish the data, you will need to wrap it in an object that also contains a PublishForOrganizationIdentifier property. Naturally, this is where you specify the CTID of the owning organization (from the accounts site). The Quality Assurance Action data itself will go in a Quality Assurance Action property:

Sample Quality Assurance Action wrapper:

See more detailed ready to run publishing example in github.

Summary

The Registry Assistant API makes it easy to publish data about Quality Assurance Actions.

Publishing Your Rubrics

Introduction

The Rubric references a structured and systematic evaluation tool used to assess performance, quality, and/or criteria..

References

• Rubric class on credreg.net
• The Rubric Minimum Data Policy for the required properties for the Rubric class.
• See github for the Rubric Request class used by the Assistant API which includes the Rubric class.
• See more detailed ready to run examples in github.

To format or publish a Rubric, use the following endpoints:

Format Data (only).

Publish Data (automatically formats first)

Required Properties

The Registry Assistant API uses a simplified version of the Rubric class to publish the data to the registry. Refer to the Minimum Data Policy for the required properties for the Rubric class.

Publishing a Basic Record

Your system will need to output the data above in JSON format. For example:

Recommended Properties

In order to maximize the utility of the Rubric data in the Registry, we recommend you also include data for the following properties (see recommended policy.):

Sample

To publish the data, you will need to wrap it in an object that also contains a PublishForOrganizationIdentifier property. Naturally, this is where you specify the CTID of the owning organization (from the accounts site). The Rubric data itself will go in a Rubric property:

Sample Rubric wrapper:

See more detailed ready to run publishing example in github.

Summary

The Registry Assistant API makes it easy to publish data about Rubrics.

Embedded Classes

Within CTDL, there are a number of classes that are published as objects nested within the top level classes described above. The Registry Assistant API works the same basic way. Some of the classes below may be used within more than one of the top level classes. In addition, more than one instance of the classes below may be present in many cases.

Condition Profile

Condition Profile is the workhorse of CTDL. It is a large profile encompassing a variety of properties that define the complex data which forms the glue between resources like Credentials and most other entities: assessments, learning opportunities, competencies, other credentials, etc. The condition profile is in the range of common properties like:

• Requires - Requirement or set of requirements for a resource.
• Recommends - Recommended credential, learning opportunity or assessment.
• Renewal - Entity describing the constraints, prerequisites, entry conditions, or requirements necessary to maintenance and renewal of an awarded credential..
• Advanced Standing From - Credential that has its time or cost reduced by another credential, assessment or learning opportunity./li>
• Entry Conditions - Requirements for entry into a credentialing program, a learning opportunity, or an assessment, including credentials, transcripts, records of previous experience, or other forms of entry documentation.

References

See:

• The Minimum Data Policy for the required properties for this class.
• The Registry Assistant API Condition Profile class in Github. The latter class will indicate which properties are lists and which are singles.
• Sample code to populate a Condition Profile in Github.

Commonly Used Condition Profile Properties

Below are some of the most relevant properties. Refer to the CTDL documentation for the full listing. The following Usage section will have examples of these (from GitHub).

Description

Nov. 13, 2023 Description is NO longer a required property.

If description is provided, the minimum length is 15 characters.

Condition

This property is a list of strings. Useful for listing required conditions such as:
{ "Complete High School", "Have a drivers licence." },

Target Credentials, Assessments, and Learning Opportunities

A credential may require the completion of other resources like assessments, learning opportunities, or other credentials. This requirement can be expressed through a condition profile and one or more of the following properties.

• Target Learning Opportunity - Learning opportunity that is the focus of a condition, process or another learning opportunity.
• Target Assessment - Assessment that provides direct, indirect, formative or summative evaluation or estimation of the nature, ability, or quality for an entity.
• Target Credential - Credential that is a focus or target of the condition, process or verification service.

The above properties are URIs in the credential registry. The API uses the Entity Reference class when publishing these target properties. See the Entity Reference class in Github for all available properties.

This class enables a flexible approach to providing references to other entities, depending on what is available in the publishing system. There are three approaches:

1. Provide just CTID (recommended):
   • If the related entity is in the registry, or soon will be, then just the CTID needs to be provided.
   • The preference between providing a CTID or Id would be the CTID. Then the API can format the URL correctly based on the target credential registry and community/private registry where applicable.
   • There may be a case where a reference is needed for an entity that is in a different community/private registry than the current target (rare, and not yet completely handled). In this case, then the full URL should be provided in the Id property.
2. Provide just Id:
   • If the entity being referenced is already published in the registry, the full URI can be provided, like: https://sandbox.credentialengineregistry.org/resources/ce-a4041983-b1ae-4ad4-a43d-284a5b4b2d73.
   • Note: The convention is to provide the /resources URI, not the /graph URI.
3. Provide Reference Properties:
   • A reference can be made to an entity that doesn’t exist in the registry but does have a URL. In this case, the following can be provided:
     • Type (required). This would be one of ceterms:AssessmentProfile, ceterms:LearningOpportunityProfile, or one of the Credential subclasses such as ceterms:Badge, ceterms:Certification, etc.
     • Name (required)
     • SubjectWebpage (required)
     • Description (optional)
     • See the Entity Reference class in Github for all available properties.

Note: only one of the three options should be provided. The CTID is checked first, then the Id, then the external reference.

Target Competency

A credential may require competencies relevant to the condition being described. The information about a competency is formatted as a Credential Alignment Object and published via the TargetCompetency property.
The commonly used properties are:

• Framework (Optional) - public URL for the framework. Note this would be the credential registry URI for a competency framework published in the credential registry.
• FrameworkName (Optional) - name of the framework.
• TargetNode (Optional) - public URL to this competency. Note this would be the credential registry URI for a competency published in the credential registry.
• TargetNodeName (Required) - name of this competency.
• TargetNodeDescription (Optional) - a description of this competency.
• CodedNotation (Optional) - for example a SOC code of 49-9081.00 (Wind Turbine Service Technicians).

Helper Property: TargetCompetencyFramework

NEW Feb. 03, 2023. The process to format a list of credential alignment objects for a large number of competencies can be difficult depending on how the data is available to the publishing system.
A new helper property was added to condition profile to ease the process of publishing all of the competencies required for a condition: TargetCompetencyFramework. This property will contain one or more CTIDs for a framework that has been published to the credential registry. The API will:

• Validate that a provided CTID is for a framework that exists in the registry
• If valid, the API will extract all competencies from the framwork and format a credential alignment object for each one
• TargetCompetency will be populated with the latter list and published with the ConditionProfile
• NOTE: only one of TargetCompetency or TargetCompetencyFramework may be provided at this time.

Credit Value

The credit value property has a range of Value Profile. A common use for this property is to specify a specified number of semester hours, or degree credits, or clock hours that may be required for a resource.

Alternative Conditions

Alternative Condition are constraints, prerequisites, entry conditions, or requirements in a context where more than one alternative condition or path has been defined and from which any one path fulfills the parent condition. A set of alternative conditions are not necessarily mutually exclusive paths; for example, a set of alternative concentrations for a degree may allow a person to optionally complete more than one concentration even though only one is required to earn the degree.

Usage

Usage

The intended interpretation and usage of the data in a Condition Profile depends entirely on which property it is associated with. For instance, A Condition Profile attached to the "requires" property defines requirements for earning a Credential, whereas a Condition Profile attached to "recommends" is merely informational or advisory in nature, and does not define requirements. Often, such information only applies in certain circumstances - Condition Profile is designed to allow designating and describing these circumstances as well. Other properties also use Condition Profile to define connections between other entities in CTDL, but here we will focus on Credentials.

Note that multiple Condition Profiles defined under the same property (e.g., requires) are considered to all apply to that property if the person pursuing the credential meets the conditions of those profiles. For example, if a credential has 3 Condition Profiles under "requires" and a person pursuing that Credential meets the conditions for two of those Condition Profiles, then that person must meet all of the conditions defined in both of those profiles to earn the Credential.

Cost Profile

Cost Profile is a detailed class meant to convey how much something costs in the context of certain circumstances. There are many situations in which the cost of something depends on some factor of the person trying to earn it, such as residency, military status, citizenship, etc. Use as many Cost Profiles as are necessary to convey the different overall costs for these different combinations of circumstances. You may provide one "general" Cost Profile, and only need to provide additional Cost Profiles for particular situations that are relevant to your credential. You should not provide a Cost Profile for every possible combination of the properties/vocabulary terms listed below unless each of those combinations is significantly different.

References

See:

• The Minimum Data Policy for the required properties for this class.
• The Registry Assistant API Cost Profile class in Github.
• Sample code to populate a Cost Profile in Github.

Usage

A credential registry cost profile includes one direct cost and price per profile. The Assistant API helps simplify the entry of cost profiles with multiple costs. The main cost profile information is provided once, and the individual cost types and price can be provided in a list.

Populating a Cost Profile

The following shows how a cost profile is populated using simple statements.

Cost Profile As JSON

The following shows how that latter code is formatted as JSON (when sent to the Assistant API, not in the registry).

Financial Assistance Profile

Financial Assistance Profile is a class that describes financial assistance that is offered or available. Provide the data that is most appropriate for your situation.

References

See:

• The Minimum Data Policy for the required properties for this class.
• The Registry Assistant API Financial Assistance Profile class in Github.
• Sample code to populate a Financial Assistance Profile in Github.

Usage

A Financial Assistance Profile must include a name and at least one of the following: Description, Subject Webpage, or Financial Assistance Type.

The financial assistance type is a list of one or more concepts that must exist in the ceterms:FinancialAssistance concept scheme. Multiple terms may be included:
FinancialAssistanceType = new List() { "Military", "Veteran" }

Use Financial Assistance Value to provide the actual value of financial assistance available. This property is a list of QuantitativeValues. The QuantitativeValue includes the UnitText property. Financial Assistance Value, the UnitText if present, is expected to be a currency. It is not required if a description is available.

Duration Profile

Duration Profile is a small utility class meant to convey how long something takes. In this case, it is used to indicate approximately how long it will take for the average person to earn this credential. This is often the same as the length of a degree credential's degree program, or the length of a certificate's assessment. Duration Profile allows expressing either an exact duration or a minimum and maximum duration. Provide the data that is most appropriate for your situation.

References

See:

• The Minimum Data Policy for the required properties for this class.
• The Registry Assistant API Duration Profile class in Github.
• Sample code to populate a Duration Profile in Github.

Jurisdiction Profile

Jurisdiction Profile is a class that describes applicable geographic areas and their exceptions. Provide the data that is most appropriate for your situation.

References

See:

• The Minimum Data Policy for the required properties for this class.
• The Registry Assistant API Jurisdiction Profile class in Github.
• Sample code to populate a Jurisdiction Profile in Github.

Usage

A Jurisdiction Profile must have at least one of the following: A global jurisdiction of true, or just a description, or a main Jurisdiction with possible exceptions (jurisdiction exception).

Data in the Registry

Data in the registry is wrapped in a common container, called an envelope. The data your system publishes is transformed into the decoded_payload property of the envelope, and is tracked with other properties. The Registry generates and maintains this structure; you do not publish an envelope.

Structure of a Registry Envelope

The properties for an enevelope are:

Sample envelope structure

Retrieving Data from the Registry

A single record in the registry can be accessed using several methods:

• Via Envelope Identifier
  • This uses /ce-registry/envelopes/, followed by an enevelope identifier (not a CTID)
  • Example: https://credentialengineregistry.org/ce-registry/envelopes/f85997f3-bc9d-4512-93f7-0119e88e20ab
• Via Resource URI
  • This uses /resources/, followed by the CTID for the resource
  • Example: https://sandbox.credentialengineregistry.org/resources/ce-a4041983-b1ae-4ad4-a43d-284a5b4b2d73
• Via Graph URL
  • This uses /graph/, followed by the CTID for the resource
  • Example: https://sandbox.credentialengineregistry.org/resource/ce-a4041983-b1ae-4ad4-a43d-284a5b4b2d73
• Payload Search API. This API is useful when importing all data from the registry. Most partners will be more interested in the Graph Search API.
• Graph Search API. See Credential Handbook Search API

Controlled Vocabularies

Within CTDL, a number of properties leverage controlled vocabularies (also called "concept schemes") to convey concepts in a format that can be understood across multiple systems. A controlled vocabulary works like a miniature schema, defining a set of terms and exactly what those terms mean. In many cases, more than one term from a controlled vocabulary can be used to more accurately define the data being described.

Refer to the Concept Schemes section of the terms page to review the concept schemes in CTDL.