Add new demandLevel property to ceterms

[stuartasutton]

In order to make a more direct assertion of employment level demand, we need to add a ceterms:demandLevel property to reference the ceterms:AggregateDataProfileinstead of the originally proposedceterms:aggregateData.

ADD:

URI: https://purl.org/ctdl/terms/demandLevel Definition: Level of workforce demand for the resource. Domain: https://purl.org/ctdlasn/terms/Competency, https://purl.org/ctdlasn/terms/Occupation Range: https://purl.org/ctdl/terms/AggregateDataProfile

and...

URI: https://purl.org/ctdl/terms/demandLevelType Definition: Type of the level of workforce demand for the resource; select from an existing enumeration of such types. Comment Examples include O*Net's "Bright Outlook", "Rapid Growth", "Numerous Job Openings" Domain: https://purl.org/ctdl/terms/AggregateDataProfile Range: https://purl.org/ctdl/terms/CredentialAlignmentObject (skos:Concept)

I have already updated the domain model (upper left), terms document and spreadsheet as well as the presentation.

[siuc-nate]

What if you want to point to something more than just demand level from the competency? The rest of Aggregate Data is there to facilitate pointing not just to demand level, but to other things, hence me suggesting the use of aggregateData as the property (since that covers all use cases) instead of making a new property that only covers one.

We want to avoid a situation like we had with having separate properties for holders, employmentOutcomes, and earnings.

[stuartasutton]

@siuc-nate if you want to have a single property that points to "something more", then use aggregateData.

[siuc-nate]

Yes. Demand level is part of the aggregate data, so while we do need demandLevelType to be a part of AggregateDataProfile, I don't think it makes sense to create a new property (demandLevel) that is redundant with the already existing property aggregateData which already covers the notion of demandLevel.

Again, it's the same situation we had with holders, employmentOutcome, and earnings. We merged those together to make the LMI data much easier to publish and consume. I don't think we want to create a fourth property on that list, especially for an edge case that hasn't been proven to have much (no pun intended) demand yet.

[stuartasutton]

Nate, you see demand level all over the place,--so there is demand. I don't think that the MEANING of aggregateData and demandLevel are the same. A demandLevel property might be considered a kind-of aggregateData (i.e., any bloody data that is aggregated), but the level of precision is quite, quite different. I am telling you that this is one place where that precision is valuable.

[siuc-nate]

I understand that it's more precise, but that also cuts off the functionality of being able to do the other things Aggregate Data Profile allows for. For example, you wouldn't be able to provide the jobsObtained data for a Competency, because Competency -[demandLevel] -> Aggregate Data Profile -[jobsObtained] -> 100 doesn't make sense the way Competency -[aggregateData] -> Aggregate Data Profile -[jobsObtained] -> 100 does, whereas Competency -[aggregateData] -> Aggregate Data Profile -[demandLevelType] -> Bright Outlook makes just as much sense as Competency -[demandLevel] -> Aggregate Data Profile -[demandLevelType] -> Bright Outlook and I don't see what you really gain with the extra precision of a demandLevel property relative to the loss of flexibility you incur by not using aggregateData.

In other words, adding a redundant property just seems like doing more to achieve less than using the property we already have.

But I suppose we're going in circles at this point. Should we put this in front of the task group and have them chime in?

If not, then I guess we can go ahead and add the property and let the data prove it out one way or the other.

I just really want to avoid having to come back later and add aggregateData to Competency in addition to demandLevel because then we're right back in the holders/employmentOutcome/earnings boat again (with the added twist that there will be two ways to publish/query for demandLevelType) and we already figured out that that was too cumbersome.

[stuartasutton]

Nate, this is linked data and there are two mechanisms for making the data useful. One is search and the other is navigation (browse). Work here in Credential Engine has been largely focused on the first (search) while people pushing the boundaries are trying to solve graph navigation. Search requires processing over the data to arrive at, and present, something meaningful and the other involves someone traversing the graph through a process of "recognition".

In search of a graph by a machine, the machine does the traversing of the path and presents a canned view of the "result". (see our Finder). Navigation or browsing a graph by humans depends on "recognition" and it's here where precision in meaning makes a difference by providing "recognition" (as much as possible) at each decision point in the (browse) journey. So, navigation means getting "precision" (recognition) as close to the person at each point along the journey's path.

Nate, compare the following and you tell me which is better for a person on a navigational journey requiring "recognition" of what is on the other end of each link:

Competency==aggregateData==>AggregateDataProfile==demandLevelType==>Concept

or

Competency==demandLevel==>AggregateDataProfile==demandLevelType==>Concept

[siuc-nate]

To me, the first option makes sense, because the schema tells me I can find demandLevelType inside of Aggregate Data Profile (and that Aggregate Data Profile provides the contextualizing info like jurisdiction and dates).

If I didn't know the schema (but could still read the definitions for the properties - this is RDF after all), the second one is more immediately intuitive. However, in the absence of such a property, the definition for aggregateData is "Statistical information about the resource." and isn't a big leap at all (in my opinion) to assume that I might find LMI data like demand level type on the other end of "Statistical information about the resource", so that would be where I'd look.

If for some reason we're going purely on the property URIs, then yes, I may have to click around a bit before trying aggregateData (and once I conquered that learning curve, I'd hopefully remember it for the future), but now we're getting really subjective.

[stuartasutton]

OK, let's shift gears. This data aggregation mode has made me more than uncomfortable from the start.

In a significant way, stating that "this competency or occupation is in demand" is like California saying "this program is awarded 'Gold' in the 2018 Strong Workforce Stars initiative". So let's treat this as our analysis of the California Strong Workforce Stars initiative indicated as a form of "action" taken on a competency or occupation that may be time delimited and have a geographic constraint.

NEW SUBCLASS OF CREDENTIALING ACTION:

URI: https://purl.org/ctdl/terms/WorkforceDemandAction Label: Workforce Demand Action Description: Action taken by an agent asserting that the resource being described has a workforce demand level worthy of note. Subclass Of: https://purl.org/ctdl/terms/CredentialingAction

NEW PROPERTY:

URI: https://purl.org/ctdl/terms/inDemandAction Label: In DemandAction Description: Assertion by an agent that this resource has a specific workforce demand level. Domain: ceterms:Occupation, ceasn:Competency Range: ceterms:WorkforceDemandAction Subproperty Of: ceterms:relatedAction (Revised definition: "Action related to the resource.")

IN RANGE OF:

ceterms:actingAgent ceterms:actionStatusType determs:description ceterm:endDate ceterm:evidenceOfAction inDemandAction ceterm:instrument ceterm:jurisdiction ceterm:object ceterm:participant ceterm:startDate

Here's a partial diagram:

[siuc-nate]

I'm definitely a fan of not having the competency point out at something, and instead having something else point in to the Competency, but is that something we can allow, given the constraints of the OSMT stuff? If so, we should probably make a bunch of changes to other areas where we were thinking of having the competency point outwards.

That said, this seems like overkill for just demand level. Would we have to make all this new stuff every time some new minor attribute of a competency comes up? That's what worries me.

[stuartasutton]

Nate, this property as well as many of the others in the Contextualization work does NOT impact OSMT because what our extensions do is cover there stuff (the "substantiating" properties) and other things. This is one of those other things.

No, it is not overkill. Indicating demand level is one of the factors that would be important for learners as to whether what they are pursuing is in decline, going up, immediately hot. You are dead wrong that this is just some tangential thing and somehow leads to a slippery slope.

[stuartasutton]

After today's (2021-08-31) discussion, the model is slightly modified and looks like this:

The fuller domain model is here: https://drive.google.com/file/d/1wZGKIrdtmadbZW5hXvrpi95BBp-8auJq/view?usp=sharing

NEW SUBCLASS OF CREDENTIALING ACTION:

URI: https://purl.org/ctdl/terms/WorkforceDemandAction Label: Workforce Demand Action Description: Action taken by an agent asserting that the resource being described has a workforce demand level worthy of note. Subclass Of: https://purl.org/ctdl/terms/CredentialingAction

NEW PROPERTY:

URI: https://purl.org/ctdl/terms/inDemandAction Label: In DemandAction Description: Assertion by an agent that this resource has a specific workforce demand level. Domain: ceterms:Organization Range: ceterms:WorkforceDemandAction Subproperty Of: ceterms:relatedAction (Revised (generalize definition: "Action related to the resource.")

URI: https://purl.org/ctdl/terms/hasWorkforceDemand Label: Has Workforce Demand Description: Demand level resource referenced by the object of the demand level action. Domain: ceasn:Competency, ceterms:Occupation Range: ceterms:WorkforceDemandAction

URI: https://purl.org/ctdl/terms/result Label: Action Result Description: Outcome produced in the action. Domain: ceterms:WorkforceDemandAction Range: ceterms:CredentialAlignmentObject (skos:Concept)

IN RANGE OF:

ceterms:actingAgent ceterms:actionStatusType determs:description ceterm:endDate ceterm:evidenceOfAction ceterms:hasWorkforceDemand ceterms:inDemandAction ceterm:instrument ceterm:jurisdiction ceterm:object ceterm:participant ceterms:result ceterm:startDate

[siuc-nate]

JSON-LD example: https://github.com/CredentialEngine/Schema-Development/blob/master/Contextualized-Competency-Statements/CSCTG%20-%20Aspiration%20Example%20(WorkforceDemandAction).json

[stuartasutton]

@siuc-nate, just two adjustment:

1. The ceterms:WorkforceDemandAction has no ceterms:actingAgent property identifying the Agent; and
2. The the competencies don't use the ceterms:demandLevel property to reference the ceterms:WorkforceDemandAction.

[siuc-nate]

Updated.

We should probably use a different name, like workforceDemand or hasDemand or something like that, since demandLevel doesn't reference a concept in a concept scheme like all of the other ___Level properties in CTDL/CTDL-ASN do.

[stuartasutton]

It was changed in the domain model to hasWorkforceDemand as well as in the graphic above. Note also that these are ceterms properties and not ceasn.

[siuc-nate]

Did we decide whether or not we're removing the reference to schema:Action from ceterms:CredentialingAction? I recall that it came up in @philbarker's points.

[siuc-nate]

The proposed definition for hasWorkforceDemand is "Demand level resource referenced by the object of the demand level action."

Is that still correct? I'm trying to parse what it means and I think I understand it. But, would "Description of workforce demand for this resource, according to the resource being referenced." be clearer? Or maybe just "Description of workforce demand for this resource."?

[philbarker]

I think we did decide to remove it.

[philbarker]

@siuc-nate references to "this resource" make some sense when you're talking about instance data but I think they are out of place when defining the schema. We're defining a property (which is an rdf:Resource): what is "this resource"? I also dislike defining properties with a definition of their range.

That said I struggle to parse the current definition too. How about:

"Indicates the level of demand for a resource via a demand level action."

[siuc-nate]

We use "this resource" in something like 20+ definitions already - it is understood to mean "the resource being described" (which is another phrase we use in a handful of places), not the property itself.

Since WorkforceDemandAction doesn't explicitly cover "level" anymore (as we're using "result") and also covers jurisdiction and date, I don't think we want to constrain the property to just "level", hence my use of "workforce demand" above. So, perhaps:

"Indicates the workforce demand for the resource being described."?

[philbarker]

We use "this resource" in something like 20+ definitions already - it is understood to mean "the resource being described" (which is another phrase we use in a handful of places), not the property itself.

That's no reason not to do better in the future.

Anyway:

"Indicates the workforce demand for the resource being described."?

why do you have to say "for the resource being described"? That's how RDF works, it's what metadata does -- what else is it going to be for?

"Indicates the workforce demand" is sufficient.

I like the "via a demand level action." bit because it gives a sense of what to expect / how to indicate it -- a bit like the "select from an enumeration" formula we use.

[siuc-nate]

That's no reason not to do better in the future.

Personally, I think it's confusing to have a property's description refer to the property itself when you're trying to describe what the property does for the object that it is a property of. Maybe that's just my object-oriented background coming out, but, that is also the kind of background a lot of the developers who will be using CTDL will have, so there is something to be said for writing definitions that make sense to someone with an object oriented mindset.

why do you have to say "for the resource being described"? That's how RDF works, it's what metadata does -- what else is it going to be for?

That is one of the predictable patterns of how our schema's definitions are written that aids in intuitive understanding of what a new property does/is for, when you are already familiar with existing properties.

"Indicates the workforce demand" is sufficient.

I guess (though I would use "Indicates workforce demand" if we're trying to keep it short), but we should probably get some input from @stuartasutton at this point, as he created the property in the first place.

I like the "via a demand level action." bit because it gives a sense of what to expect / how to indicate it -- a bit like the "select from an enumeration" formula we use.

That is directly provided by the property's range, though - unlike the vocabulary properties which have a CredentialAlignmentObject in the middle. And it would be more correct to use "Workforce Demand Action" instead of "demand level action".

[stuartasutton]

As for removing the reference to schema:action. The answer is "yes", remove it.

[stuartasutton]

Use "Indicates the level of demand for a resource via a demand level action."

[siuc-nate]

What is a "demand level action"? That isn't the class we created.

[stuartasutton]

@siuc-nate there are no capital letters...was NOT directly referencing the WorkforceDemandAction class but the nature of the action.

[siuc-nate]

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