The "embodied" properties need to have their ranges changed

[stuartasutton]

The ceasn:skillEmbodied, ceasn:knowledgeEmbodied, ceasn:abilityEmbodied and ceasn:taskEmbodied properties have a range of xsd:anyURI. They all should have a range of ceasn:Competency since, with the possible exception of task reference KSAs which for us are competencies.

[siuc-nate]

I think we made these URIs deliberately so we could reference KSAs from other sources like EMSI and tasks from other sources like NIST.

[stuartasutton]

Yes, but the things being "embodied are KSAs etc. not just any URI and that would enclude EMSI and NIST (where you mean things like the cybersecurity stuff).

[philbarker]

1. Stuart is right, the purpose of declaring the range of a property is to say what type of thing you will get data for if you resolve it.
2. we probably shouldn't have xsd:anyURI as the range for any property as it is a datatype for literals not a class. Even if it were a class it would be the class of URIs so having it in the range means the property points to a URI and you will get a decsription of that URI.

[stuartasutton]

Hey, Phil, since the definition of rdfs:Resource basically entails all resources, it would likely serve instead of xsd:antURI. Thoughts?

[stuartasutton]

Let's not get too sidetracked with the xsd:anyURI (separate issue) but keep focused here on the distinction between an occupation as a distinct class (e.g., ceterm:Occupation) and as a concept in a classification scheme.

[philbarker]

Yes, but let's not get sidetracked here.

[siuc-nate]

@stuartasutton @philbarker is this something that needs more discussion? Otherwise it seems fairly straightforward.

[stuartasutton]

If the conclusion is to change the range on these embodied properties to ceasn:Competency, then we are done.

[siuc-nate]

Proposal:

Remove:

Subject: ceasn:skillEmbodied, ceasn:knowledgeEmbodied, ceasn:abilityEmbodied, ceasn:taskEmbodied Predicate: schema:rangeIncludes Object: xsd:anyURI

Add:

Subject: ceasn:skillEmbodied, ceasn:knowledgeEmbodied, ceasn:abilityEmbodied Predicate: schema:rangeIncludes Object: ceasn:Competency

Subject: ceasn:taskEmbodied Predicate: schema:rangeIncludes Object: ceterms:Task

@jeannekitchens This does represent a potentially breaking change for CaSS, so we will need to work with them to prepare before we actually make this change

[stuartasutton]

I think there needs to be a modification to the proposed ceterms:taskEmbodied adding ceterms:Competency since there can be competency framework descriptions with competency nodes identified as "task":

Subject: ceasn:taskEmbodied Predicate: schema:rangeIncludes Object: ceterms:Competency, ceterms:Task

[jeannekitchens]

This looks to be ready to move forward other than it was not coordinated with CaSS team. True? If so, I'll put this on the next CaSS agenda.

[siuc-nate]

Yes, we would want to avoid breaking things. There is also the matter of potentially breaking other consuming systems at this point to consider as well.

For what it's worth, xsd:anyURI can already be used to point at Competencies/Tasks (among other things), so this isn't a terribly necessary change to make - I believe the Finder, for example, already checks to see if the URI provided is a registry URI or returns JSON-LD and handles that accordingly; otherwise it just gets treated like a webpage link.

In short: While this would make the schema a little cleaner, I think we are okay leaving it alone.

[siuc-nate]

This has resurfaced again in https://github.com/CredentialEngine/CredentialRegistry/issues/701#issuecomment-2107771997

If we can ensure this doesn't break CaSS, then this should probably move forward.

@jeannekitchens @philbarker @Lomilar @mparsons-ce thoughts?

[philbarker]

Looks like they should have a rangeIncludes of ceasn:Competency