Financial Assistance Terms or Concept Scheme

[stuartasutton]

The ceterms:financialAssistance property has a range of a CredentialAlignmentOvject and yet there is no framework referenced? Is this an oversight? Or should the range be rdf:langString?

[siuc-nate]

The FinancialAlignmentObject was created to be the thing that financialAssistance points at. It isn't used anywhere else, but it does provide for a framework.

There is no predefined framework/vocabulary on our end - this would be used similarly to industryType, occupationType, and instructionalProgramType, though a bit more loosely. In general the framework would be the type of financial assistance and the target would be some specific area of that assistance (possibly the same URI). It may rely more heavily on the self-contained name and description properties, though.

[stuartasutton]

Yup, but it was created by me under the assumption that the finance alignment object would need additional properties unique to it. So far that has not appeared to be the case.

[stuartasutton]

Well, yes. That was what I was implying. But in other cases where we have used a alignment object, there was at least one such vocabulary out there. I know of none for categorizing financial aid types.

[siuc-nate]

I think the association was looser, perhaps somewhat more comparable to competencies in a PDF. Something like:

{
  "@type": "ceterms:FinancialAlignmentObject",
  "ceterms:frameworkName": "National financial aid",
  "ceterms:framework": "http://someurl.com",
  "ceterms:targetNodeName": "Tuition assistance",
  "ceterms:targetNodeDescription": "Provides financial aid etc etc.",
  "ceterms:targetNode": "http://someurl.com/tuitionassistance"
}

We wanted to account for cases where links were or were not available while also allowing a more refined description of the aid if needed, so the structure and properties of AlignmentObject was a good fit.

I could see replacing the property's range with a range of xsd:anyURI and making it a subclass of ceterms:subjectWebpage, but that might be too limiting.

[stuartasutton]

Nate my problem is with: "so the structure and properties of AlignmentObject was a good fit". My response continues to be "so what". AlignmentObject (and any subtype of it) has a meaning that is controlling; and, that meaning is that there is a framework referenced. If there is no framework on the other end, use of AlignmentObject and its subtypes is inappropriate.

[stuartasutton]

Given that in the absence of any defined classifications | category lists | enumerations for types of financial assistance, use of any derivative of AlignmentObject would be definitionally inappropriate.

We could create a ceterms:FianancialAssistantClassification type and and declare it the CER Target Scheme of ceterms:financialAssistance (see ceterms:industryType and ceterms:IndustryClassification as property and class templates). For those cases where there is no suitable instance of ceterms:FianancialAssistantClassification, then the solution is not to put what is nothing more than a literal in a CredentialAlignmentObject but rather to also have a literal option.

Add

URI: ceterms:FinancialAssistanceClassification Label: Financial Assistance Classification Definition: Class of concept schemes defining types of financial assistance. Type of Term: rdf:Class Subclass Of: ceterms:CredentialFramework

Add

URI: ceterms:financialAssistanceDescription Label: Financial Assistance Definition: Types of financial assistance for a qualified credential, learning opportunity or assessment. Type of Term: rdf:Property Range Includes: rdf:langString

[siuc-nate]

There may well exist such categories/etc., but I'm not familiar enough to list them. @jkitchensSIUC can probably list some, since they're relevant to some of our other projects here.

Also, would this relate to DefinedTerm and DefinedTerm set somehow?

Somewhat of a side issue, but: as for the description property and how your approach relates to our solution for industryType and occupationType and instructionalProgramType, would we need an "industryTypeDescription" (and so on for the other properties) too? Note that in the editor we have, for some time now, enabled additional industries/occupations to be entered and have been merging them in with industryType/occupationType while publishing, even though they don't refer to any framework and are just text.

[stuartasutton]

Well, I was not aware you were doing that with the editor or using the CredentialAlignmentObject in that manner, Nate. We've discussed CredentialAlignmentObject not being used as a convenient data structure in the absence of a framework so many times I've lost count. In essence, no framework, no use. So my answer if "yes", if they're just entering text without a framework to back it up, then there needs to be a property defined with a range of rdf:langString to capture that data. But before doing anything, do we have any idea how many instances there are of CredentialAlignmentObect being used in this manner?

[siuc-nate]

