New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is there a financial assistance vocabulary #466

Closed
stuartasutton opened this Issue Sep 27, 2017 · 33 comments

Comments

@stuartasutton
Contributor

stuartasutton commented Sep 27, 2017

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

This comment has been minimized.

siuc-nate commented Sep 27, 2017

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

This comment has been minimized.

Contributor

stuartasutton commented Sep 27, 2017

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

This comment has been minimized.

Contributor

stuartasutton commented Sep 27, 2017

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

This comment has been minimized.

siuc-nate commented Sep 27, 2017

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

This comment has been minimized.

Contributor

stuartasutton commented Sep 28, 2017

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

This comment has been minimized.

Contributor

stuartasutton commented Sep 28, 2017

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

This comment has been minimized.

siuc-nate commented Sep 28, 2017

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

This comment has been minimized.

Contributor

stuartasutton commented Sep 28, 2017

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

This comment has been minimized.

siuc-nate commented Sep 28, 2017

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

This comment has been minimized.

cwd-mparsons commented Sep 28, 2017

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

@stuartasutton

This comment has been minimized.

Contributor

stuartasutton commented Sep 29, 2017

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

This comment has been minimized.

Contributor

stuartasutton commented Sep 29, 2017

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

This comment has been minimized.

siuc-nate commented Sep 29, 2017

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

This comment has been minimized.

Contributor

stuartasutton commented Sep 29, 2017

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

This comment has been minimized.

siuc-nate commented Sep 29, 2017

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

This comment has been minimized.

Contributor

stuartasutton commented Sep 29, 2017

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

@siuc-nate

This comment has been minimized.

siuc-nate commented Sep 29, 2017

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

This comment has been minimized.

Contributor

stuartasutton commented Oct 4, 2017

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

This comment has been minimized.

Contributor

stuartasutton commented Oct 4, 2017

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

This comment has been minimized.

siuc-nate commented Feb 20, 2018

@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

This comment has been minimized.

Contributor

stuartasutton commented Feb 21, 2018

@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

This comment has been minimized.

siuc-nate commented Feb 21, 2018

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

This comment has been minimized.

Contributor

stuartasutton commented Feb 21, 2018

"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

This comment has been minimized.

siuc-nate commented Feb 21, 2018

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

This comment has been minimized.

Contributor

stuartasutton commented Feb 21, 2018

"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 comment has been minimized.

siuc-nate commented Feb 21, 2018

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

This comment has been minimized.

siuc-nate commented Feb 21, 2018

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

This comment has been minimized.

philbarker commented Feb 22, 2018

@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

This comment has been minimized.

Contributor

stuartasutton commented Feb 22, 2018

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

This comment has been minimized.

siuc-nate commented Feb 22, 2018

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

This comment has been minimized.

siuc-nate commented Mar 23, 2018

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

This comment has been minimized.

siuc-nate commented Apr 11, 2018

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

@siuc-nate siuc-nate closed this Apr 11, 2018

@stuartasutton

This comment has been minimized.

Contributor

stuartasutton commented Apr 15, 2018

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 #466 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment