Lomilar
commented
6 years ago - Should now be JSON-LD (emits a named graph).
Any opinions on an @id for the named graph?
Closed stuartasutton closed 6 years ago
Lomilar
commented
6 years ago Any opinions on an @id for the named graph?
stuartasutton
commented
6 years ago As for the question regarding @id for named graph, I'm assuming something like this:
"@context": "http://credreg.net/ctdlasn/schema/context/json",
"@id": "http://credentialengine.org/graphs/a99ff19d-51ea-40fa-b451-34d1c2d465b9",
"generatedAt": "2018-11-27",
"@graph": [
{with generatedAt added to @context (see JSON-LD 1.1); but we should pull in @siuc-nate.
siuc-nate
commented
6 years ago One note - competency framework does not have a hasChild property in CTDLASN: http://credreg.net/ctdlasn/terms/hasChild
Anyway, we have not yet determined, at a technical level, how to publish (or how to later emit) competency frameworks from the registry itself. Off the top of my head:
I say all of this because we do need to consider it. I think the most reliable approach overall will be to publish each thing separately, as we will avoid the need for special handling during publishing or retrieval.
As for the named graph, we could generate that, potentially via a custom endpoint as @stuartasutton suggests, where a graph is constructed from a given starting point (the CTID of a framework, or of a credential, or of an organization, etc.) - though the details of that are unclear (how much data should a graph include for an example like: a framework that references levels that reference vocabularies that are owned by organizations that offer credentials that require assessments that require concepts from the framework that was initially requested?).
stuartasutton
commented
6 years ago Sigh...so we are "signing" competency frameworks as well?
siuc-nate
commented
6 years ago My understanding is that the registry signs everything. I think CASS does as well, so there may be double signatures involved here - I could be wrong.
Lomilar
commented
6 years ago Objects that are owned are signed by the last party to modify them, in CASS. Additionally, signatures are required to post to the Registry. Considering the security value of signing, this is no skin off our back.
Because the CTID for each competency will differ for each (publishing/version) of a framework, all CTIDs will only be relative to that published framework anyway. Publishing them independently (and giving them separate signatures for each) is fine on our side, as is publishing them in a named graph, though the registry would have to deconstruct it to make the elements of the named graph searchable.
Lomilar
commented
6 years ago CTDL+ASN export now emits a named graph, and hasChild is no longer an item. Are there any other actionable requests here before I close this?
stuartasutton
commented
6 years ago In essence, I started the issue because I wasn't getting a complete description set (@graph) of framework and associated competencies. That's solved. The issue of whether the framework could use hasChild or only 'hasTopChild` has been resolved.
I think we can close.
I've entered part of a Board of Certified Safety Specialist (BCSP) framework into CASS under the title [Test] Certified Environmental, Safety & Health Trainer (CET). I'm a little confused by the 'download/version' for the "Credential Engine ASN" json serialization. I was expecting straight forward jsonld. The output is below (sorry, long). I'll be referencing it from a few other issues.
The encoding has captured Domain 1, Tasks 1-3 from the BCSP Exam Blueprint at https://www.bcsp.org/Portals/0/Assets/DocumentLibrary/CET_Exam_Blueprint.pdf. Thus, as the encoding in the CASS editor makes clear, the framework has 1 top concept--"Domain 1: Communication and Interpersonal Skills".