That would be a question that @cwd-mparsons can probably answer. The thing is, sometimes there is a framework, and sometimes there isn't (i.e., a non-NAICS industry framework, maybe). But for this particular case, having such properties might make more sense.

[cwd-mparsons]

For 'other' entries, there are 112 industries, 83 occupations, and 1 instructional program.

[stuartasutton]

Sorry, Michael, I didn’t make myself clear. So the only places where we have, with the editor, saved literals to the CredentialAlighnmentObject are with industries, occupations, and instructional program types.

[stuartasutton]

Nate, I want to return to your example above (reproduced below) and discuss a couple of issues. I know the data in the example is fictitious, but let's assume it is real.

{
  "@type": "ceterms:FinancialAlignmentObject",
  "ceterms:frameworkName": "National financial aid",
  "ceterms:framework": "http://someurl.com",
  "ceterms:targetNodeName": "Tuition assistance",
  "ceterms:targetNodeDescription": "Provides financial aid etc etc.",
  "ceterms:targetNode": "http://someurl.com/tuitionassistance"
}

This, in fact, assumes that there IS a framework (it has a URI, it has node URIs etc). This is a legitimate use of CredentialAlignmentObject since these fictitious URIrefs would actually resolve to some data. I thought the problem here was the result of not having an actual framework to reference and wanting to provide a text value. No?

[siuc-nate]

I guess my thinking goes like this:

• Sometimes you have a competency/framework with a URI; sometimes you don't. In either case, use of CredentialAlignmentObject allows conveying as much data as you have available about 1-n competencies.
• Sometimes you have a financial aid resource/particular resource within that resource with a URI; sometimes you don't. In either case, use of CredentialAlignmentObject allows conveying as much data as you have available about 1-n financial aid resources.

[stuartasutton]

NOTHING says the framework has to have a URI. The question is whether the text you want to include comes from an articulated framework. It either does or it doesn't. If it doesn't, then it's just plain text and a property with a range of rdf:langString will do it.

I'm going to give up on arguing AlignmentObject as a semantic unit and give in to a view that it's just a convenient data structure. I've explained the problem countless times and we always end up in this same place.

[siuc-nate]

Apologies, I didn't mean to imply that the framework will always have a URI. My intent was to be able to cover cases where it does, as well as cases where it doesn't. The convenient data structure of the alignment object also enables recording more than one instance of something, whereas a single literal/string property may only allow providing one item, or may make it difficult to relate the name of a financial assistance resource to a description of it.

I do understand the definition of the object doesn't fit - perhaps we should do something about that instead?

[stuartasutton]

Can you show me an instance of an AlignmentObject that records more than one instance of something. Not sure what that means.

[siuc-nate]

Sorry, again - I meant that you would use multiple objects to tie the data together, as opposed to using just properties. In other words:

"ceterms:financialAssistance": [
  {
    "@type": "ceterms:FinancialAlignmentObject",
    "ceterms:targetNodeName": "The name of the financial assistance",
    "ceterms:targetNodeDescription": "This describes a financial assistance for something."
  },
  {
    "@type": "ceterms:FinancialAlignmentObject",
    "cterms:frameworkName": "Some Framework",
    "ceterms:framework": "http://someframework.com",
    "ceterms:targetNodeName": "The title of some financial assistance",
    "ceterms:targetNodeDescription": "This is a description of the financial assistance."
  },
]

versus something like

"ceterms:financialAssistanceName": [ 
  "The name of the financial assistance", 
  "The title of some financial assistance"
],
"ceterms:financialAssistanceDescription": [ 
  "This describes a financial assistance for something.", 
  "This is a description of the financial assistance."
],
"ceterms:financialAssistanceFrameworkName": [
  "Some Framework"
],
"ceterms:financialAssistanceFramework": [
  "http://someframework.com"
]

If all you use are properties, you can't group information together.

[stuartasutton]

OK @siuc-nate & @jkitchensSIUC, I think we may be barking up the wrong tree with this one.

On yesterday's team call (2017-10-03), Nate and I talked about using something like schema.org Intangible for this purpose of handling financial assistance information. But should we perhaps be looking at a FinancialAssistanceProfile that covers grants, work-study opportunities, scholarships, and loan programs? At least in the U.S., such financial assistance is a key component and concern to learning opportunities and, therefore, to credentialing. For example, see my local community college's: (1) aid homepage; and (2) aid program types page. See also the similar subjectWebpage for Stanford and for financial aid for its Law School JD.

