search

cassproject / CASS

Competency and Skills System
http://cassproject.org
Apache License 2.0
50 stars 26 forks source link

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

Open Lomilar opened 5 years ago

Lomilar commented 5 years ago

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

woodkri commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

I think those are the pathways.

siuc-nate commented 5 years ago

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:

Lomilar commented 5 years ago

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 commented 5 years ago

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

woodkri commented 5 years ago

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.