Skip to content

Surface a DataSet's own licence in term info - #88

Merged
Robbie1977 merged 2 commits into
mainfrom
fix/dataset-terminfo-license
Aug 7, 2026
Merged

Surface a DataSet's own licence in term info#88
Robbie1977 merged 2 commits into
mainfrom
fix/dataset-terminfo-license

Conversation

@Robbie1977

Copy link
Copy Markdown
Contributor

Problem

Every DataSet page in v2 renders without a License row, e.g.
https://v2.virtualflybrain.org/org.geppetto.frontend/geppetto?id=Berg2025

The licence is in the KB — (:DataSet {short_form:'Berg2025'})-[:has_license]->(:License {short_form:'VFBlicense_CC_BY_4_0'}) — and it shows correctly in the AllDatasets results table. It is lost in term-info serialisation.

Cause

QueryLibrary.dataset_term_info (VFB_json_schema) uses the license() clause, so a dataset's licence comes back in license. Images and templates use dataSet_license() and come back in dataset_license.

term_info_parse_object only ever read dataset_license, so DataSet terms serialised as "Licenses": {}. Downstream, VFBProcessTermInfoVFBqueryJson.licenseList() builds the Source + License block from Licenses{} alone, so with an empty dict no License row is added.

The fallback exists everywhere else — term_info_queries.VFBTerm.get_license() has elif self.license:, and the legacy VFBProcessTermInfoJson.getLicense() has the same else if. Only this serialiser lost it, so the row disappeared when v2 moved onto the VFBquery term-info path.

Fix

Add the missing branch. source/source_iri are left empty: the dataset is its own source, and an empty source stops the panel rendering a Source row that links back to the page you are already on. No Java or client change needed — the License slot is already in VFBMain.js's ordered field list.

Verification

Parsed against live SOLR after the change:

Dataset Licence
Berg2025 CC-BY 4.0
Bates2025 CC-BY 4.0
Dorkenwald2023 CC-BY-NC 4.0
Cachero2010 CC-BY-SA 4.0

Three tests added to test_term_info_parity.py as Gap E, alongside the gaps this serialiser has already been reconciled against. The two dataset tests fail on main and pass here; the third asserts the dataset_license path is unchanged (JRC2018U keeps both its licence and its source attribution).

Note: test_individual_synonyms_present in that file already fails on main and is untouched by this change.

DataSet term info returns has_license on the term itself as `license`
(QueryLibrary.dataset_term_info), not as `dataset_license`, but
term_info_parse_object only read `dataset_license`. Every DataSet page
therefore came back with "Licenses": {} and the client rendered no
License row, even though the has_license edge was in the KB.

Add the same fallback the dataclass serialiser
(term_info_queries.VFBTerm.get_license) and the legacy Java serialiser
(VFBProcessTermInfoJson.getLicense) already have. Source is left empty
so the panel does not render a Source row linking back to the page you
are already on.

Add parity tests covering both the fallback and the unchanged
dataset_license path.
@Robbie1977
Robbie1977 requested a review from Clare72 August 7, 2026 10:05
@Clare72

Clare72 commented Aug 7, 2026

Copy link
Copy Markdown
Contributor

The elif means a term carrying both dataset_license and its own license would only surface the inherited one. In practice the query library populates one or the other per term type, and this matches get_license(), so it's fine — worth a one-line acknowledgement, not a change.

@Robbie1977

Copy link
Copy Markdown
Contributor Author

Agreed — deliberate, and it matches get_license(): if both were ever populated, dataset_license wins. In practice the query library gives you one or the other (dataset_term_infolicense, anatomical_ind/template/pub_term_infodataset_license), so the case doesn't arise today. Noted at the branch point in 541cc12 rather than changing the behaviour.

@Robbie1977
Robbie1977 merged commit 395654a into main Aug 7, 2026
2 of 4 checks passed
@Robbie1977
Robbie1977 deleted the fix/dataset-terminfo-license branch August 7, 2026 10:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants