CredentialEngine / CredentialRegistry

Repository for development of the Credential Registry
Apache License 2.0
12 stars 10 forks source link

Searching for Competency Frameworks by creator CTID returns incorrect results #681

Closed siuc-nate closed 7 months ago

siuc-nate commented 8 months ago

This query is returning nearly all of the competency frameworks in the Registry (regardless of which CTID you use):

{
  "@type": "ceasn:CompetencyFramework",
  "ceasn:creator": {
    "ceterms:ctid": "ce-356bee5c-3740-40a8-b00d-c1c38ca7f103"
  }
}

image

excelsior commented 8 months ago

@siuc-nate This query has been fixed.

siuc-nate commented 8 months ago

Thanks. However, this query (used by the Finder) is now exhibiting the same behavior (returning over 1000 results). It also takes about 9ish seconds to execute.

{
  "@type": "ceasn:CompetencyFramework",
  "search:termGroup": {
    "search:operator": "search:orTerms",
    "ceasn:creator": {
      "ceterms:name": "connecting credentials",
      "ceterms:subjectWebpage": "connecting credentials",
      "search:operator": "search:orTerms"
    },
    "ceasn:publisher": {
      "ceterms:name": "connecting credentials",
      "ceterms:subjectWebpage": "connecting credentials",
      "search:operator": "search:orTerms"
    },
    "^ceasn:isPartOf": {
      "ceasn:competencyLabel": "connecting credentials",
      "ceasn:competencyText": "connecting credentials",
      "ceasn:comment": "connecting credentials",
      "ceasn:conceptKeyword": "connecting credentials",
      "search:operator": "search:orTerms"
    },
    "ceasn:name": "connecting credentials",
    "ceasn:description": "connecting credentials",
    "ceasn:source": "connecting credentials",
    "ceasn:conceptKeyword": "connecting credentials"
  }
}
excelsior commented 8 months ago

@siuc-nate There was a bug in the URI alias finder and it was uncovered by (what I believe) is an error in the context. The ceterms:subjectWebpage property's @type is @id, meaning that we expect it to point to another resource in the registry. However, the actual values of that property look like this: http://www.emilygriffith.edu. Which is just some URL, not a resource @id. That's why the conditions on ceterms:subjectWebpage were applied incorrectly.

The bug is fixed. And if my assumption is correct, ceterms:subjectWebpage's definition in the context should be changed. If you do so, let me know, I'll need to re-index all of the affected resources, and there are 100k of them.

BTW, can't we use the xsd:anyURI type for URLs? That'd help query them more efficiently.

siuc-nate commented 8 months ago

This has come up before, in the CTDL side of things: https://github.com/CredentialEngine/Schema-Development/issues/560 https://github.com/CredentialEngine/Schema-Development/issues/819 https://github.com/CredentialEngine/Schema-Development/issues/822

We've never been able to come to an agreement on an answer that is universally correct and useful, so I have long since given up on relying on the context and instead examine the schema:rangeIncludes for each property to figure out what it really points to (and even that isn't always perfect, since some properties like ceterms:targetNode can still point to other objects in the schema)

excelsior commented 8 months ago

Thanks, Nate! I took a look. Each envelope has a @context property with a value like this: https://credreg.net/ctdlasn/schema/context/json

However, those contexts only have @type info for each property.

schema:rangeIncludes is available at other locations, e.g.: https://credreg.net/ctdlasn/schema/encoding/json

But the latter one's aren't mentioned in the data that get published. BTW, what's the difference between the two?

siuc-nate commented 8 months ago

I'm not sure I understand the question - what is the difference between which two things?

excelsior commented 7 months ago

The difference between the two contexts:

  1. https://credreg.net/ctdlasn/schema/context/json
  2. https://credreg.net/ctdlasn/schema/encoding/json