Credential Query for all Subclasses and to Exclude Classes Are Not Bringing Back Correct Results

[jeannekitchens]

At the time of writing this, there's, 102,796 credentials published to the Registry across Credential Classes. See the full list of Credential Classes https://credreg.net/ctdl/handbook#credentialclasses. This is a query I need a customer to use but I cannot provide the information to them because neither query works.

The query below should bring back all 102,696 credentials. However, it only brings back 97,738 credentials.

{
"@type": {
"search:value": "ceterms:Credential",
"search:matchType": "search:subClassOf"
}
}

This query is supposed to exclude the Credential Class QACredential. However, it does not work. It brings back 97,738 credentials. The "search:notValue" does not work.

{
"@type": {
"search:value": "ceterms:Credential",
"search:matchType": "search:subClassOf",
"search:notValue": "ceterms:QACredential"
}
}

[excelsior]

@jeannekitchens The query engine looks for a root class's subclasses under the subsclasses_map property in the community config. The current CE config doesn't have such a property, so the default mapping is used, which can be found here. Putting the up-to-date mapping into the config should fix the issue.

The second query's syntax is wrong, the correct query would be:

{
  "@type": {
    "search:value": "ceterms:Credential",
    "search:matchType": "search:subClassOf"
  },
 "!@type": "ceterms:QACredential"
}

But this one won't work either because the mapping is outdated.

[jeannekitchens]

@mparsons-ce are you handling updating of the Registry config for adding subclasses. Per above comment from @excelsior it needs to be updated and the mapping is outdated. @excelsior this is definitely a problem as the first thing that comes to my mind is that consumers are missing thousands of credentials. I need to know exactly what needs to happen so the three queries work dependably that caused this issue. @rohit-joy @chuang-CE tagging you for awareness. I would think the CLLC Registry also has a configuration that has to be maintained.

[mparsons-ce]

@excelsior
The only config file that I update is:
https://credentialengineregistry.org/metadata/ce-registry/config
Sample from github
https://github.com/CredentialEngine/CredentialRegistry/blob/master/fixtures/configs/ce_registry.json

does not have the property: subsclasses_map.
Should the latter be added verbatim to the latter config file?

[jeannekitchens]

@excelsior @edgarf we need to know how the config file referenced above by @excelsior is created/updated. If it relies on manual updates that seems problematic also because we didn't know it was needed. The queries are simple and were previously verified to work...according to closed Github issues.

[excelsior]

@mparsons-ce I added the default mapping into the default config:

https://github.com/CredentialEngine/CredentialRegistry/blob/829-config-with-subclasses-map/fixtures/configs/ce_registry.json#L287

Please let me know one the actual config is updated with the up-to-date mapping so I can make sure the subclasses are resolved correctly.

[mparsons-ce]

@excelsior I am adding the subclasses to the config file that I have been using.
The config file referenced above does not include all of the credential subclasses and is missing all the newer ones (like credentialing actions, supportService, VerificationServiceProfile, etc). So I am using the config file from production (https://credentialengineregistry.org/metadata/ce-registry/config) and adding the subclass section.
It seems there is a disconnect on how this file is used?

I see the subclasses are not up to date either, based on:
https://credreg.net/page/typeslist

[mparsons-ce]

@excelsior
I merged the subclasses_map data into the registry config file.
I added it to the following file for discussion:
CredentialEngine/Schema-Development#998

The config file that I was using did NOT have the following section:
"aliases": {
"ctid": "ceterms:ctid"
},
Should it be added?

For the subclasses
It seemed that every class had to had appear in the list at the top level even if it did appear in a hierarchy.
So I did follow that pattern.

[mparsons-ce]

@excelsior Another question
For id_prefix, is it the same regardless of whether for prod, sandbox, or staging?
"id_prefix": "http://credentialengineregistry.org/resources/",

what about for custom communities like for Florida (fdoe)?

"id_prefix": "http://credentialengineregistry.org/resources/",
VERSUS
"id_prefix": "http://credentialengineregistry.org/fdoe/resources/",

[mparsons-ce]

@excelsior Just as a test, I updated the sandbox with the updated config file.
Is there a delay where the sub class mapping has to be applied?
I tried the following to get all subclasses for Certificate:

"Query": {
    "@type": {
        "search:value": "ceterms:Certificate",
        "search:matchType": "search:subClassOf"
    }
},

It didn't include AcademicCertificate. This was one of the classes that was missing from the config file in github.
https://github.com/CredentialEngine/CredentialRegistry/blob/829-config-with-subclasses-map/fixtures/configs/ce_registry.json#L287

[excelsior]

The config file that I was using did NOT have the following section:
"aliases": {
"ctid": "ceterms:ctid"
},
Should it be added?

No, it isn't used in the app.

For id_prefix, is it the same regardless of whether for prod, sandbox, or staging?

Same as above, not used, so it doesn't really matter.

I merged the subclasses_map data into the registry config file.

I'm looking at the current config (retrieved via GET /metadata/ce-registry/config) and can't find the subsclasses_map property. Are you sure the config was updated with the correct subclass mapping?

[mparsons-ce]

I had only updated the sandbox, not production yet.

[mparsons-ce]

@excelsior If the latter looks OK, I can go ahead and update production.

[excelsior]

@mparsons-ce The changes look good indeed. Please update the production config the same way.

[mparsons-ce]

@excelsior I have updated production.

[excelsior]

@jeannekitchens @mparsons-ce I checked the query results after Mike updated the config, and now the original query returns slightly more data than you'd expect.

{
  "@type": {
    "search:value": "ceterms:Credential",
    "search:matchType": "search:subClassOf"
  }
}

returns 104,463.

{
  "@type": {
    "search:value": "ceterms:Credential",
      "search:matchType": "search:subClassOf"
    },
  "!@type": "ceterms:QualityAssuranceCredential"
}

returns 104,448.

{
  "@type": "ceterms:QualityAssuranceCredential"
}

returns 15, which is 104,463 – 104,448, so the math checks out now.

If 102,796 the correct number of credentials, I'll try to find out where does this discrepancy come from.

[jeannekitchens]

@excelsior thank you. The registry counts are a moving target. New data is published almost daily so it is very possible that the quantity increased. Also, we account for blank nodes with the Finder making is somewhat confusing to verify counts. We need to double check a couple things on our end. What had to be manually changed to correct this? Is this something that is programatically updated or manually updated?

[khasan786]

@mparsons-ce Can you implement the suggestions implemented by @jeannekitchens so we can bring a closure to this issue now that record counts are back up to the expectations ?

[excelsior]

@jeannekitchens No manual adjustments are required.

[khasan786]

@excelsior & @mparsons-ce Can this issue be closed now?..

[khasan786]

Closing this issue after creating #841 for documenting the configuration steps.