Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Range for ceterms:instructionalProgramType #903

Open
siuc-nate opened this issue Oct 5, 2023 · 1 comment
Open

Range for ceterms:instructionalProgramType #903

siuc-nate opened this issue Oct 5, 2023 · 1 comment

Comments

@siuc-nate
Copy link
Contributor

siuc-nate commented Oct 5, 2023

In CTDL and CTDL-ASN, the range for ceterms:instructionalProgramType is ceterms:CredentialAlignmentObject (which then goes on to point to a ceterms:InstructionalProgramClassification placeholder class)
In QData, the range for ceterms:instructionalProgramType is skos:Concept.

This mismatch presents issues when looking at all of the schemas as a whole.

Semi-related: #875

@philbarker
Copy link
Collaborator

So in fact the range of ceterms:instructionalProgramType includes both skos:Concept and ceterms:CredentialAlignmentObject (because in RDF you get all the data you link to, wherever it comes from).

Part of a full solution would be to declare skos:Concept in the range of any property that currently has range including ceterms:CredentialAlignmentObject and to use local profiles to select which you want in a particular context. That, I think, is functionally how you are viewing the situation when you talk about the range being one thing in CTDL/-ASN and another in QData; and yes you're right that the mismatch doesn't help when the two contexts meet.

We should settle on one or the other for our own use, but do so without breaking the namespace policy.

More widely, another part of the full solution might be using a mapping between the two, either as a data transform (aka Materialization approach) or at query time (aka Query Language approach) to either:

  • homogenize the data to one or the other, e.g. turn all skos:Concepts into AlignmentObjects (at least in an index in order not to change the data as submitted) and query them as such (or vice versa) [Materialization], or
  • automatically rewrite queries to looking for Concept-related properties when AlignmentObject-related properties are in the query and vice versa [Query Language approach].

Both are common enough solutions (OWL can support either), both have their downside in that Materialization involves querying non-authoritative data and Query Language approach can be slow at query time. Also they are implementation solutions, not CTDL issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants