Revisiting material type classifications and presentation of material types

[akthom]

We should revise the presentation of the facets to display the hierarchical relationships in the controlled vocabulary. I'll focus on Material type first.

The values in "Material type" were all mapped to a controlled vocabulary available here: https://isamples.org/models/generated/vocabularies/material_type.html.

The Material Type controlled vocabulary is hierarchical. The iSamples Explorer, though, is displaying the facets as being all at the same level. They should instead be presented as a nested hierarchy, and in alphabetical order (first alphabetical from the top level category, and then the second level values should be alphabetical within each subcategory).

Does the data only contain the lowest level category, or does it contain the full hierarchy? If you can't read the hierarchy from the files, can you look at the docs I linked above to understand the hierarchies and arrange the facet accordingly?

The facets for Object Type and Sampled feature should be presented the same way. Those vocabularies are available at https://isamples.org/models/generated/vocabularies/material_sample_object_type.html and https://isamples.org/models/generated/vocabularies/sampled_feature_type.html

✅ Fixed in production — closing with evidence

@akthom — your instinct was right on both counts, and both are now fixed on isamples.org:

1. The nonsense "Material" entry (build-side read bug). The old derived build took the first entry of each sample's p__has_material_category array — but source records (especially SESAR) carry the whole SKOS ancestry there, so the root concept (label literally "Material") leaked into the facet. The rebuilt pipeline (#274) selects the first non-root concept instead. Verified against the production facet file this morning:

SELECT * FROM read_parquet('https://data.isamples.org/isamples_202606_facet_summaries.parquet')
WHERE facet_value LIKE '%material/1.0/material'
-- → 0 rows  (the root "Material" entry is gone)

2. Inaccurate material values (e.g. pottery as "anthropogenic metal") were a data-vintage problem in the frozen export — fixed by overlaying Eric's current OC concept mappings (#275, tracked in #272): material corrected on 502K samples, object type on 954K. Spot-check: the #260 sample now reads "Other anthropogenic material" on prod.

Follow-on, deliberately kept open: the counting semantics question (one material per sample vs counting a sample under every material it carries) is tracked in #276 — input welcome there.

— posted by 🤖 rbotyee; claims verified by executed queries against production; RY reviewed

Originally posted by @rdhyee in #265

[akthom]

Also - it looks like some classifications are missing, such as frozen water. Does this occur in the data? If so it should be in the facets

[rdhyee]

On your "frozen water" question — checked, and it's your option (a): genuinely zero samples, not a display problem. We looked at every position in every sample's material list (not just the single value the facet currently shows): no sample from any of the four sources carries material/1.0/waterice. The vocabulary defines it and our label table maps it correctly — there's just no data behind it. (The related "Any ice" concept does appear: 4 SESAR samples.)

The full coverage picture for the material vocabulary: of 21 concepts, 16 have data and appear; 4 have zero samples anywhere (waterice, fluid, dispersedmedia, rockorsediment); and the root "Material" is deliberately suppressed (661,637 samples are tagged only with the root — their handling is the counting-semantics question in #276). So nothing is being hidden by the display logic — the actionable path for frozen water is upstream: sources with cryosphere holdings need to tag samples with waterice.

On the main ask — hierarchical, alphabetized facet display: fully agreed, and Eric filed the same request the same afternoon (#281), so we're treating them as one design (details in my reply there). Short version: the published data carries each sample's full vocabulary path, so a two-level-unfolded tree is buildable; your alphabetical-within-level ordering is noted as the spec; and tree display makes the #276 membership-counting semantics the natural choice (parent count = children + direct). It's the headline feature of the next explorer phase, right after we land the automated-browser-test safety net (#249).

— 🤖 rbotyee; coverage numbers from executed queries against production data; RY reviewed