Adding "constraints" to string validation (enum, pattern)

[colleenXu]

[For post-2.0]

We could add more "constraints" to string fields to flesh out, standardize, or add detail to their implementation. This would also add more stringent validation.

I previously reviewed the entire schema (2026-02-07, probably branch 2.0) and came up with this (copied, cleaned up #538 (comment)):

Add enum to...

• statuses:
  • AsyncQueryResponse.status
  • AsyncQueryStatusResponse.status
  • Response.status
  • LogEntry.code
• knowledge_type: lookup or inferred (aka creative-mode)
  • QEdge.knowledge_type
  • MetaEdge.knowledge_types.items

Add `pattern` to...

• URLs (similar to AsyncQuery.callback's pattern):
  • AsyncQueryStatusResponse.response_url
  • Attribute.value_url
  • RetrievalSource.source_record_urls.items
• semantic-version
  • Response.schema_version
  • Response.biolink_version
• LogEntry.timestamp
• biolink terms only?
  • MetaQualifier.qualifier_type_id (could use Qualifier's)
  • Attribute.attribute_type_id
  • MetaAttribute.attribute_type_id
  • AttributeConstraint.id

Add infores `pattern` to source IDs?

Source-related fields.

• RetrievalSource.resource_id
• RetrievalSource.upstream_resource_ids.items
• Analysis.resource_id
• QEdgeConstraints.sources.values
• Attribute.attribute_source
• MetaAttribute.attribute_source

[colleenXu]

Note: there is an old PR https://github.com/NCATSTranslator/ReasonerAPI/pull/406/changes but it may have issues...

The json-schema regex flavor doesn't allow many shortcuts - so ^\S+:\S+$ wouldn't be allowed (what about openapi's regex flavor?)

[colleenXu]

And...what about constraining values to biolink enums or terms? Ex: Edge.knowledge_level to the biolink:KnowledgeLevelEnum, or qualifier_type_id to a biolink:qualifier or its children.

I wonder if this would be helpful, and if it would be straightforward to set up or not.

Or maybe this isn't in the realm of the spec and is instead covered by the implementation/validator like TOM