Closed siuc-nate closed 7 months ago
@siuc-nate This query has been fixed.
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"
}
}
@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.
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)
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?
I'm not sure I understand the question - what is the difference between which two things?
The difference between the two contexts:
This query is returning nearly all of the competency frameworks in the Registry (regardless of which CTID you use):