Need property, ceterms:providesTransferValueFor and ceterms:receivesTransferValueFrom

[jeannekitchens]

Major use case:

As a credentialing organization I need to publish my course, exam, or apprenticeship and link it to the Transfer Value Profile published by a third party including the transfer value recommendations published by American Council on Education and to articulated transfer value profiles such as those published by state agencies including Kansas Board of Regents.

To be clear, the credentialing organization does not need to publish a Transfer Value Profile. They simply want to indicate that their course, exam or apprenticeship has a targetTransferValueProfile published, in this case by ACE.

Currently, ACE is currently in process of publishing over 10,000 TVPs to the Registry https://credentialfinder.org/search?searchType=transfervalue&filteritemtext=American%20Council%20on%20Education:%20Owns%203432%20Transfer%20Value%20Profiles(s)&filterparameters={%22n%22:%22organizationroles%22,%22aid%22:1314,%22rid%22:[6,7]}. They issue transfer value recommmendations for courses, exams and apprenticeships. They are NOT going to publish those courses exams and apprenticeships for their customers. They are identifying the courses, exams and apprenticeships as blank nodes/references along with their owners (as blank nodes / references).

Further, ACE is not going to initially track the CTIDS of their customers course, exams, or apprenticeships.

We need to support the ability of credentialing organizations to point directly to transfer values that are recommended or articulated for their credentials, Learning Opps, and assessments.

**Need property, ceterms: targetTransferValueProfile
Definition: Transfer Value Profile for this resource.
Domain Includes: Credential, Learning Opportunity Profile, Learning Program, Course, Job, Occupation, Competency, and Assessment Profile.
Range Includes: transferValueFrom
**

The below diagram is here. CE team and Phil have edit access https://drive.google.com/file/d/1u3SaDBpcwpmtaCWfJdiqFJb9Tg2twewS/view?usp=sharing

[siuc-nate]

A bnode is one option that uses existing schema:

There is also secondary-source publishing, which would look like this:

Note that the Secondary-Source publishing would have the benefit of allowing multiple TVPs to reference the same Course object (though at some point it would be ideal to start pointing to the real Course, which could complicate things with the secondary-source Course still floating around in the Registry).

[siuc-nate]

Something wasn't sitting right with me on this one, but I couldn't quite articulate it. So I tried modeling how this would work for a few additional scenarios beyond just the original use case and I've stumbled across a few critical problems.

First, here is what the data would look like under the current proposal - the issues occurred to me in the middle of making this, and I added them on the left side of the image:

I tried a few other potential scenarios and encountered more issues:

Basically there are three main problems that are interwoven with each other:

1. Grouping: Transfer value can come from and/or apply to sets of things, not just individual things, and without some additional object to function as a grouping mechanism, there is no way to know which things are in which sets (other than maybe some kind of agreed-upon UUID per set, but that seems like it invites its own issues)
2. Directionality: A property that generically references a Transfer Value Profile does not indicate the directionality of the transfer value - in other words, (Course) -[targetTransferValue]-> (TVP) gives no indication of whether the Course is providing or receiving the value
3. Interpretation: There is no mechanism to indicate whether the Course(s) should be interpreted as replacing the Course bnode or appending to it (ie part of the same set). Since nothing in the bnode's data indicates that it is describing the same underlying Course as any of the Customer Courses, we cannot just make an assumption here (and even if we could, it would be a risky assumption to make in other cases, particularly where a Course may appear in more than one set).

Basically, I don't think we can get away with just having a property. Even if we created two new properties (one for providing transfer value and one for receiving it), the other two main issues above would still stand. I have two potential solutions:

