Range for ceterms:accommodationType and ceterms:supportServiceType

[siuc-nate]

@jeannekitchens @philbarker @mparsons-ce The discussion fell off here, but did we ever actually determine whether to use Credential Alignment Object (which is what went into the implementation) instead of skos:Concept directly?

It seems like it would be better to just reference the Concepts.

[philbarker]

Seems like my last comment on that was the same as I said when discussing the schema management tool the other day: can we put both Concept and CredentialAlignmentObject into rangeIncludes for CTDL and whichever works best for the registry into the registry profile.

Registry considerations aside, my preference would be Concept.

[siuc-nate]

Per our 6/27/2023 meeting: Change the ranges of those two properties from CredentialAlignmentObject to Concept.

[mparsons-ce]

@jeannekitchens @siuc-nate @philbarker How does this work for publishing/the registry?

If a URI to a concept, how to get the CTID (from a text string like: accommodation:AccessibleHousing)?

Or is the URI to credreg.net or a PURL?

Or will an actual concept class be embedded in the graph?

[siuc-nate]

I imagine it would work the same way as the targetNode property on Credential Alignment Object today, or like how other properties in CTDL-ASN that link directly to concepts work.

So:

{
  "ceterms:supportServiceType": [ "support:CareerAssessment", "support:BehavioralService", "https://credentialengineregistry.org/resources/ce-ctid-for-some-custom-concept" ]
}

instead of:

{
  "ceterms:supportServiceType": [
    { "ceterms:targetNode": "support:CareerAssessment", "ceterms:name": { "en": "Career Assessment" }, "etc": "etc" }
    { "ceterms:targetNode": "support:BehavioralService", "ceterms:name": { "en": "Behavioral Service" }, "etc": "etc" }
    { "ceterms:targetNode": "https://credentialengineregistry.org/resources/ce-ctid-for-some-custom-concept", "ceterms:name": { "en": "Some Custom Concept" }, "etc": "etc" }
  ]
}

[mparsons-ce]

We would require some guidance on how to resolve a value of support:CareerAssessment Current the CAO includes the description and URI to the framework.

[siuc-nate]

How is this currently handled for CTDL-ASN properties that point directly to concepts?

[siuc-nate]

@mparsons-ce @jeannekitchens @philbarker Is this one actually ready to implement, or is there still an issue?

[jeannekitchens]

Seems we need to set the range for this and going forward. Per Phil's above comment the range can include both but the Registy Profile can use one over the other. I think @mparsons-ce has the most information about handling the latter.

[siuc-nate]

It would be the only property like that (a mix of concept and credential alignment object) and I think that would be even worse going forward. We need to pick one or the other.

[philbarker]

If the Registry can work with Concept rather than AlignmentObject then I would be happy with just Concept in the Range.

We could have a minimum data policy for Concept that ensures whatever data is needed by the registry that currently comes from the AlignmentObject is available in the graph each time the concept is referenced, OTOH, the idea of linked data is that you resolve the URI represented by support:CareerAssessment (i.e. https://purl.org/ctdl/vocabs/support/CareerAssessment ) to get the data.

[siuc-nate]

I don't see this as being any different to how we've handled the various properties in CTDL-ASN and QData that have been direct Concept references (instead of using Credential Alignment Object) since the beginning. Am I missing something?

[siuc-nate]

Per our 2023-9-15 meeting: We will leave these as-is for now and revisit it later if needed