I would assume that we might have the same profile/manifest type situation as we have with costs and conditions.

[stuartasutton]

Following through on that thought, we would:

1. Deprecate the FinancialAlignmentObject;
2. Create a new FinancialAssistanceProfile (and a FinancialAssistanceManifest?);
3. Change the range of financialAssistance to both FinancialAssistanceProfile and FinancialAssistanceManifest; and
4. Develop a minimal set of properties for FinancialAssistanceProfile and FinancialAssistanceManifest.

[siuc-nate]

@stuartasutton can you provide an example of the properties/structure of such a FinancialAssistanceProfile?

For the record, the reason we had used AlignmentObject for this was so that we wouldn't need to schematize the various ways in which financial assistance can be structured - we just wanted to point to it. This saves a lot of complexity, and ensures we don't miss something important since none of us are experts in this field.

I really don't think we want to get into trying to define a schema for financial assistance (as a standalone entity), much less take the extra step of creating a manifest for it.

Descriptions of financial assistance can take whole websites - let those do their job, let us just reference them. Let's not reinvent the wheel.

[stuartasutton]

@siuc-nate & @jkitchensSIUC , this thread is so convoluted that it's not worth much. Let's go back to the top where I asked a quite simple question:

The ceterms:financialAssistance property has a range of a CredentialAlignmentObject and yet there is no framework referenced? Is this an oversight? Or should the range be rdf:langString?

[siuc-nate]

If anything it should be xsd:anyURI - we just wanted to be able to let the user say "I am referencing [type of financial aid], specifically [some subset of the aid]" - or to phrase it in a more framework-y way, "I am referencing [specific type of financial aid] from [general category of financial aid]".

We were using [Financial]AlignmentObject (yes, because it is a data structure) because it permits the user to provide both text and URI information (or just one or the other if one isn't available) about the aid so that it is as clearly and specifically referenced (and/or described) as possible.

It was supposed to be similar to how we use the NAICS/SOC codes (with optional non-code, non-URI-able text strings), but without (in some cases) the code itself.

Unfortunately, I cannot provide concrete examples since I am not familiar enough with the various kinds of financial aid. I would need to do some further research in that regard.

[stuartasutton]

"It was supposed to be similar to how we use the NAICS/SOC codes (with optional non-code, non-URI-able text strings), but without (in some cases) the code itself."

But NAICS/SOC codes identify things in a framework (enumeration)...since we have no enumeration, why not ceterms:financialAssistance range that includes xsd:langString and xsd:anyURI?

[siuc-nate]

We want to enable the user to provide as many of the following as possible:

• Text name
• Text description
• URI Without wanting to restrict the user to only being able to provide one, or to requiring any particular of combination of the three. This is why the data structure of the AlignmentObject is so useful - it lets you provide 1, 2, or 3 of the above properties without mattering which one(s) you pick.

If we only provide a property that lets you put in a string or a URI, you would have no way to associate a text name or text description with a URI that you put in (which, again, is why we used AlignmentObject as a data structure).

Additionally, we have found it is much easier to develop for a schema whose property ranges are of the same type - otherwise the code for publishing and/or consuming has to investigate the data, figure out what kind of data it really is, and then make use of it. It also means you can't explicitly define the property in the context, which in turn means that your URIs have to be encoded as objects with @id properties.

One way around this would be to provide two properties: financialAssistance as a URI financialAssistanceDescription as text We did this with a few other properties - but the problem then becomes that you can only define one kind of financial assistance for whatever it is you are describing. You need to be able to group the data together into a list of 0-n objects - which, again, is why AlignmentObject is so useful as a data structure.

Would it solve the semantic problem if we had another object that was explicitly meant for "describing and/or referencing" external things? It could structurally mimic AlignmentObject without the baggage of the implication that it exists to align something - which I thought was the entire reason you came up with FinancialAlignmentObject.

It would be the same basic concept as the pointer/reference objects that we were using for external entities, but without the @id-related problem that led us to push them to somewhere else in the graph. Something like:

{
  "ceterms:financialAssistance": [
    {
      "@type": "ceterms:Reference",
      "ceterms:targetUrl": "http://some-financial-aid.com/aidtype/123",
      "ceterms:codedNotation": "123",
      "ceterms:targetName": "Name of the financial aid type",
      "ceterms:targetDescription": "Some text that describes the financial aid type"
    },
    {
      "@type": "ceterms:Reference",
      "ceterms:targetUrl": "http://another-financial-aid.org/aid/category/abc/098",
      "ceterms:targetName": "Name of the financial aid type",
      "ceterms:targetDescription": "Some text that describes the financial aid type",
      "ceterms:targetFrameworkUrl": "http://another-financial-aid.org/aid/category/abc",
      "ceterms:targetFrameworkName": "Name of the general category of aid"
    },    {
      "@type": "ceterms:Reference",
      "ceterms:targetUrl": "http://yet-more-aid.net/1234567"
    },
    {
      "@type": "ceterms:Reference",
      "ceterms:targetName": "Financial Aid without a URL or URI to reference",
      "ceterms:targetDescription": "Some text that describes the financial aid type"
    },
  ]
}

This is why we needed to use an object - we needed to be able to reference things that may or may not have a URI, and be able to provide "backup text" if they didn't (or supplementary text even if they did), and be able to provide more than one instance of such a thing. An array of objects (of whatever @type) is the only practical solution I know of to achieve this.

Note that it's probably extraneous to include the "targetFrameworkUrl" and "targetFrameworkName" properties in the case of financial aid - i put them in to illustrate how they might be used. Properties like that, which reference the broader set of things from which the thing being referenced comes (whether it's called a framework or not), may be useful for other things that you might use a ceterms:Reference with. That part is beside the point I am trying to make.