Solution 1: The ACE TVP needs to directly reference the Customer Course via its CTID-based URI (ie vanilla CTDL functionality - this is ultimately the best solution. I understand from Jeanne's post at the top of this thread that ACE does not intend to track this data, at least not at first, but if they plan to do so at some future date, then it is probably worth waiting for:

Solution 2: Alternatively, the Customer organization needs to publish their own TVP that mirrors the WGU TVP in the sense that it is also derived from the ACE TVP, but provides the data for the other side of the articulation. This is also vanilla CTDL functionality, but it does put more of a burden on the Customer organization:

Solution 3: We come up with some way for the Customer Course to indicate that it represents the same thing as the bnode. However, as far as I am aware, this is not valid RDF, since we can't (reliably) point to a bnode in something else's graph:

Solution 4: Instead of using a Course bnode, ACE would publish the Course as a secondary-source record that could then effectively allow for solution Three (minus the bnode problem, but with the added overhead of maintaining a secondary-source Course CTID - though this does allow them to reuse the Course among multiple TVPs instead of duplicating it):

It's worth noting that solutions 2, 3, and 4 do also incur extra overhead on the consuming side, since we would need to walk more connections in order to pull the whole graph together on the detail page. Also I don't think we've done much implementation-wise with secondary-source records yet, so there may be additional pitfalls we have not yet encountered with solution 4.

I strongly recommend revisiting solution 1 to determine when it might be doable.

I am open to other ideas, provided they solve all 3 of the main problems listed above.

Edit: Actually, solution 4 may be a bit questionable, as secondary source records are intended to point out to the primary source record when available, not so much the other way around. I guess nothing specifically prevents it, but it would somewhat diverge from the intended functionality if memory serves.

[philbarker]

Looking at the issues in your diagram

Issue 1: My understanding (or assumption if you prefer) was that targetTransferValue would be the inverse of transferValueFrom, so the course would have the transfer value indicated.

Issue 2: There is nothing in the data to say that the two courses (the bnode in the ACE-published data and the identified course in the customer published data) are the same, so it cannot replace it.

Issue 3: As shown, Course A and Course B both have the target value independently, not as a set. BTW, that's true in solution 1 as well.

Referring to your three problems
1 & 3, Statements have only one subject, so a transfer value comes from only one thing. We do have cases where that one thing may have hasPart or similar relationships to other things. I don't think I see the problem.
2. can we agree targetTransferValue is the inverse of transferValueFrom?

I agree about solution being the best solution: writing the triples in full it looks like

# 1
<ACE TVP> :transferValueFrom  <Customer Course A> .
<ACE TVP> :transferValueFrom  <Customer Course B> .

RDF inferencing means that this is exactly the same as:

# 2
<Customer Course A> :targetTransferValue   <ACE TVP> .
<Customer Course B> :targetTransferValue  <ACE TVP> .
:targetTransferValue owl:inverseOf :transferValueFrom .

Given ACE are not in a position to look up all the URIs for all the courses, the normal open world solution would be for the Customer to make the statements # 1, if registry policy or tooling doesn't allow that then # 2 will provide the same data.

BTW, on proposed solution 3: you can't point to a blank node in another graph.

[siuc-nate]

Issue 1: My understanding (or assumption if you prefer) was that targetTransferValue would be the inverse of transferValueFrom, so the course would have the transfer value indicated.

can we agree targetTransferValue is the inverse of transferValueFrom?

That wasn't my impression and it isn't indicated in the definition anywhere. That definition could apply to either side of things. The "target" properties are all fairly generic in their inherent meaning and are usually contextualized by some other part of the data. Also what would the inverse be, then, of transferValueFor?

Issue 2: There is nothing in the data to say that the two courses (the bnode in the ACE-published data and the identified course in the customer published data) are the same, so it cannot replace it.

Then your data has at least two objects describing the same Course as the sources of transfer value, which means they'd be taken as a set, which would be interpreted as saying that someone has to take two unusually similar courses in order to receive transfer value.

Issue 3: As shown, Course A and Course B both have the target value independently, not as a set.

That's one interpretation, but then how would you express it if you wanted them to be considered a set?

BTW, that's true in solution 1 as well.

1 & 3, Statements have only one subject, so a transfer value comes from only one thing. We do have cases where that one thing may have hasPart or similar relationships to other things. I don't think I see the problem.

The transferValueFrom and transferValueFor properties explicitly say that when they reference multiple resources, those resources are to be treated a set for/from which transfer value applies/originates. The TVP itself is the "grouping mechanism" in such a case. This was a deliberate part of its design in order to enable transfer value to come from or apply to sets of things.

[jeannekitchens]

There is no need for ACE or any other credit recommender or credit articulator to have their customers also publish a Transfer Value Profile. We'll rule that out. It's not feasible as the role of ACE, as a recommender, and e.g., the role of a state agency such as Kansas, as an articulators (meaning they have a role in putting the articulation agreements in place and publishing the outcomes i.e., transfer value profiles. The organization that offers, for example, the course with credit recommendations has no role in republishing the transfer value determined by ACE standards.

The role of the customer is to publish their courses and link to those credit recommendations or articulations.

A recommender or articulator are not going to randomly lump TV profiles together. ACE versions their recommendations. If there's scenarios where more than 1 TV is inlcuded with a TVP, they would have logical relationship. E.g., a TV at a lower division level recommendation and a TV at an upper value recommendation for the same course.

[siuc-nate]

There is no need for ACE or any other credit recommender or credit articulator to have their customers also publish a Transfer Value Profile.

If the TVP does not point to the Course, then another TVP needs to be created which does. Otherwise you run into the issues I described in this post.

We'll rule that out.

I am open to solutions which solve the "three main problems" I outlined in this post.

The role of the customer is to publish their courses and link to those credit recommendations or articulations.

I agree the role of the customer is to publish their courses. However, I believe it is the role of the TVP author to point to the courses that the TVP needs to point to. But if the customer is to reference transfer value instead of the other way around, then it has to be done in a way which solves the three main problems I outlined.

A recommender or articulator are not going to randomly lump TV profiles together. ACE versions their recommendations. If there's scenarios where more than 1 TV is inlcuded with a TVP, they would have logical relationship. E.g., a TV at a lower division level recommendation and a TV at an upper value recommendation for the same course.

I'm not sure what this is in reference to. I wasn't suggesting that TVPs would be grouped, I said that TVPs would be the grouping mechanism (ie one TVP points to 3 courses to say "the credit comes, collectively, from these 3 courses together")

[philbarker]

There is no need for ACE or any other credit recommender or credit articulator to have their customers also publish a Transfer Value Profile. We'll rule that out.

If this is a response to my post then it is based on a misunderstanding. I did not say that any customer would publish a Transfer Value Profile. I said they would publish a statement that had the identifier for an existing TVP as its subject.

[philbarker]

Issue 2: There is nothing in the data to say that the two courses (the bnode in the ACE-published data and the identified course in the customer published data) are the same, so it cannot replace it.

Then your data has at least two objects describing the same Course as the sources of transfer value, which means they'd be taken as a set, which would be interpreted as saying that someone has to take two unusually similar courses in order to receive transfer value.

There is no set, just information about two things that may or may not be the same.

Issue 3: As shown, Course A and Course B both have the target value independently, not as a set.

That's one interpretation, but then how would you express it if you wanted them to be considered a set?

If you wanted them to be part of a set you would have to group them, either through a CTDL grouping, something with parts/members, probably a single LearningOpportunity with the two courses as parts; or you could use a native RDF grouping mechanism, one of the rdfs:containers.

We don't do this, hence there is no set.

[jeannekitchens]

Final Proposal:

Create:

URI: ceterms: providesTransferValueFor
Label: Provides Transfer Value For
Definition: This resource provides transfer value for the referenced Transfer Value Profile.
Comment: Refer to the referenced Transfer Value Profile for more information. Other resources may be included for the full value.
Domain Includes: ceterms:Credential (and subclasses), ceterms:LearningOpportunityProfile (and subclasses), ceterms:Job, ceterms:Occupation, ceasn:Competency, ceterms:AssessmentProfile
Range Includes: ceterms:TransferValueProfile

Create:

URI: ceterms: receivesTransferValueFrom
Label: Receives Transfer Value From
Definition: This resource receives transfer value from the referenced Transfer Value Profile.
Comment: Refer to the referenced Transfer Value Profile for more information. Other resources may be included for the full value.
Domain Includes: ceterms:Credential (and subclasses), ceterms:LearningOpportunityProfile (and subclasses), ceterms:Job, ceterms:Occupation, ceasn:Competency, ceterms:AssessmentProfile
Range Includes: ceterms:TransferValueProfile

This needs to be closed with a comment concerning the issues created by using b nodes. Encourage publishers to publish Fors and Froms with CTIDs.

https://drive.google.com/file/d/1u3SaDBpcwpmtaCWfJdiqFJb9Tg2twewS/view?usp=sharing

[siuc-nate]

Should the comments in the above post be usage notes instead? Or perhaps "Other resources may be included for the full value" is appropriately a comment while "Refer to the referenced Transfer Value Profile for more information" should be characterized as a usage note?

Also, should they be marked as inverse properties of transferValueFrom/transferValueFor, or does the disjointed grouping mean that wouldn't be an accurate assertion?

[jeannekitchens]

I feel it's better as a comment based on the conversation we had about the reason for adding it. We had talked about them as inverse properties but they feel disjointed to me. I'm not sure what the ramification is with the CTDL if they aren't marked as inverse properties. I supposed it's harder to figure out what properties to use.

[philbarker]

Comment, I think not usage note: it seems more broad than "how to use this property" as it includes how to interpret data beyond this property.

The situation seems a bit too complicated to say that they are inverseProperties: other factors need to be considered so there could be cases where it is not true. Even if it is always true we don't lose much by not stating it.

We should document how we see these properties being used for some of the gnarly edge cases that came up in our discussion.

[siuc-nate]

Understood, we'll keep the comment as-is, then.

We should document how we see these properties being used for some of the gnarly edge cases that came up in our discussion.

Not to belabor this, but should we add a usage note that effectively says "don't use this unless you have to"?

[philbarker]

Not to belabor this, but should we add a usage note that effectively says "don't use this unless you have to"?

Let's not: opens a can of worms around when would they "have to" that we might not want to highlight. Seems like a "don't press the big red button" scenario.
Edit: what I meant by "document how we see these properties being used" was put something in the advanced examples of the handbook. We have more scope there for explanation/contextualization.

[siuc-nate]

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