Wikidata:Property proposal/source of transfer & destination of transfer
source of transfer & destination of transfer
[edit]source of transfer
[edit]Originally proposed at Wikidata:Property proposal/Generic
Description | entity that a transferred item is initially associated with, before this process associates it with another entity (the destination of transfer) [aliases: source / sender] |
---|---|
Represents | source (Q31464082) |
Data type | Item |
Example 1 | pitch (Q1063937)source of transferpitcher (Q1048902) / pitch (Q1063937)destination of transfercatcher (Q1050571) |
Example 2 | data import into Wikidata (Q107661232)destination of transferWikidata (Q2013) |
Example 3 | Alaska Purchase (Q309029)source of transferRussian Empire (Q34266) |
Example 4 | radio broadcast (Q64707203)source of transfertransmitter (Q190157) / radio broadcast (Q64707203)destination of transferradio receiver (Q159391) |
See also | addressee (P1817), start point (P1427) / destination point (P1444), target (P533), participant (P710) |
destination of transfer
[edit]Originally proposed at Wikidata:Property proposal/Generic
Description | entity that a transferred item comes to be associated with as a result of this process [aliases: recipient / receiver / destination ] |
---|---|
Represents | recipient (Q20820253) |
Data type | Item |
Example 1 | see #source of action |
Example 2 | see #source of action |
Example 3 | see #source of action |
Motivation
[edit]source (Q31464082) and recipient (Q20820253) are fundamental thematic roles in transfers (i.e., processes where an item starts off associated with one entity and becomes associated with another), and we do not currently have a simple way to express them. The only existing approach is to assign sources/recipients as values of participant (P710), uses (P2283), has part(s) (P527), or another property, and then to qualify those statements with object has role (P3831). participant (P710) is currently limited in scope to "person[s], group[s] of people or organization[s]", and uses (P2283) and has part(s) (P527) are vague and ill-suited to these roles. This approach is awkward and inconsistently used on main statements, and does not work at all when a source or destination is given by a qualifier.
We currently have some properties for specific types of transfers, such as addressee (P1817) for correspondence and start point (P1427) and destination point (P1444) for travel. The proposed properties would take those as sub-properties, while generalizing to all types of transfers, including physical, digital, legal, etc. (Note: although transfers may involve a wide variety of relations, including physical possession/containment, inclusion as a part, ownership, employment, etc., that does not mean the scope of the proposed properties is unlimited: values of "source" and "destination" must fulfill those thematic relations in context. In other words, there must be an item that is initially associated with the "source", and that comes to be associated with the "destination" in the same way, as a result of the process described by the subject.)
The item being transferred may be specified with uses (P2283) where necessary (leaving open the possibility of a future property for the thematic role of "item transferred"). It should be noted that the source of a transfer is not necessarily the cause of the transfer.
@Push-f, The-erinaceous-one, ZI Jony: Pinging based on participation in the last proposal; SM5POR already expressed intent to sit this one out.
Swpb (talk) 19:15, 17 April 2024 (UTC)
(By the way, there is another active proposal, "Event role", that seeks to link all sorts of events to the roles therein. The present proposal seeks to link transfers (a specific type of event) to the entities that occupy the specific roles (inherent to transfers) of source and destination. So these proposals are not competing, and are in fact complimentary. Swpb (talk) 20:31, 17 April 2024 (UTC))
Discussion
[edit]- Support seems sensible. Although uses (P2283) to model the thing transferred is a bad idea in my opinion, as it mixes the end and the means. To me "uses (P2283) " could be used to denote the mean, such as "electronic network" and the things being exchanged should have its own property. author TomT0m / talk page 19:24, 17 April 2024 (UTC)
- Yeah, agree that should have it's own property, but I didn't want to complicate this proposal. Could add that to the proposal if you think it would help get this through. Swpb (talk) 20:31, 17 April 2024 (UTC)
- Generally, this looks good. Where I'm unsure is whether all items where this is used should be of some "transfer" class. ChristianKl ❪✉❫ 21:45, 20 April 2024 (UTC)
- @ChristianKl: Like transfer (Q125506646)? That is my intent. If we constrained the subject class to that, would you support the properties? Swpb (talk) 15:28, 22 April 2024 (UTC)
- Yes, like that. As far as I out of the examples only data import into Wikidata (Q107661232) subclasses it and the examples currently do not subclass transfer (Q125506646). Before we creating this property it would make sense to change the subclass tree of the examples to subclass transfer (Q125506646) and see whether that goes well or causes problems. ChristianKl ❪✉❫ 18:10, 22 April 2024 (UTC)
- @ChristianKl: Like transfer (Q125506646)? That is my intent. If we constrained the subject class to that, would you support the properties? Swpb (talk) 15:28, 22 April 2024 (UTC)
- Easy:
- 1. pitch (Q1063937) → throwing (Q12898216)subclass of (P279)transfer (Q125506646)
- 2. Alaska Purchase (Q309029)instance of (P31)selling (Q3380760) (→ financial transaction (Q1166072) → transfer (Q125506646))
- 3. radio broadcast (Q64707203) → ... → information exchange (Q6031064)subclass of (P279)transfer (Q125506646)
- Swpb (talk) 19:42, 22 April 2024 (UTC)
- It mixes physical transfers and logical one, could be an issue if we are not careful. parent class tree. It's currently both a subclass of "spatio-temporal entity" (something physical) and "non-physical entity", a contradiction. I'm surprised it's not found as a disjointness violation. author TomT0m / talk page 20:43, 22 April 2024 (UTC)
- transfer (Q125506646) is not a subclass of abstract entity (Q7048977). It is supposed to include both physical and "logical" (e.g. information, legal) transfers; this does not create a contradiction. Swpb (talk) 20:28, 23 April 2024 (UTC)
- @ChristianKl:, would you like to give your opinion based on the response? Regards, ZI Jony (Talk) 06:40, 26 April 2024 (UTC)
- I waited some to see whether other people have more input, but I Support it in the current state. ChristianKl ❪✉❫ 21:02, 28 April 2024 (UTC)
- @ChristianKl:, would you like to give your opinion based on the response? Regards, ZI Jony (Talk) 06:40, 26 April 2024 (UTC)
- transfer (Q125506646) is not a subclass of abstract entity (Q7048977). It is supposed to include both physical and "logical" (e.g. information, legal) transfers; this does not create a contradiction. Swpb (talk) 20:28, 23 April 2024 (UTC)
- It mixes physical transfers and logical one, could be an issue if we are not careful. parent class tree. It's currently both a subclass of "spatio-temporal entity" (something physical) and "non-physical entity", a contradiction. I'm surprised it's not found as a disjointness violation. author TomT0m / talk page 20:43, 22 April 2024 (UTC)
- Easy:
- @Swpb, TomT0m, ChristianKl, Push-f, The-erinaceous-one: Done as source of transfer (P12693) and destination of transfer (P12694). Regards, ZI Jony (Talk) 13:54, 3 May 2024 (UTC)
- Thanks! Swpb (talk) 20:50, 4 May 2024 (UTC)