{"slug": "open-78-card-tarot-meaning-dataset-for-symbolic-nlp-and-multilingual-experiments", "title": "Open 78-card tarot meaning dataset for symbolic NLP and multilingual experiments", "summary": "A proposed v2 dataset for 78-card tarot meanings will separate English and multilingual versions, with language-specific Hugging Face configs and a consistent schema per locale, following the precedent of Facebook's BOUQuET dataset. The design includes fields for card number, locale, card name, upright/reversed/love/career meanings, and provenance metadata, while keeping compact meanings as a distinct layer. The author suggests prototyping five cards in multiple shapes before freezing the schema.", "body_md": "Hmm… maybe something like this? :\n\nI think I would separate the three questions a little, because they interact, but they do not have to share the same answer.\n\nMy short version would be:\n\nThere is also one design choice that affects all three: whether the multilingual version is meant to be a **faithful translation of the English v1 interpretation**, a **locale-specific interpretation that is allowed to adapt**, or both.\n\nThose are slightly different datasets, even if they can live in the same repository.\n\nFor the Hub side, language-specific configs seem perfectly reasonable. Hugging Face describes a [subset/configuration as a sub-dataset](https://huggingface.co/docs/dataset-viewer/configs_and_splits), and explicitly gives multilingual datasets with one subset per language as a typical use case. The repository can define those configs directly in the dataset card YAML and map them to different files or globs without custom loading code; the current [data-files configuration docs](https://huggingface.co/docs/hub/datasets-data-files-configuration) show that pattern.\n\nThe useful distinction, I think, is:\n\nHow the multilingual data is canonically aligned does not have to be identical to how users load it from the Hub.\n\nA nice precedent is [BOUQuET](https://huggingface.co/datasets/facebook/bouquet). Its underlying data is fully multi-way parallel, but it is distributed through several views/configs, including language-specific ones. So using configs does not mean giving up multi-way alignment.\n\nIf I were trying a first v2 shape, I would probably test something like this:\n\n```\ndata/\n  en.parquet\n  tr.parquet\n  es.parquet\n  de.parquet\n  pt-BR.parquet\n```\n\nwith a consistent schema in every file, and then expose `en`\n\n, `tr`\n\n, `es`\n\n, `de`\n\n, `pt-BR`\n\n, plus optionally an `all`\n\nconfig.\n\nConceptually:\n\n```\ncard_number\ncard_id?                 # optional; card_number already works as an ID\nlocale\n\ncard_name\nupright_meaning\nreversed_meaning\nlove_meaning\ncareer_meaning\n\nvariant_type?            # e.g. faithful_translation / localized_interpretation\ncreation_method?         # human / machine / machine_postedited\nreview_status?\nsource_revision?\n```\n\nI would not call that the only correct representation, though.\n\nThere are at least three sensible shapes:\n\n| Priority | Shape I would test first |\n|---|---|\n| Load one language easily; add languages later | one common schema per locale + Hub configs |\n| Inspect all five translations side by side | wide/parallel language columns |\n| Treat each card as one self-contained object | nested `translations` structure |\n| Filter/analyze provenance per locale | `card × locale` long/tidy representation |\n\nAt only 78 cards, one unusually cheap way to decide is to prototype maybe **five cards** in two or three shapes, put them through the Dataset Viewer/Data Studio, and freeze the schema only after seeing which one is easiest to inspect and query.\n\nThat is probably more informative than deciding from schema aesthetics alone.\n\nAlso, I would keep the **storage format** as a separate decision. CSV is fine while most values are scalar strings. If v2 starts using real arrays for keywords or nested provenance/translation objects, Parquet or JSONL may become less awkward. Hugging Face currently supports all of these and generally recommends Parquet when richer typed/tabular data is useful.\n\nI would keep the compact meanings.\n\nThey are not merely an incomplete version of a future paragraph. They are a useful representation in their own right: they are easy to compare, embed, retrieve, classify, audit manually, and translate at matching granularity.\n\nIf more context becomes useful, I would add it rather than replace the compact layer.\n\nSomething like:\n\n```\nupright_keywords\nupright_meaning\nupright_context\n```\n\nwhere these could mean:\n\n```\nkeywords:\n  [\"new beginnings\", \"innocence\", \"adventure\", \"free spirit\"]\n\ncompact meaning:\n  \"New beginnings, innocence, adventure, free spirit\"\n\ncontext:\n  a longer explanatory paragraph\n```\n\nNot every layer necessarily has to exist in v2. The point is just that they answer different experimental questions.\n\nA very close independent example is the [Tarotoo 78-card dataset](https://huggingface.co/datasets/Tarotoo/tarotoo-tarot-card-meanings), which separates `keywords_upright`\n\n/ `keywords_reversed`\n\narrays from prose meaning fields and contextual fields. I would use that only as a useful schema comparison, not as an authority on which interpretation of a card is “correct.”\n\nThere is also a broader NLP reason to preserve compact descriptions: natural-language label descriptions and related terms are useful inputs for zero-shot and description-based classification rather than just human-readable metadata. For example, [Gao et al. (EMNLP 2023)](https://aclanthology.org/2023.emnlp-main.853/) study training with natural-language label descriptions, including related terms and short descriptions.\n\nOne thing I would try to preserve quite carefully is **granularity alignment**.\n\nFor example, comparing:\n\n```\nEnglish: 4 compact concepts\nSpanish: a 120-word explanatory paragraph\n```\n\nwith an embedding model makes it difficult to know whether a difference comes from translation drift or simply from comparing different kinds of text.\n\nFor experiments, I would prefer:\n\n```\nkeywords ↔ keywords\ncompact meaning ↔ compact meaning\ncontext paragraph ↔ context paragraph\n```\n\nwhenever possible.\n\nThis is the part where I would be most cautious about reducing everything to one score.\n\nI do not know of a standard metric specifically for “tarot symbolic consistency,” but the problem can be decomposed into several ordinary, testable questions.\n\nA small stack could be:\n\n```\nstructural alignment\n        ↓\nsame-card cross-lingual retrieval\n        ↓\ndeliberate corruption / contrast tests\n        ↓\nselective bilingual human review\n        ↓\noptional deck-level relational analysis\n```\n\nThis part is nearly free and catches boring errors before any semantic metric is involved.\n\nFor example, for five locales:\n\n```\n78 cards per locale\nunique(card_number, locale)\nno missing compact meanings\nexpected locale set\nvalid categorical values\nstatic metadata consistent where it should be\n```\n\nIf the dataset becomes 78 × 5 aligned rows, simple build-time checks may prevent a surprising amount of later debugging.\n\nFor each field, treat the 78 meanings in one language as a tiny retrieval corpus.\n\nFor example:\n\n```\nEnglish Fool / upright\n        ↓\nsearch all 78 Spanish upright meanings\n        ↓\nwhere does Spanish Fool rank?\n```\n\nThen repeat for all 78 cards and in both directions.\n\nUseful summaries could be:\n\nThis is not a particularly exotic evaluation. Sentence Transformers has a [ TranslationEvaluator](https://www.sbert.net/docs/package_reference/sentence_transformer/evaluation.html) built around essentially this idea: aligned source item\n\n`i`\n\nand target item `i`\n\nshould retrieve one another among all candidates.I would interpret it as an **alignment sanity check**, not as proof of translation quality.\n\nThis may be more useful than choosing the “best” embedding metric immediately.\n\nBefore trusting a metric, I would ask whether it responds correctly when the data is intentionally damaged.\n\nFor example:\n\n```\neasy:\n  random wrong card\n  completely wrong target language\n\nmedium:\n  upright ↔ reversed\n  love ↔ career\n  remove an important concept\n\nhard:\n  substitute a semantically similar card\n  substitute a card from the same suit\n  preserve most concepts but reverse one important one\n```\n\nThen a very basic desired property is:\n\n```\nscore(correct pair) > score(controlled corruption)\n```\n\nor, for retrieval, that the correct card ranks above the corrupted/hard-negative candidate.\n\nThis is similar in spirit to [DEMETR](https://aclanthology.org/2022.emnlp-main.649/), which evaluates machine-translation metrics by introducing controlled semantic, syntactic, and morphological perturbations and testing whether the metric actually notices them. One useful lesson from that work is that different learned metrics are sensitive to different error types.\n\nSo for this dataset I would probably think of the controls as **tests of the evaluator**, not just tests of the translations.\n\nRandom wrong-card negatives may actually be too easy. A more informative negative is often a card whose English meaning is already nearby.\n\nBecause there are only 78 cards, human checking is unusually feasible, but I would still not start by designing a large annotation project.\n\nA lower-cost flow could be:\n\n```\nautomatic alignment/retrieval checks\n        ↓\nflag:\n  very bad rank\n  very small or negative hard-negative margin\n  disagreement between embedding models\n  off-target / mixed-language text\n        ↓\nbilingual review of flagged items\n+ a small random sample of unflagged items\n```\n\nFor human review, I would separate at least two questions:\n\nAnd, if localization is intentional:\n\nThat distinction is close to the motivation behind [XSTS](https://aclanthology.org/2022.amta-research.24/), a bilingual human-evaluation protocol that focuses explicitly on semantic correspondence/adequacy rather than folding everything into fluency.\n\nSince 78 cards is tiny, another interesting exploratory test is to build the full 78×78 semantic-similarity matrix in each language.\n\nThere are only 3,003 unique card pairs, so one can ask whether relative neighborhoods are approximately preserved:\n\n```\nEnglish deck similarity structure\n        vs\nSpanish deck similarity structure\n```\n\nThis could reveal broad drift that same-card retrieval misses.\n\nI would keep this explicitly **exploratory**, though. The result depends heavily on the embedding model, so I would not call a matrix correlation a “symbolic fidelity score.”\n\n[/details]\n\nI think this decision should probably come before finalizing the evaluation.\n\nIf the goal is:\n\nThen the English v1 meaning is the reference interpretation, and divergence is mostly something to inspect.\n\n```\nEnglish v1\n  → faithful ES\n  → faithful DE\n  → faithful TR\n  → faithful PT-BR\n```\n\nSame-card retrieval and semantic adequacy make sense as fairly direct checks.\n\nThen some divergence from English may be **correct behavior**.\n\nA Spanish, Turkish, German, or Brazilian Portuguese interpretation may choose a different idiom, emphasis, or culturally natural wording while still serving the local reader better.\n\nIn that case, maximizing similarity to English can accidentally punish good localization.\n\nThis may actually be the most research-friendly version if it is not too much work:\n\n```\nfaithful_translation\nlocalized_interpretation\n```\n\nas separate variants.\n\nThen the dataset can support two different experiments:\n\nA useful precedent here is [MASSIVE](https://huggingface.co/datasets/AmazonScience/massive), which explicitly distinguishes whether an item was a `translation`\n\n, a `localization`\n\n, or left `unchanged`\n\n, rather than treating all target-language differences as one operation.\n\nI would not copy MASSIVE’s annotation machinery, but that distinction seems valuable here.\n\nAnd I would probably split the metadata into two separate questions:\n\n```\nvariant_type:\n  faithful_translation\n  localized_interpretation\n\ncreation_method:\n  human\n  machine\n  machine_postedited\n\nreview_status:\n  ...\n```\n\nbecause “what relationship does this target text have to the English meaning?” and “how was this text produced?” are not the same thing.\n\nA small synthetic sanity check I triedSo, if I were choosing the lowest-cost path, I think I would do roughly this:\n\n```\n1. Keep the existing 78-card identity and compact meanings.\n\n2. Decide whether v2 represents:\n   faithful translations,\n   localized interpretations,\n   or two separate variants.\n\n3. Prototype a few cards in 2–3 multilingual schemas.\n\n4. Pick the representation that is easiest to inspect,\n   but expose language-specific Hub configs regardless if useful.\n\n5. Add longer context only as an additional layer.\n\n6. Record just enough provenance to distinguish\n   locale / variant / creation method / review state.\n\n7. Add tiny structural validation.\n\n8. Evaluate with:\n   same-card retrieval\n   + deliberate hard controls\n   + selective human review.\n\n9. Treat deck-level geometry as exploratory, not as the definition\n   of symbolic consistency.\n```\n\nI do **not** think this needs to become a large ontology or a heavyweight MT benchmark to be useful.\n\nThe small, closed 78-card inventory is actually one of the attractive parts of the dataset: every item can be aligned, audited, perturbed, and compared exhaustively.\n\nSo I would mostly preserve that simplicity, and just separate the boundaries that become important once multiple languages enter the picture:\n\n```\ncard identity\n≠ localized wording\n\ncanonical alignment\n≠ Hub presentation\n\ncompact descriptor\n≠ contextual prose\n\nfaithful translation\n≠ localization\n\nautomatic anomaly score\n≠ human judgment\n```\n\nThat seems enough to keep the current dataset easy to use while making the multilingual version much easier to evaluate and extend later.", "url": "https://wpnews.pro/news/open-78-card-tarot-meaning-dataset-for-symbolic-nlp-and-multilingual-experiments", "canonical_source": "https://discuss.huggingface.co/t/open-78-card-tarot-meaning-dataset-for-symbolic-nlp-and-multilingual-experiments/179105#post_2", "published_at": "2026-08-23 11:07:18+00:00", "updated_at": "2026-08-23 11:13:47.818473+00:00", "lang": "en", "topics": ["natural-language-processing"], "entities": ["Hugging Face", "Facebook", "BOUQuET"], "alternates": {"html": "https://wpnews.pro/news/open-78-card-tarot-meaning-dataset-for-symbolic-nlp-and-multilingual-experiments", "markdown": "https://wpnews.pro/news/open-78-card-tarot-meaning-dataset-for-symbolic-nlp-and-multilingual-experiments.md", "text": "https://wpnews.pro/news/open-78-card-tarot-meaning-dataset-for-symbolic-nlp-and-multilingual-experiments.txt", "jsonld": "https://wpnews.pro/news/open-78-card-tarot-meaning-dataset-for-symbolic-nlp-and-multilingual-experiments.jsonld"}}