fix(dataset-registry-client): type the IRI-valued schema properties as IRIs - #762
Merged
Merged
Conversation
…s IRIs - Declare '@type': ldkit.IRI on license, accessURL, mediaType, compressFormat and conformsTo, which hold IRIs in DCAT-AP. Without it LDkit falls back to xsd:string and encodes a search value as a plain literal, so a filter such as mediaType $in [...] compares an IRI to a string and can never match. - The mismatch was invisible because LDkit emitted a search FILTER inside the OPTIONAL block of an optional property, where it only unbound the value instead of removing the row; ldkit 2.7.2 hoists the FILTER out of the block and makes it bite. - Cover a distribution that declares no media type through an $id query: media-type criteria now narrow a dataset's distributions to the matching ones, so a filtered query no longer reaches that path.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Unblocks #734 (ldkit 2.7.1 → 2.7.2), where
queries datasets from SPARQL endpoint with criteriareturns 0 instead of 3.DatasetSchemaleftlicense,accessURL,mediaType,compressFormatandconformsTowithout an@type, so LDkit fell back toxsd:stringand encoded a search value as a plain literal:FILTER (?iri_6_1 IN ("https://www.iana.org/assignments/media-types/text/turtle", …))The data holds those values as IRIs, so the comparison can never match. Declaring
'@type': ldkit.IRIemits<…>instead.The mismatch was invisible until now because LDkit emitted the search
FILTERinside theOPTIONALblock of an optional property, where it only left the value unbound instead of removing the row – the filter did nothing, so every dataset came back and the assertion passed for the wrong reason. ldkit 2.7.2 (karelklima/ldkit#176) hoists theFILTERout of the block and makes it bite, which is what surfaced this.Behaviour change once ldkit 2.7.2 lands
An effective nested filter also narrows what comes back:
query({ distribution: { mediaType: { $in: […] } } })returns a matching dataset with only its matching distributions, not all of them. The new$idtest covers reading back a distribution that declares no media type, which a filtered query no longer reaches.Verified against both ldkit 2.7.1 (this branch) and 2.7.2 (#734's lockfile).