Create a reference-data library
Use the reference-data workspace for general vocabulary and ontology content. Choose the resource that matches the result you need:
| Resource | Use it to |
|---|---|
| Library or ontology | Establish the context and namespace for a maintained body of content. |
| Class | Describe a reusable kind of thing below an existing class. |
| Property | Describe a reusable characteristic or relationship. |
Use a specialized CFIHOS+, IMF, or symbol workspace when those domain rules apply.
Older examples may mention annotation-property or SHACL-shape authoring routes. Those routes are not supported and must not be used.
What you should prepare first¶
Before you start, prepare:
- the target library for a class or property;
- a parent class or other structural context for a class;
- domain/range or equivalent semantics for a property, as required by the form; and
- any upper ontologies for a new library.
A new library can also include a CFIHOS namespace prefix and an automatic backup frequency of daily, weekly, or monthly. If the library will be used for CFIHOS+, both the CFIHOS namespace prefix and CFIHOS RDL v2.0 as an upper ontology must be set. Choose these settings with the collection owner; they are operational settings, not content review outcomes.
Create in the PCA platform¶
- Search for the library, class, property, and close alternatives.
- Open Create > Reference data and choose Library, Class, or Property.
- Select and verify the target library when the resource is not itself a library.
- Enter the definition, justification, relationships, sources, and mappings.
- For a library, configure upper ontologies and the agreed backup frequency. For a CFIHOS+ library, also set the CFIHOS namespace prefix and select CFIHOS RDL v2.0.
- Choose Save as Draft.
- Follow View draft, check the generated IRI and status, and edit if required.
- Use Submit for review only when the Draft is complete.
Create through the API¶
If you use the API, the main reference-library creation endpoints include:
POST /ontologies/domainsfor a library/ontology;POST /rdl/terms/subclassfor a class; andPOST /general/propertyfor a property.
Typical technical workflow:
- Authenticate with the correct role.
- Build the payload for the specific content type.
- Include
changeJustification,name,description, and the target library where required. - Add the type-specific structural fields.
- Store the returned Draft location or identifier.
- To edit, send
PUTto the same route with the Draft IRI iniri. - Submit the complete Draft with
PUT /status/submit?iri=<encoded-IRI>.
changeJustification is mandatory. Be precise about the ontology you are writing
into, and search for near-duplicates before creating a differently worded concept. The
API endpoint and error reference contains the shared
request fields and response behavior; Work with drafts and submit content
explains what to do with the returned Draft.