[stuartasutton]

"We want to enable the user to provide as many of the following as possible:

• Text name
• Text description
• URI Without wanting to restrict the user to only being able to provide one, or to requiring any particular of combination of the three. This is why the data structure of the AlignmentObject is so useful - it lets you provide 1, 2, or 3 of the above properties without mattering which one(s) you pick."

This should be solved with a profile and not an AlignmentObject!

[siuc-nate]

This should be solved with a profile and not an AlignmentObject!

Which is why I asked:

Would it solve the semantic problem if we had another object that was explicitly meant for "describing and/or referencing" external things? It could structurally mimic AlignmentObject without the baggage of the implication that it exists to align something - which I thought was the entire reason you came up with FinancialAlignmentObject.

However, the name "profile" brings with it the implication of a full array of properties to describe and define something - it's much more than just a reference. As I have stated, I don't think we want to try to schematize the whole universe of financial aid (as we tried to do with CostProfile, ProcessProfile, etc.). "Profile" also tends to imply a specific topic or purpose, whereas a generic reference could be used in other situations as well.

[siuc-nate]

To expand on this a bit, a reference would be very much like a hyperlink on a webpage. For instance:

<a href="http://someurl.com/123/abc" title="this is some descriptive text">visit me</a>
<a href="" title="a link without a url still provides some textual information">you can read this on the page</a>
<a href="http://verysmalllink.com/543"></a>

All three will each present a functional HTML tag (the last one may not show up visibly without some styling, but it would still lead somewhere and be machine-readable) with varying degrees of usefulness.

Compare:

{
  "ceterms:financialAssistance": [
    {
      "@type": "ceterms:Reference",
      "ceterms:targetUrl": "http://someurl.com/123/abc",
      "ceterms:targetName": "visit me",
      "ceterms:targetDescription": "this is some descriptive text"
    },
    {
      "@type": "ceterms:Reference",
      "ceterms:targetName": "you can read this on the page",
      "ceterms:targetDescription": "a link without a url still provides some textual information"
    },    {
      "@type": "ceterms:Reference",
      "ceterms:targetUrl": "http://verysmalllink.com/543"
    }
  ]
}

It's the same data, with the same levels of usefulness, just written a different way.

That is what I am trying to accomplish with a generic reference class - so far we've just been hijacking AlignmentObject to do it, since it is a close structural match.

[philbarker]

@siuc-nate my way of viewing this is that all the objects in the credential registry are ways of describing and or referencing external things. The only variables are 1) are you describing / referencing the thing itself or another description of it, 2) how much detail & precision you want to provide.

