Add ceterms:LearningProgram to the domain of ceterms:aggregateData?

[ChelseaKR]

While mapping California ETPL training program data to CTDL, I found that ceterms:aggregateData cannot attach to a ceterms:LearningProgram under the explicit domain declarations, though it can attach to the parent class.

ceterms:LearningOpportunityProfile's property list carries 104 properties and ceterms:LearningProgram's carries 103. The one property present on the parent and absent from the subclass is aggregateData. Sampling the shared properties (estimatedDuration, deliveryType, targetLearningResource) shows the convention is explicit enumeration, with each naming both classes, so aggregateData appears to be the single property where LearningProgram was not enumerated.

Observed in the term JSON at https://credreg.net/ctdl/terms/aggregateData/json and https://credreg.net/ctdl/terms/LearningProgram/json, retrieved 2026-08-06.

The practical stake: AggregateDataProfile is where earnings and completion counts live, and state ETPL-derived data is outcome-bearing learning programs. A validator or publisher coding against the per-class list will reject outcome data on a LearningProgram that the parent class permits.

Should LearningProgram (and possibly Course) be added to aggregateData's domainIncludes, as #850 did for degreeConcentrations? If the intended pattern for program outcomes is instead qdata:DataSetProfile referencing the program, a note in the aggregateData usage guidance would save implementers the wrong turn.

Happy to open a PR against the schema files if that is welcome! Thanks y'all.

[philbarker]

Thank you @ChelseaKR, we will look into this and fix it. Going forward we intend to promote the use of qdata:relevantDataSet and qdata:DataSetProfile as described here: https://credreg.net/ctdl/handbook#qdataschema . The older approach will stay in the schema and will still be (quietly) supported. That definitely should be better documented, and we should fix the inconsistency you note for those who use the older approach.

[jeannekitchens]

@ChelseaKR thank you for postiing this. In the Credential Registry we removed support for publishing aggregateData and rather support publishling Metrics with Observations via DataSetProfile via relevantDataSetFor / relevantDataSet. See the Qdata schema https://credreg.net/qdata/terms. Let us know if you have any questions or if you'd like to chat.

[ChelseaKR]

Thank you both — that settles it for my use case: I'll publish the ETPL outcome data as qdata:DataSetProfile with Metrics/Observations linked via relevantDataSet / relevantDataSetFor, rather than aggregateData.

Context, in case it's useful: this issue came out of a working pipeline mapping California's Eligible Training Provider List data (CalJOBS/EDD program records with completions and earnings) to CTDL. California's Registry presence today is community-college/CPL-led through the MAP Initiative, so state workforce outcome data is the corner of the schema this project keeps exercising. If it would help the QData documentation effort to see how a state ETPL dataset lands in DataSetProfile/Metrics/Observations, I'm happy to share the mapping and notes on where the guidance was ambiguous.

@jeannekitchens I'd welcome that chat — the granularity of Observations for state outcome data (per-program vs. per-cohort vs. per-reporting-period) is the design question I'd most value your read on. What's the best way to set up time?

@philbarker would you take a handbook PR adding a note to the aggregateData usage guidance that the Registry no longer accepts it for publishing, pointing to the qdata pattern instead? That's the wrong turn my original post was trying to prevent.

[jeannekitchens]

@ChelseaKR good to know! Let's chat. Here's my scheduling link https://calendar.app.google/5zdLS4nL3W5mc42B9 . Looking forward to chatting soon.