CTDL-ASN Export of CASE framework can result in malformed character errors.

[Lomilar]

See: https://cass.credentialengine.org/api/ceasn/b2679040117f9e708f6f477359e505d5

[woodkri]

Publisher Name is being imported from CASE into the Publisher field here, which expects a URL. I suspect that's why the export isn't working for this framework.

[Lomilar]

So here's the situation:

ceasn:identifier is equivalentTo asn:identifier asn:identifier refines (specializes?) dc:identifier and has a controlled range of URI (based on the description, maybe not based on the intended range?) schema:identifier seems to be based on dc:identifier. I have no basis for this at the moment.

So, we import IMS CASE identifiers, assigning them to schema:identifier as a text string (permitted). schema:identifier cannot cast to ceasn:identifier, because ceasn:identifier and asn:identifier require a URI.

As such, the natural casting from schema:identifier to ceasn:identifier is inhibited by the refined requirement for a URI, and causes this error message.

@stuartasutton Is only allowing that cast from schema:identifier to ceasn:identifier if it is a URL the appropriate path forward?

[stuartasutton]

@Lomilar, schema.org/identifier has an owl:equivalentProperty to http://purl.org/dc/terms/identifier which is defined with a range of http://www.w3.org/2000/01/rdf-schema#Literal. However, schema.org has a rangeIncludes of both URL and Text. ASN simply uses the DC terms and says nothing about range while ctdl-identifier uses xsd:anyURI. But, given the schema.org range includes both URL and Text, I'm not sure of the issue unless CaSS only handles part of the schema.org ranges.

I don't have a problem with the current ctdl-asn position since it's explicitly defined as

An alternative URI by which this competency framework or competency is identified.

This is intended to differentiate the @ id of a competency node from some alternative URI; e.g., the URI assigned to a node in the Common Core State Standards by its creators would be an "alternative URI" to the @ id for that node in the ASN-US repository.

[Lomilar]

Ah, some more background may help.

In IMS CASE, identifier seems to be used in the dc sense.

https://opensalt.net/ims/case/v1p0/CFDocuments/c5fb3436-d7cb-11e8-824f-0242ac160002

{
  "uri": "https://opensalt.net/ims/case/v1p0/CFDocuments/c5fb3436-d7cb-11e8-824f-0242ac160002",
  "identifier": "c5fb3436-d7cb-11e8-824f-0242ac160002",
  "lastChangeDateTime": "2018-10-24T20:31:24+00:00",
...
}

When we convert CASE to CASS, we cast case:identifier to schema:identifier.

https://cass.credentialengine.org/api/data/b2679040117f9e708f6f477359e505d5

{
  "@context": "http://schema.cassproject.org/0.3",
  "@id": "https://opensalt.net/ims/case/v1p0/CFDocuments/c5fb3436-d7cb-11e8-824f-0242ac160002",
...
  "schema:dateModified": "2018-10-24T20:31:24+00:00",
  "schema:identifier": "c5fb3436-d7cb-11e8-824f-0242ac160002",
  "schema:inLanguage": "en",
  "schema:publisher": "Public Consulting Group"
}

When we attempt to cast schema:identifier to ceasn:identifier based on the @context, the ceasn schema requires a URL in the JSON-LD @context via this attribute:

{
  "ceasn:identifier": {
    "@type": "@id"
  },
}

This causes an error in the JSON-LD Translation Processor as a UUID isn't a URI.

We can put some manual code in that checks schema:identifier for a URI before casting it to ceasn:identifier, just wondering if there is a better way to handle this.

Probably also appropriate now to rope in @siuc-nate, as he may have context for this.

[stuartasutton]

The declaration of ceasn:identifier as follows is correct since it is defined as an ..."alternative URI":

{
  "ceasn:identifier": {
    "@type": "@id"
  },
}

The functional pattern here is that CASE identifier value is a UUID that is appended to the namespace for the CASE resource URI just as the CEASN ctid is appended to a namespace to create the CE resource URI. Obviously, we can't map the CASE identifier to the CEASN ctid, so we functionally don't have a CEASN place to map the CASE identifier any more than CASE has a a place to map the CEASN ctid. I'm not enamored with the idea of jacking the ceasn:identifier around to accommodate a CASE mapping. What are the alternatives?

[Lomilar]

• Leave it as case:identifier and not translate to schema:identifier or dc:identifier.
• OR Remove the translationability of dc:identifier to/from ceasn:identifier/asn:identifier.
• OR Disentangle the entomology of identifier across schema:, dc:, asn:, ceasn:, namespaces and determine where the definition changed and what to do.

I think those are the pathways.

[siuc-nate]

I don't see anything in the schema that would really fit a generic GUID identifier (aside from maybe ceasn:codedNotation, but that is a bit of a stretch). It seems to me that while the casting from case:identifier to schema:identifier is appropriate, the casting from schema:identifier to ceasn:identifier should only happen if the identifier is a URI (as you pointed out above).

In cases where it is not, perhaps one of these would work:

• Use ceasn:codedNotation (or altCodedNotation)
• Use ceterms:alternativeIdentifier (would it be necessary to add this to CTDL-ASN at all given that CTDL is represented in the @context file already?)
  • Note that this would also require the use of the ceterms:IdentifierValue class and its properties, ceterms:identifierType, and ceterms:identifierValueCode
• Create an arbitrary namespace to turn non-URI identifiers into URI identifiers (if this is applied exclusively to GUID identifiers, this could work for non-CASE situations as well)
• Create some new property in CTDL-ASN to handle non-URI identifiers (with range of xsd:string)
• Create some new property in CTDL as a super-property of ceterms:credentialId that applies to non-credential cases (this property has a range of xsd:string, which avoids the complexity of using IdentifierValue and its related properties), then borrow this property for CTDL-ASN (ceterms:identifier?)
• Borrow just the ceterms:identifierValueCode property from CTDL (range of xsd:string)

[Lomilar]

TODO: Translation from schema:identifier to ceasn:identifier should only happen if the identifier is a URI.

Transferring to cassproject/cass to be addressed by the CTDL-ASN export.

[Lomilar]

Relevant: https://github.com/CredentialEngine/vocabularies/issues/599

[woodkri]

I went ahead and added code to only translate schema:identifier and schema:publisher to ceasn if they are URLs. If ceasn:altIdentifier is added, we can amend it. This will allow for CTDL-ASN JSON-LD export of CASE frameworks in the meantime though.