If you reference the thing, you can @type it appropriately-- that may be more useful than just saying "here's a description some unknown type of thing, but it is part of how much detail/precision you want to provide. You may use @id or schema:url for the identifier of the thing itself (which may resolve to something human readable), and schema:mainEntityOfPage to link to a description of it. schema:name and schema:description are the name and description of the thing you're referencing (no need for target*). All properties are optional.

So, assuming you want to add little more detail / precision about what you are referencing, your examples would become:

{
  "ceterms:financialAssistance":  {
      "@type": "ceterms:FinancialAssistanceReference",
      "ceterms:url": "http://verysmalllink.com/543",
      "ceterms:name": "A Financial Assistance Package",
      "ceterms:description": "this is some descriptive text of the package",
      "ceterms:mainEntityOfPage": "http://someurl.com/123/abc"
    }
}

[I assumed all the three JSON Objects in your array referred to the same thing, otherwise just split them] tbh: I don't myself see any difference between ceterms:FinancialAssistanceReference and ceterms:FinancialAssistanceProfile because the @type names identify the type of thing, not the amount of detail provided. I would prefer Profile for consistency.

[stuartasutton]

Yes, Phil. Your analysis is spot on. What you describe is generally what the proposed FinancialAssistanceProfile would do. Exactly what and how much detail is a conversation we've not reached. We have an endless supply of real world examples.

[siuc-nate]

It is the detail that I am trying to avoid - it has been a slippery slope we have fallen down many times in the past. My hope is that by setting up a generic reference object, we prevent ourselves from sliding down that slope, because any type-specific properties wouldn't make sense to put in a generic reference class.

[siuc-nate]

Per our 3/23/2018 call:

• Create a FinancialAssistanceProfile with these properties:
  • Name
  • Description
  • Subject Webpage
• Deprecate FinancialAlignmentObject
• Change the range of financialAssistance from FinancialAlignmentObject to FinancialAssistanceProfile

[siuc-nate]

These changes have been made in pending CTDL and noted in the history tracking.

[stuartasutton]

