Wikidata:Requests for comment/Changes to P2737 and P2738
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
There is consensus to keep the use of dummy values as agreed in the property proposals. The parts of the union are listed as qualifiers. − Pintoch (talk) 23:49, 7 November 2018 (UTC)
| An editor has requested the community to provide input on "Changes to P2737 and P2738" via the Requests for comment (RFC) process. This is the discussion page regarding the issue.
If you have an opinion regarding this issue, feel free to comment below. Thank you! |
The way properties union of (P2737) and disjoint union of (P2738) are largely used, and the way their original proposals suggest they be used, doesn't make a whole lot of sense in most cases. For cases where the intended values of these properties form distinct, non-overlapping sets, the properties have used a "dummy" item, list of values as qualifiers (Q23766486), with the actual values given in qualifiers. So far, so good – this allows it to be clear that some values form one set, while other values form a different set.
The problem, however, is that when there are not multiple sets to consider (which is most of the time), the use of the dummy item doesn't serve any purpose, and it makes the use of union of (P2737) and disjoint union of (P2738) different from all other properties, in that its values are not given directly, but only as qualifiers.
I would like to revise the use and documentation of these two properties, and the dummy qualifier, to make it clear that when values do not form distinct sets, the dummy value should not be used, and instead the actual values should be direct values of the properties, as is done with all other properties.
I initiated discussion on the dummy value, but didn't get input there, so I implemented much of this change in BOLD fashion. Obviously, if consensus is found to maintain status quo, these edits will all be undone.
Swpb (talk) 19:28, 3 January 2018 (UTC)
Discussion edit
- I reverted these edits because there were extensive discussions that took place at property creation and that this argumentation is not new.
- There is templates that requires that stuffs works that way, transcluded into Template:Item documentation
- It’s way simple to write them when these kind of statements are written in a consistent way. And not « if there is :only one partition then the set off all statements describe it, but else the qualifiers are to be taken »
- If a source states that a class is partitioned into a set of subclasses, then the semantics is that it source the whole statement, not each of these smaller statements meaningless. The same difference beetween « I’m made of my head and my body » (and that’s all as a statement is assumed to be complete) and « I’m made of my head ». « I’m made of my body » separately. I may also be made of something else as the set of statements is not supposed to be complete.
- The completeness issue. If « I’m made of my head and my body » and « I’m made of my head » you’ll have to rely on external tools to state I’m not made of something else ( http://ceur-ws.org/Vol-1963/paper466.pdf ) COOL-WD to name it.
- This breaks existing query. author TomT0m / talk page 19:41, 3 January 2018 (UTC)
- Mmm don’t know why or how, but a topic where swpb and I where discussing prior to this RfC and whose originated this page
https://www.wikidata.org/w/index.php?title=Topic:U50sv2c17wqyeq6w&topic_showPostId=u50vt3x2kgvjter8#flow-post-u50vt3x2kgvjter8 has been masked while I was replying to one of the answer, which I find kind of rude if swpb did this. author TomT0m / talk page 19:52, 3 January 2018 (UTC)
- I absolutely did hide a thread on my personal talk page, as is my right, and it could have saved you the embarrassment of your behavior there being visible to all. I've hid it again, because it was completely unproductive. All discussion of this issue can happen in this RFC, where wider participation will hopefully encourage adulthood. If you'd like to remove your off-topic aside here, you may remove this reply as well. Swpb (talk) 21:20, 3 January 2018 (UTC)
- I won’t take a word away, sorry. Assuming everything I said, not ready to take all the blame here as you seem to try to push me to and presenting the issue. Seems that you’re not gaining any attention at all. author TomT0m / talk page 14:15, 4 January 2018 (UTC)
- I absolutely did hide a thread on my personal talk page, as is my right, and it could have saved you the embarrassment of your behavior there being visible to all. I've hid it again, because it was completely unproductive. All discussion of this issue can happen in this RFC, where wider participation will hopefully encourage adulthood. If you'd like to remove your off-topic aside here, you may remove this reply as well. Swpb (talk) 21:20, 3 January 2018 (UTC)
- An illustration on why such unilaterally changes are bad : this breaked Template:Class reports and I had to revert some changes https://www.wikidata.org/w/index.php?title=Q188745&diff=616255730&oldid=616150128 in order to make it work again. It’s pretty inconsequential as this template is not used a lot, but imagine it breaks an enwiki infobox … The « be bold » argument is pretty weak on Wikidata. author TomT0m / talk page 20:21, 3 January 2018 (UTC)
- Sorry I'm not understanding the issue here - could you illustrate the problem with some specific examples (where you think the current approach works, and where it doesn't for instance)? ArthurPSmith (talk) 20:50, 8 January 2018 (UTC)
- @ArthurPSmith: Take the property example on union of (P2737): There are five values given for the property; they comprise one set. But instead of being given as values of union of (P2737) itself, they're given as values of a qualifying property, of (P642), with a dummy property in the main value slot. This is a layer of complication that no other properties use. Conventional statements, i.e. chemical compound (Q11173)union of (P2737)solid (Q11438), etc., are readily interpreted correctly: that chemical compound (Q11173) is a union of all the values given. The case for a dummy property is sound for items like vertebra (Q180323), where there is a need to indicate separate sets, but that case doesn't seem to apply when there is only one set of values. Nor should the existence of tools that "expect" the current usage foreclose changing the usage to be like the rest of the project; tools can be updated. Swpb (talk) 19:47, 9 January 2018 (UTC)
- Ah, I get it now. Ok, this is a little obscure though. I think the fundamental problem stems from Wikidata not having any notion of "lists" (generally a pretty fundamental data object). That is, you cannot make a list as a whole the value of a statement. The mechanism used in this case with union of (P2737) is a work-around for that; conceptually I believe the intent was to see this as if the value of the statement was the list specified in those qualifiers; obviously a dummy value is meaningless in itself. If you don't need a list-valued statement then you probably don't really need to be using union of (P2737), do you? ArthurPSmith (talk) 21:50, 9 January 2018 (UTC)
- Well, then I guess the question becomes "when do you need a list-valued statement?" In every other area of the project I know of, multiple values are expressed with multiple statements; there hasn't been an apparent need to get them all into a single statement. I'm not convinced why these two properties should be any different, other than for the case of multiple, independent sets already noted. Simplicity of sourcing maybe, but I'm not sure that's enough of a justification. Swpb (talk) 13:55, 10 January 2018 (UTC)
- @Swpb: As I said in the introduction of the property proposal, this actually would be an inverse property for « subclass of » that we usually consider a bad thing. You claim to be aware of the discussions, so you should know that. author TomT0m / talk page 13:30, 10 January 2018 (UTC)
- You seem to confuse awareness with agreement. If you want your comments to carry any weight with the closer, try addressing the points raised here. Swpb (talk) 13:55, 10 January 2018 (UTC)
- Ah, I get it now. Ok, this is a little obscure though. I think the fundamental problem stems from Wikidata not having any notion of "lists" (generally a pretty fundamental data object). That is, you cannot make a list as a whole the value of a statement. The mechanism used in this case with union of (P2737) is a work-around for that; conceptually I believe the intent was to see this as if the value of the statement was the list specified in those qualifiers; obviously a dummy value is meaningless in itself. If you don't need a list-valued statement then you probably don't really need to be using union of (P2737), do you? ArthurPSmith (talk) 21:50, 9 January 2018 (UTC)
- @ArthurPSmith: Take the property example on union of (P2737): There are five values given for the property; they comprise one set. But instead of being given as values of union of (P2737) itself, they're given as values of a qualifying property, of (P642), with a dummy property in the main value slot. This is a layer of complication that no other properties use. Conventional statements, i.e. chemical compound (Q11173)union of (P2737)solid (Q11438), etc., are readily interpreted correctly: that chemical compound (Q11173) is a union of all the values given. The case for a dummy property is sound for items like vertebra (Q180323), where there is a need to indicate separate sets, but that case doesn't seem to apply when there is only one set of values. Nor should the existence of tools that "expect" the current usage foreclose changing the usage to be like the rest of the project; tools can be updated. Swpb (talk) 19:47, 9 January 2018 (UTC)
Oppose. Consistency is important. Consistent use of the dummy value makes all uses of the property have the same structure, allowing easier queries. --Yair rand (talk) 21:26, 23 October 2018 (UTC)- Oppose, there is the consistency argument which is important, but there is also a conceptual argument that was present from the beginning in the property proposal : the open world assumption is reasonable to make on Wikidata, that is the information on our entities is not always complete and we have to « add » information to state that it is. For example, if we have statements about the children of a person, we have to add information about its number of children to know if we all the possible « child » statements on Wikidata. « union of » and « disjoint union of », on the other hand, only make sense if the information is complete. On the other hand it’s safe to assume a statement IS complete and represent a unit of information, that is the classes listed in one statement is complete. author TomT0m / talk page 11:12, 3 November 2018 (UTC)
