Enhancements for describing transfer value from an occupation at a given level

[siuc-nate]

Per our 1/31/2023 meeting: Determine, based on examples, which of these two approaches makes more sense:

Alternative 1:

• Add ceterms:Occupation and ceterms:Job to the domain of asn:hasProgressionLevel
• Add asn:ProgressionLevel to the range of ceterms:transferValueFrom and ceterms:transferVaueFor

Alternative 2:

• Add ceterms:Occupation to the domain of asn:hasProgressionModel
• Add ceterms:Job to the domain of asn:hasProgressionLevel

Example modeling for discussion: https://app.diagrams.net/#G12o0N0jLy0uVqZk3Ad88ALwM-ebp3Jv6q

[siuc-nate]

There are parallels here to the problem of how best to embody the data when, say, a learning opportunity points to all of the competencies in a framework - does it make sense to just reference the framework directly somehow, or to point to each of the competencies individually?

[jeannekitchens]

@siuc-nate this came from working with Kansas on military transfer values where the TV is based on the occupation and the level in the occupation. Why do we need to look at the solutions as alternatives? Occupations and jobs, can definitely have levels. A transfer value can be explicit to define an occupation transfer with or without a level? Let's get this one figured out.

[siuc-nate]

The first alternative allows the Transfer Value Profile to point to the level independently of the Occupation/Job. The second alternative enables the Occupation to provide a list of levels and the Job to be at a particular level, so that the Transfer Value Profile just needs to point to the Job (which then points to the level).

Looking at it now, the TVP aspect might already be handled by just indicating the level in the TVP's ValueProfile (e.g. even if an Occupation has 3 levels, the credit provided is only at some specific level). This can be done today.

However, Occupation/Job themselves do not have a way to point at a level, so we probably still need to figure out whether this should be done via audienceLevelType (possibly with a user-published custom concept scheme where needed) or if this needs to be done via asn:hasProgressionLevel/Model.

[philbarker]

While it seems more logical that an Occupation (e.g. Soldier) has a progression level and Jobs within that occupation are at some specific level. However, I suspect that we will often not have data at the Job level. So it is more practical to add both to the domain of asn:hasProgressionLevel, so we could talk about someone having an occupation or a job at a certain level. That also makes sense: you might sensibly say your occupation is a "senior software developer" without giving specifics on your current job. So I would

• Add ceterms:Occupation to the domain of asn:hasProgressionModel
• Add ceterms:Occupation and ceterms:Job to the domain of asn:hasProgressionLevel

The thing that makes me really uneasy is the point.

• Add asn:ProgressionLevel to the range of ceterms:transferValueFrom and ceterms:transferVaueFor

ProgressionLevels are essentially concepts like "Trainee", "Junior", "Senior". They are not occupations. It doesn't make much sense to say that a level on its own has a transfer value.

What we should do is create different Occupations or Jobs at each of those levels and assign the transfer value to them. But the details are difficult (such as are there additional requirements, such as time in post at a certain level), so some examples would be good.

[siuc-nate]

Having thought on this some more, I think we want to avoid creating a bunch of duplicate Occupation instances where the only difference is the level. That makes sense for the transfer value use case, but gets really messy everywhere else.

It doesn't make much sense to say that a level on its own has a transfer value.

Agreed, but that can be handled by guidance/best practices. The comment for ceterms:transferValueFrom states:

"When this property references multiple resources, those resources should be treated as a set from which, collectively, the transfer value originates."

So I don't think it's too outlandish to have transferValueFrom point to both the occupation and a particular level (be it a progression level, audience level concept, whatever).

When used properly, I think the meaning is clear:

[jeannekitchens]

@siuc-nate this makes really good sense to me. What is the terms proposal to support this modeling?

[philbarker]

I think that is stretching any intuitive meaning of "Audience" way beyond its limit. It also seems no better than pointing to progression level from TransferValueProfile because the Audience Level Type is just a "type of level indicating a point in a progression through an educational or training context, for which the credential is intended" pretty similar to progressionLevel ("Identifiable point along a developmental progression of competence, achievement or temporal position.").

[siuc-nate]

Equivalents with ProgressionLevel/Model:

The above suggestions would also work (though maybe not make much sense?) even if the Occupation doesn't reference any levels at all. This might be useful if the Occupation comes from a totally different source than the Transfer Value Profile where the former doesn't have/publish as much data/detail.

[philbarker]

I prefer that. I still have reservations about the value coming from a Level. How about a "requiredLevel" property for that arrow from TransferValueProfile to Level II?

FWIW, I think the correct approach is to create Occupations or Jobs at every level that needs to be referenced, numerous though they might be. If we don't want to instantiate them as first class objects, I think we could use an approach similar to that we discussed for when we needed to reference a "generic" degree in a science subject from an organization: rather than listing all possible science degrees, we create a bnode containing the required attributes of the degree -- or did I dream that?

[siuc-nate]

We did discuss (back when Transfer Value was being devised) using a bnode for things like learning opportunities/assessments (using sameAs to point to the actually-published version where applicable) as a way for the publisher of the Transfer Value Profile data to make assertions about the learning opportunity even though they are not the owner of that data. An analogous approach to that might be viable here:

Occupation already has the sameAs property, so this would just require figuring out the audienceLevel/progressionLevel/Model/etc. stuff. This would also work in cases where there is no published Occupation to point to.

I think this is the right track.

[philbarker]

Hmm. Not sure that works. SameAs is "Another source of information about the entity being described" and the two Occupations are not really the same entity--one is a "subOccupation" of the other. I think ceterms:isSpecializationOf is a better term to use, if you accept the levels as being specializations. Is "Senior software developer" a specialization of "Software developer"? Could be...

[siuc-nate]

Well, the bnode is an instance of the Occupation class, so it could use whichever property is appropriate to point to the "real" published data.

[jeannekitchens]

We need to discuss this based on a real-world use case. Here's the U.S. Military transfer values based on the level of the occupation. Each branch has occupations and levels. https://military.kansasregents.org/ - search by different branches of the service and service levels. The transfer value is determined by the combination of the occupation + that occupation's level.

[philbarker]

Looking at Jeanne's screen shot, in this case the bnode could be a job and the link would be hasOccupation, so we should cover t\hat as well.