Wikidata:Property proposal/requires form
Jump to navigation
Jump to search
requires form[edit]
Originally proposed at Wikidata:Property proposal/Lexemes
Not done
| Description | form required from lexemes following subject lexeme |
|---|---|
| Data type | Form |
| Domain | lexemes, generally secondary forms on lexemes. Languages where this is useful (initially, la/fr) |
| Allowed values | forms of lexemes |
| Example 1 | "ab" Lexeme:L13362-F2 → u |
| Example 2 | "ab" Lexeme:L13362-F2 → e |
| Example 3 | "ab" Lexeme:L13362-F2 → i |
| Example 4 | "e" Lexeme:L11738-F2 → m |
| Planned use | add to some recently created entities |
| See also | requires grammatical feature (P5713) |
Motivation[edit]
For mere text comparison, it seems better to map this explicitly to forms, not features. (Add your motivation for this property here.) --- Jura 13:33, 5 October 2018 (UTC)
Discussion[edit]
Comment seems it does raise any issue. Ready to go? --- Jura 11:12, 13 October 2018 (UTC)- @Jura1: I think it would be good to have supporting votes first. (I personally do not have a clue what this is about.) − Pintoch (talk) 17:18, 14 October 2018 (UTC)
Oppose I also have no clue what this is about. Since forms are live, I don't understand why the examples aren't given as direct links? The intent seems to be to link one form to another because of - what? Anyway, until this is better explained, count this as an opposing vote. ArthurPSmith (talk) 14:26, 15 October 2018 (UTC)
- Fixed the links (there don't seem to be any anchors for forms). Target ones don't have lexemes yet. The sample is in Latin. Maybe there is something similar in English, but I'm not sure. The scope is currently limited to Latin and French. --- Jura 14:50, 15 October 2018 (UTC)
- I wonder if the anchors had been there and were removed since. --- Jura 15:11, 15 October 2018 (UTC)
- @Jura1: may I suggest once again that it is in your interest to take the time to actually explain what you are proposing? Even if you do not care about things like being friendly or just polite, explaining your proposal is crucial to get support votes, so if you want this property to be created you should do it out of pure self-interest. People will not support this proposal if they cannot understand it. Be strategic, communicate! − Pintoch (talk) 15:59, 15 October 2018 (UTC)
- What points would need explaining? I think I explained the borked anchors. --- Jura 16:02, 15 October 2018 (UTC)
- How about trying to write a few paragraphs describing what information this property will encode, explaining the linguistic notions that are involved, possibly with links to external resources on the subject? It is also useful to show that you have considered alternative modelling approaches (and explain these). For instance, aim to get something like Wikidata:Property proposal/stated in reference as. Just try to imagine you are a random Wikidata editor who does not know anything about the subject - they are not in your brain, and they have other things to do than trying to decipher your thoughts so you should make it extremely clear and easy for them to understand (and therefore support) your proposal. − Pintoch (talk) 16:16, 15 October 2018 (UTC)
- I think it's preferable to keep the proposal in the recommended format. I understand that the overwhelming flow of information in Wikidata makes it tempting to access all of it, but without the basics of Latin, I'm not sure if it's actually a good idea to attempt to edit Latin lexemes. Explaining them here exceeds the scope of the project and would probably by a misuse of project resources. It's also complicated to understand Lexemes if one hasn't actually tried it. In any case, I'd expect people looking at these having at least reviewed the samples and compared with their usual sources. --- Jura 16:29, 15 October 2018 (UTC)
- Sure, if you think communicating is a waste of resources, that is up to you. I vote Oppose then. − Pintoch (talk) 16:32, 15 October 2018 (UTC)
- It seems that you oppose what you don't attempt to understand. Not sure if this a productive use of other volunteers' time and resources. --- Jura 16:35, 15 October 2018 (UTC)
- Sure, if you think communicating is a waste of resources, that is up to you. I vote
- I think it's preferable to keep the proposal in the recommended format. I understand that the overwhelming flow of information in Wikidata makes it tempting to access all of it, but without the basics of Latin, I'm not sure if it's actually a good idea to attempt to edit Latin lexemes. Explaining them here exceeds the scope of the project and would probably by a misuse of project resources. It's also complicated to understand Lexemes if one hasn't actually tried it. In any case, I'd expect people looking at these having at least reviewed the samples and compared with their usual sources. --- Jura 16:29, 15 October 2018 (UTC)
- How about trying to write a few paragraphs describing what information this property will encode, explaining the linguistic notions that are involved, possibly with links to external resources on the subject? It is also useful to show that you have considered alternative modelling approaches (and explain these). For instance, aim to get something like Wikidata:Property proposal/stated in reference as. Just try to imagine you are a random Wikidata editor who does not know anything about the subject - they are not in your brain, and they have other things to do than trying to decipher your thoughts so you should make it extremely clear and easy for them to understand (and therefore support) your proposal. − Pintoch (talk) 16:16, 15 October 2018 (UTC)
- What points would need explaining? I think I explained the borked anchors. --- Jura 16:02, 15 October 2018 (UTC)
- @Jura1: may I suggest once again that it is in your interest to take the time to actually explain what you are proposing? Even if you do not care about things like being friendly or just polite, explaining your proposal is crucial to get support votes, so if you want this property to be created you should do it out of pure self-interest. People will not support this proposal if they cannot understand it. Be strategic, communicate! − Pintoch (talk) 15:59, 15 October 2018 (UTC)
- @Djiboun, Tacsipacsi, Daniel Mietchen: as active contributors of Latin lexemes, what's is your take on this? --- Jura 17:51, 15 October 2018 (UTC)
- As far as I remember, I’ve created exactly one Latin lexeme (about a proverb; not a preposition, like the ones in the examples). I have never learned Latin or any Romance language, so I have no idea what this property would be about. —Tacsipacsi (talk) 18:50, 15 October 2018 (UTC)
- Oppose I do contribute to Latin lexemes but I have the same problem like Pintoch, I find Jura1 proposals written in so cryptic language that I usually abstain from voting, but in this case if Jura1 openly refuse to explain purpose of the property than there is no agreement in me to such cooperation in lexeme namespace. I oppose until Jura1 will not explain this property proposal. KaMan (talk) 06:32, 16 October 2018 (UTC)
- Do you have any specific questions that need answering? I agree that "subject lexeme" is a bit cryptic and even confusing to longtime Wikidata editors (see Wikidata:Project_chat#Author_Qualifiers), but it seems to be the appropriate way to reference the lexeme to which the property is added. "form" in the context of the property is a form found on a L-entity. --- Jura 11:59, 16 October 2018 (UTC)
- I do not understand description, domain, examples and motivation phrase. My English understanding is far from perfect and there can be specialistic lexicographical layer of English vocabulary too. KaMan (talk) 15:20, 16 October 2018 (UTC)
- Do you have any specific questions that need answering? I agree that "subject lexeme" is a bit cryptic and even confusing to longtime Wikidata editors (see Wikidata:Project_chat#Author_Qualifiers), but it seems to be the appropriate way to reference the lexeme to which the property is added. "form" in the context of the property is a form found on a L-entity. --- Jura 11:59, 16 October 2018 (UTC)
Question @Jura1: I just have a few questions. Am I correct in saying that this property is to be used to illustrate what form must follow the lexeme that the property is added to? If that is correct, then I see two issues given the examples provided. Firstly, each example has the property added to a form of the lexeme, not the lexeme itself, which actually makes a lot of sense. Shouldn't the domain of this property then be "forms" and not "lexemes"? Also, the values for each of the examples are letters/characters, and not actual forms. Would the datatype then not be forms, but rather Q-Items representing letters or classes of letters (such as "vowels" or "consonants"). In that case, perhaps a more suitable name for this property might be "requires following lexeme to start with" or "precedes lexeme starting with". Furthermore, I feel that this would be needed in more than just Latin and French, but also any language that has words derived from Latin or French. For example, the English prefix "ab-" is derived from the Latin preposition "ab", and it has the form "a-" when it precedes lexemes starting with 'm', 'p' or 'v'. Also, the Italian conjunction "e" has the form "ed" when it precedes lexemes starting with a vowel. However, I may have completely incorrectly interpreted the description of this property. Have I understood correctly? Liamjamesperritt (talk) 22:39, 4 November 2018 (UTC)
- @Liamjamesperritt: I think you mostly understood it. Thanks for your review. Re "firstly": yes, it should be primarily on forms (a part of a lexeme). The "domain" above indicates that. Re "also": letters can be forms. To work, I think the forms should be language specific. You could use requires grammatical feature (P5713) if you want to link items, but these seems to make it difficult to match strings. Re "furthermore": please re-read domain above. Feel free to add more languages, but make sure it is (at least in samples) and can be used consistently in these languages. --- Jura 14:34, 5 November 2018 (UTC)
- @Jura1: Thank you very much for the clarification. I wasn't aware that letters were being added in the Lexeme namespace. It does make sense and I agree that using explicit forms (which have only one representation) rather than items (which generally have multiple labels) would help with string matching. I still think it would be clearer if the name of the property communicated that it is specifically the 'first letter' of the following form that is being required, not the whole form. I feel that "requires form starting with" or "requires word-initial" would be clearer potential names for this property. I also feel that being able to state the classes of letters that are required, such as vowel for the English article "an" or potentially even labial consonant for the Latin-derived English prefix "im-" (rather than three separate statements for 'm', 'b' and 'p'), and I don't think that requires grammatical feature (P5713) is appropriate as it does not illustrate that the required feature is referring to the first letter only (and is generally only used to reference cases and moods). Therefore, a Q Item datatype might still be more useful here. Liamjamesperritt (talk) 02:35, 8 November 2018 (UTC)
- @Liamjamesperritt: I think you mostly understood it. Thanks for your review. Re "firstly": yes, it should be primarily on forms (a part of a lexeme). The "domain" above indicates that. Re "also": letters can be forms. To work, I think the forms should be language specific. You could use requires grammatical feature (P5713) if you want to link items, but these seems to make it difficult to match strings. Re "furthermore": please re-read domain above. Feel free to add more languages, but make sure it is (at least in samples) and can be used consistently in these languages. --- Jura 14:34, 5 November 2018 (UTC)
Not done No support.--Micru (talk) 09:43, 22 December 2018 (UTC)