In the pending release (http://credreg.net/ctdl/release?releaseID=20180427) under "Mapping Changes Implemented in this Release", there is an entry for ceterms:FinancialAssistanceProfile. Included in the changes to properties in this class, the release lists "addition: ceterms:FinancialAlignmentObject". Since ceterms:FinancialAlignmentObject is deprecated in this Release, how can it be "added" to ceterms:FinancialAssistanceProfile. (see https://github.com/CredentialEngine/vocabularies/issues/466#issuecomment-375788783

[cwd-mparsons]

@stuartasutton Stuart, I had a request to add financial assistance to the bulk upload. Upon reviewing the editor and the API, I saw that they were still using the financial alignment object. I want to confirm that I should:

• add the financial assistance profile to the editor, and API
• convert existing FAO (20ish) to FAP
• republish
• remove all references to FAO

[stuartasutton]

The FinancialAlignmentObject was removed long ago. First, who asked for the FinancialAssistanceProfile to be added to the API? It's a very skeletal entity and should be further fleshed out.

[cwd-mparsons]

Jeff Gran raised the request. The source is to be able to publish info about financial assistance for veterans.

[stuartasutton]

Thanks, Michael.

On Tue, Jul 2, 2019 at 9:53 AM Michael Parsons (CWD) < notifications@github.com> wrote:

Jeff Gran raised the request. The source is to be able to publish info about financial assistance for veterans.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/CredentialEngine/vocabularies/issues/466?email_source=notifications&email_token=AAWNRJVTL7HRJWNLZDY6R6DP5OBXRA5CNFSM4D4XHZK2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZB42GQ#issuecomment-507759898, or mute the thread https://github.com/notifications/unsubscribe-auth/AAWNRJWVUUM75ELS7W4EG3DP5OBXRANCNFSM4D4XHZKQ .

[jeff-grann]

Yes, this came up during the Indiana Appathon. A participant asked about searching for credentials eligible GI Bill veteran benefits. Discussion with the Higher Education Advisory Board confirmed support for this use case and provided several helpful considerations for the solution design. Specifically, they advised to prioritize the most helpful information for particular users and connecting to a trusted federal source for this information. Subsequent investigation identified the US Department of Veterans Affairs GI Bill Comparison Tool https://www.va.gov/gi-bill-comparison-tool as an authoritative federal source aggregating key information concerning the eligibility of credentials for veteran financial assistance. The data for this tool are made available for download in Excel format and updated quarterly. These data are described via a Data Dictionary worksheet, a Data Sources worksheet, and via a descriptive webpage.

To support this work, I propose we extend CTDL’s Financial Assistance Profile to support a new MilitaryIndicator concept scheme defined as “Types of officially defined indicators pertinent to military populations.” This concept scheme should have 2 specific concepts

1. Add concept DOD Memorandum of Understanding for Tuition Assistance defined as “Educational institutions that have signed the revised DoD Voluntary Education Partnership MOU”. Source codes originate on the TA Decide webpage. (n = 2,216 institutions)

2. Add concept Yellow Ribbon defined as “Institutional participate in the Yellow Ribbon Program”. Source codes originate on the VA annual yellow ribbon webpage. (n=2,751 institutions)

BTW: Because financial assistance is a large domain, we should consider if the approach we adopt for military indicators will scale well in the future (such as for Pell Grant eligibility).

[siuc-nate]

I'm on board with using a concept scheme to indicate financial assistance type, but I would do it at a broader level to cover cases beyond the military use case.

[siuc-nate]

Explore: https://ceds.ed.gov/domainEntitySchema.aspx Postsecondary -> PS Student -> Financial Aid

We could create a concept scheme from a combination of Financial Aid Award Type and Financial Aid Veteran's Benefit Type, as a basis. https://ceds.ed.gov/CEDSElementDetails.aspx?TermxTopicId=37749 https://ceds.ed.gov/CEDSElementDetails.aspx?TermxTopicId=41080

[siuc-nate]

Per our 8-20-2019 meeting:

• Create a concept scheme:

  URI: ceterms:FinancialAssistance Label: Financial Assistance Definition: Types of financial assistance.

• Create top-level concepts:

  URI: financialAid:General Label: General Financial Assistance Definition: Generally-available financial assistance.

URI: financialAid:Veteran Label: Veteran Financial Assistance Definition: Financial assistance available to veterans.

URI: financialAid:Illinois Label: Illinois Financial Assistance Definition: Financial assistance applicable within the state of Illinois.

• Create concepts for that scheme, based on the two CEDS vocabularies identified above. If needed, the skos:definition would be identical to the label unless otherwise identified:

  URI: financialAid:PellGrant Label: Pell Grant Exact Match: https://ceds.ed.gov/element/000113/#PellGrants Broader: financialAid:General

URI: financialAid:OtherFederalGrant Label: Other Federal Grant Exact Match: https://ceds.ed.gov/element/000113/#OtherFederalGrants Broader: financialAid:General

URI: financialAid:StateLocalGrant Label: State or Local Grant Exact Match: https://ceds.ed.gov/element/000113/#StateAndLocalGrants Broader: financialAid:General

URI: financialAid:InstitutionalGrant Label: Institutional Grant Exact Match: https://ceds.ed.gov/element/000113/#InstitutionalGrants Broader: financialAid:General

URI: financialAid:PrivateGrant Label: Private Grant Exact Match: https://ceds.ed.gov/element/000113/#PrivateGrants Broader: financialAid:General

URI: financialAid:OtherGrant Label: Other Grant Exact Match: https://ceds.ed.gov/element/000113/#OtherGrants Broader: financialAid:General

URI: financialAid:Assistantship Label: Assistantship Exact Match: https://ceds.ed.gov/element/000113/#Assistantships Broader: financialAid:General

URI: financialAid:FederalScholarship Label: Federal Scholarship Exact Match: https://ceds.ed.gov/element/000113/#FederalScholarships Broader: financialAid:General

URI: financialAid:StateLocalScholarship Label: State or Local Scholarship Exact Match: https://ceds.ed.gov/element/000113/#StateAndLocalScholarships Broader: financialAid:General

URI: financialAid:InstitutionalScholarship Label: Institutional Scholarship Exact Match: https://ceds.ed.gov/element/000113/#InstitutionalScholarships Broader: financialAid:General

URI: financialAid:PrivateScholarship Label: Private Scholarship Exact Match: https://ceds.ed.gov/element/000113/#PrivateScholarships Broader: financialAid:General

URI: financialAid:OtherScholarship Label: Other Scholarship Exact Match: https://ceds.ed.gov/element/000113/#OtherScholarships Broader: financialAid:General

URI: financialAid:FederalSubsidizedLoan Label: Federal Subsidized Loan Exact Match: https://ceds.ed.gov/element/000113/#FederalSubsidizedLoans Broader: financialAid:General

URI: financialAid:FederalUnsubsidizedLoan Label: Federal Unsubsidized Loan Exact Match: https://ceds.ed.gov/element/000113/#FederalUnsubsidizedLoans Broader: financialAid:General

URI: financialAid:PrivateLoan Label: Private Loan Exact Match: https://ceds.ed.gov/element/000113/#PrivateLoans Broader: financialAid:General

URI: financialAid:StateLoan Label: State Loan Exact Match: https://ceds.ed.gov/element/000113/#StateLoans Broader: financialAid:General

URI: financialAid:Institutional Label: Institutional Loan Exact Match: https://ceds.ed.gov/element/000113/#InstitutionalLoans Broader: financialAid:General

URI: financialAid:ParentPLUSLoan Label: Parent PLUS Loan Exact Match: https://ceds.ed.gov/element/000113/#ParentPLUSLoans Broader: financialAid:General

URI: financialAid:OtherLoan Label: Other Loan Exact Match: https://ceds.ed.gov/element/000113/#OtherLoans Broader: financialAid:General

URI: financialAid:StateWork Label: State Work Exact Match: https://ceds.ed.gov/element/000113/#StateWork Broader: financialAid:General

URI: financialAid:FederalWorkStudy Label: Federal Work Study Exact Match: https://ceds.ed.gov/element/000113/#FederalWorkStudy Broader: financialAid:General

URI: financialAid:OtherOnCampusWork Label: Other On-Campus Work Exact Match: https://ceds.ed.gov/element/000113/#OtherOnCampusWork Broader: financialAid:General

URI: financialAid:Post911GIBill Label: Post 9-11 GI Bill Exact Match: https://ceds.ed.gov/element/001610/#Post911GIBill Broader: financialAid:Veteran

URI: financialAid:DoDTuitionAssistance Label: Department of Defense Tuition Assistance Exact Match: https://ceds.ed.gov/element/001610/#DODTuitionAssistance Broader: financialAid:Veteran

Terms that fall under the Illinois concept are to be determined.

It may also be worth creating the Illinois top-level term as part of a profile of CTDL specific to its use case rather than as part of core CTDL.

[siuc-nate]

In our lengthy discussion, I think we missed needing to create a property on FinancialAssistanceProfile to reference the vocabulary above.

Something like this may make sense:

URI: ceterms:financialAssistanceType Label: Financial Assistance Type Definition: Type of financial assistance; select from an existing enumeration of such types. Domain: ceterms:FinancialAssistanceProfile Range: ceterms:CredentialAlignmentObject

[stuartasutton]

Yes, we missed that. Definition looks good.

[cwd-mparsons]

From Nate I suggest we move forward without the Illinois category for now. We can either add it later (when we have some things to put into it) or add it as a CTDL profile that is state-specific rather than to CTDL proper. Either way, that will likely require more time/discussion than the main set of CEDS-based terms.

[siuc-nate]

Thanks, Mike - I removed that comment from the other issue.

[siuc-nate]

Per our 10-8-2019 meeting: Changes:

• Create a property to point to the concepts:

  URI: ceterms:financialAssistanceType Label: Financial Assistance Type Definition: Type of financial assistance; select from an existing enumeration of such types. Domain: ceterms:FinancialAssistanceProfile Range: ceterms:CredentialAlignmentObject

• Create a concept scheme:

  URI: ceterms:FinancialAssistance Label: Financial Assistance Definition: Types of financial assistance.

• Create top-level concepts:

  URI: financialAid:General Label: General Financial Assistance Definition: Generally-available financial assistance. Equivalent To: https://ceds.ed.gov/element/000113

URI: financialAid:Veteran Label: Veteran Financial Assistance Definition: Financial assistance available to veterans. Equivalent To: https://ceds.ed.gov/element/001610

• Create concepts for that scheme, based on the two CEDS vocabularies identified above. If needed, the skos:definition would be identical to the label unless otherwise identified:

  URI: financialAid:PellGrant Label: Pell Grant Equivalent To: https://ceds.ed.gov/element/000113#PellGrants Broader: financialAid:General

URI: financialAid:OtherFederalGrant Label: Other Federal Grant Equivalent To: https://ceds.ed.gov/element/000113#OtherFederalGrants Broader: financialAid:General

URI: financialAid:StateLocalGrant Label: State or Local Grant Equivalent To: https://ceds.ed.gov/element/000113#StateAndLocalGrants Broader: financialAid:General

URI: financialAid:InstitutionalGrant Label: Institutional Grant Equivalent To: https://ceds.ed.gov/element/000113#InstitutionalGrants Broader: financialAid:General

URI: financialAid:PrivateGrant Label: Private Grant Equivalent To: https://ceds.ed.gov/element/000113#PrivateGrants Broader: financialAid:General

URI: financialAid:OtherGrant Label: Other Grant Equivalent To: https://ceds.ed.gov/element/000113#OtherGrants Broader: financialAid:General

URI: financialAid:Assistantship Label: Assistantship Equivalent To: https://ceds.ed.gov/element/000113#Assistantships Broader: financialAid:General

URI: financialAid:FederalScholarship Label: Federal Scholarship Equivalent To: https://ceds.ed.gov/element/000113#FederalScholarships Broader: financialAid:General

URI: financialAid:StateLocalScholarship Label: State or Local Scholarship Equivalent To: https://ceds.ed.gov/element/000113#StateAndLocalScholarships Broader: financialAid:General

URI: financialAid:InstitutionalScholarship Label: Institutional Scholarship Equivalent To: https://ceds.ed.gov/element/000113#InstitutionalScholarships Broader: financialAid:General

URI: financialAid:PrivateScholarship Label: Private Scholarship Equivalent To: https://ceds.ed.gov/element/000113#PrivateScholarships Broader: financialAid:General

URI: financialAid:OtherScholarship Label: Other Scholarship Equivalent To: https://ceds.ed.gov/element/000113#OtherScholarships Broader: financialAid:General

URI: financialAid:FederalSubsidizedLoan Label: Federal Subsidized Loan Equivalent To: https://ceds.ed.gov/element/000113#FederalSubsidizedLoans Broader: financialAid:General

URI: financialAid:FederalUnsubsidizedLoan Label: Federal Unsubsidized Loan Equivalent To: https://ceds.ed.gov/element/000113#FederalUnsubsidizedLoans Broader: financialAid:General

URI: financialAid:PrivateLoan Label: Private Loan Equivalent To: https://ceds.ed.gov/element/000113#PrivateLoans Broader: financialAid:General

URI: financialAid:StateLoan Label: State Loan Equivalent To: https://ceds.ed.gov/element/000113#StateLoans Broader: financialAid:General

URI: financialAid:InstitutionalLoan Label: Institutional Loan Equivalent To: https://ceds.ed.gov/element/000113#InstitutionalLoans Broader: financialAid:General

URI: financialAid:ParentPLUSLoan Label: Parent PLUS Loan Equivalent To: https://ceds.ed.gov/element/000113#ParentPLUSLoans Broader: financialAid:General

URI: financialAid:OtherLoan Label: Other Loan Equivalent To: https://ceds.ed.gov/element/000113#OtherLoans Broader: financialAid:General

URI: financialAid:StateWork Label: State Work Equivalent To: https://ceds.ed.gov/element/000113#StateWork Broader: financialAid:General

URI: financialAid:FederalWorkStudy Label: Federal Work Study Equivalent To: https://ceds.ed.gov/element/000113#FederalWorkStudy Broader: financialAid:General

URI: financialAid:OtherOnCampusWork Label: Other On-Campus Work Equivalent To: https://ceds.ed.gov/element/000113#OtherOnCampusWork Broader: financialAid:General

URI: financialAid:Post911GIBill Label: Post 9-11 GI Bill Equivalent To: https://ceds.ed.gov/element/001610#Post911GIBill Broader: financialAid:Veteran

URI: financialAid:DoDTuitionAssistance Label: Department of Defense Tuition Assistance Equivalent To: https://ceds.ed.gov/element/001610#DODTuitionAssistance Broader: financialAid:Veteran

[siuc-nate]

These changes have been made in pending CTDL and noted in the history tracking.