Talk:Q772497

From Wikidata
Jump to navigation Jump to search

Autodescription — Hebrew cantillation (Q772497)

description: Jewish practice of melodically reciting holy texts; cantilenas are based on Teamim
Useful links:
Classification of the class Hebrew cantillation (Q772497)  View with Reasonator View with SQID
For help about classification, see Wikidata:Classification.
Parent classes (classes of items which contain this one item)
Subclasses (classes which contain special kinds of items of this class)
Hebrew cantillation⟩ on wikidata tree visualisation (external tool)(depth=1)
Generic queries for classes
See also


לא ברור לי ההבדל

[edit]

בין זה לבין: Q112143953. מדובר על אותו נושא. ויקיפדיות שנכתב בהן על זה - אין בהן כלום על האחר. בברוך (talk) 18:31, 1 August 2022 (UTC)[reply]

אני חושב ש-Q772497 מתאר את ההקראה בקול של הטעמים, בעוד ש-Q112143953 מתאר את הכתיב. ההבדל דק מאוד וגם לדעתי העמודים בויקיפדיה צריכים להיות מקושרים יחד. אין שפה של ויקיפדיה שיש בה את שניהם.
-- NeatNit (talk) 17:40, 3 April 2023 (UTC)[reply]
→ ← Merged. -- -- -- 21:08, 1 June 2023 (UTC)[reply]
The difference between the system of signs and writing and between performance is not a thin line, but literally things that have no connection whatsoever. For example the Russian article is called "Cantillation signs in Hebrew writing". Have you ever seen a musical genre with such a name? The articles in some cases have identical titles "Teamim" and that is more of a specific wikipedia problems since the concept described in the articles are not always consistent with the title (mostly it's mentioned by a single sentence only, while the rest article describes the other concept). That's acceptable for wikipedia, but not for wikidata. But normally the articles should be rather renamed to what they describe. Here on WD, I have tried to separate articles based on what they predominantly describe. Perhaps somewhere it can be done more neatly - so you can move articles if they mainly describe a different concept (but in the case of the English article, that would be problematic and would probably require renaming). There also an option to create a new QItem with "Teamim" label and make instance of (P31) = Wikipedia article covering multiple topics (Q21484471) and list both concepts in the "main subject", but then the articles would have to be divided even more, so it's not really optimal. Solidest (talk) 00:34, 2 June 2023 (UTC)[reply]
As User:NeatNit wrote above, not a single Wikipedia has two separate articles for the two concepts; and although I don't understand most languages, my assumption is that they all cover both concepts. They way it was before I did the merge, when one was looking at the English-language article, he or she would wonder how can it be that the Hebrew Wikipedia doesn't yet have an article on this? The next step would be to go to main page, then switch to the Hebrew Wikipedia's main page, then switch the keyboard from English to Hebrew, then type in the searchbar "טעמי המקרא", and then, finally, reach the Hebrew article. The same process would apply to someone reading the Hebrew article and wondering how can it be that the English-language Wikipedia doesn't yet have an article on this. So as long as no one goes and splits the article(s) into two - one for the cantillation itself and one for the cantillation "signs", I believe they should all be held together in the same item, and not divided based on the arbitrary titles given to the articles. If we would revert to the way it was before I did the merge, then it's likely that someone else will come along and merge them back again. Sincerely, -- -- -- 23:10, 2 June 2023 (UTC)[reply]
It is a standard case where several loosely related concepts are described in the same article on wikipedias, and I have listed three solutions that are usually allowed to resolve such cases. However, it is preferable that each article in each language is handled independently of the others. Merging different concepts on wikidata for the sake of wikipedia is a mistake. But handling articles, as i said before, allows a freer approach, so feel free to resolve it with any of the listed approaches instead of merging. Solidest (talk) 03:06, 3 June 2023 (UTC)[reply]