Open jeannekitchens opened 1 year ago
I don't think we need specific properties for every niche of data that someone can publish unless they are common to enough distinct publishers to be worthwhile (otherwise we will end up merging everyone's bespoke schemas together and not have any interoperable data).
Instead, for cases like this, we should ensure there is a property that allows some degree of flexibility/customization in what it describes. It's hard to tell whether exactly something like that already exists in Qdata (perhaps qdata:subjectsInSet or qdata:subjectValue?), but if not, then something explicitly intended for "other" data like the above would be the way to go. Then there is at least some degree of interoperability (everyone using the same custom property) without blowing up the size of the schema. We can then monitor that for potential candidates for specific properties.
Something like this perhaps:
URI: qdata:dataPoint Label: Data Point Description: A piece of information for which there is no more specific property. Domain: qdata:DataProfile Range: schema:QuantitativeValue
Usage in the above example:
{
"@type": "qdata:DataProfile",
"qdata:dataPoint": [
{
"@type": "schema:QuantitativeValue",
"schema:description": { "en": "Average loan amount at graduation." },
"schema:value": 12345,
"schema:unitText": [ "res:ce-for-USD" ]
},
{
"@type": "schema:QuantitativeValue",
"schema:description": { "en": "Percent of graduates with loans." },
"schema:percentage": 0.5
},
{
"@type": "schema:QuantitativeValue",
"schema:description": { "en": "Loan as a percentage of first year wages." },
"schema:percentage": 0.25
}
]
}
Part of solving this may involve solving #875 since that will have implications for whether or not schema:currency needs to be part of schema:QuantitativeValue.
I think debt is important, not a niche case. Especially globally.
It is kind of a consequence of fees Vs funding options, and the funding options depend on student circumstances in varied way. For example an English student of Computer Science at HW is going to graduate with a much higher debt than a Scots student, because the Scottish government pays the tuition fees directly to the university.
Is that the sort of thing that subjectType deals with?
BTW, there is no schema:percentage
property.
My point wasn't that debt in general is niche, it is that these specific ways of measuring it are ones we haven't seen from other publishers yet (as far as I am aware) and we don't want to go adding every institution's specific ways of measuring things into QData if nobody else uses those same measures. We should incorporate the ones that are used by multiple institutions in order to facilitate sharing. A generic property can handle things specific to a single institution (ie "niche").
If we see those specific measures from other institutions, then they may be candidates for new properties, but I think we should look around first to see what other institutions use for similar notions. We don't want to end up with 17 very subtly different debt-related properties when 2 or 3 would do (and facilitate better interoperability) in the long run.
@siuc-nate OK, got you. Let's start with debt as generic and then think about how to describe whose debt is being measured, how and when. I think there are common ways of defining the how and when (though maybe that's my European view of how these things are done) I would look to something like OECD for those.
Per our 7/10/2023 meeting: Example data: https://sandbox.credentialengine.org/finder/credential/50787 Example descriptions (currently done via qdata:holdersInSet):
Text descriptions will do for a first pass, it'll give an indication to prospective students. Go for it.
It won't be sufficient for serious analytics, for that you need identifiers for common methodologies for measuring all the variables -- but that would probably need a task group to sort out, if we need to and feel able to.
BTW @siuc-nate the example data above shows schema:percentage": 0.5
: that should be qdata:percentage": 50
@jeannekitchens @philbarker Can you both confirm that the plan, then, is to move forward with the proposal from this post?
URI: qdata:dataPoint Label: Data Point Description: A piece of information for which there is no more specific property. Domain: qdata:DataProfile Range: schema:QuantitativeValue
Confirmed.
There needs to be a property or concept for student debt or studen loan debt. With data set profile, users e.g., state governments can include a description that is based on the way they calculate student loan debt but publishers and consumers need to know that the date they're publishing or getting is about student loan debt. If the final proposal is only to add Data Point, I don't believe this addresses the use case.
Do we have enough data from enough states to know how they measure it (see example above - measured as a loan in absolute dollars, measured as debt (ie minus any grants/payments/etc), measured as a percentage of wages, whether there is a time component involved (e.g. first year's wages, debt over 10 years, etc). There is a lot of potential variation and if we want data that speaks a common language that all states can share/compare among each other, we'll need to come up with what the common denominator should be.
There is also a similar question for how this is handled internationally.
There can be multiple types of calculations for student debt, the main point it to know the data is about student debt. They use the description to describe how they do the calculation with the data set profile and they also do this with the data set. We don't need to document the calculations, rather the type of data.
Would this be something specific to student loans, or debt in general? Also, are there any issues with using the term "student" as opposed to "learner" or one of the other more generic terms like that? I guess what I'm asking is, how broadly/narrowly should we scope such a property?
It's only relevant to students accumulating debt to cover costs for learning and debt is via loans.
This is where putting all data in an AggregateDataProfile fails. The clearest solution is to have a StudentDebtProfile class so that rdfs:type can do its job of telling data consumers what type of thing the data is about no matter what property points to it (e.g. it could be referenced from outside the registry using a non-CTDL property). Next best would be a dataSetType property pointing to concepts such as StudentDebtProfile.
For context, Phil, we're looking at adding a property to DataProfile with a range of either QuantitativeValue or MonetaryAmount, so that would work the same way as all the other properties on DataProfile in QData. AggregateDataProfile isn't in play here and the contextual information is provided by QData classes higher up the hierarchy.
@siuc-nate sorry, sometimes it's hard to keep track of these long-running issues, especially times like now when several are in play at the same time. I got mislead by the issue title :-}
This is an Equity Council use case to publish the debt of graduates analyzed alongside wages.
Here's some globally utilized student debt/aggregate outcome statistics:
Sources Include:
United State College Scorecard Glossary of Outcome Data https://collegescorecard.ed.gov/data/glossary/
State of Texas Definitions for Sudent Loan/Debt Statistics: