Wikidata:Property proposal/address of addressee
address of addressee
editOriginally proposed at Wikidata:Property proposal/Generic
Not done
| Description | address of the address e.g. on a postcard |
|---|---|
| Data type | Monolingual text |
| Example 1 | A trip to Meissen (Q92739714)address of addresseeLeipziger Straße 57 |
| Example 2 | Ausstellungspalast (Q109104529)address of addresseeBerliner Straße 24 |
| Example 3 | Q109106149address of addresseeTilsiter Straße 41 |
| Planned use | I plan to use the property for the WikiProject Postcards on Commons |
Motivation
editThe motivation of this proposal is to capture the data of backsides of postcards via SDC on Wikimedia Commons. So this property is thought to be mainly used as structured data on Commons, but can also be used for other items on Wikidata. The idea was first discussed here. The property should be used in combination with the properties street, housenumber, point in time and coordinate location. --CuratorOfThePast (talk) 11:24, 16 May 2024 (UTC)
Discussion
edit
Oppose When it comes to the name of the sender of a post card, I would say that the sender is the author (P50) of the post card. The property for the addressee on the other hand is addressee (P1817). If we don't have a Wikidata item for either you can use unknown value Help with subject named as (P1810).- We have street address (P6375) that could be used as a qualifier on author (P50)/addressee (P1817). I don't see a need for a new property. ChristianKl ❪✉❫ 13:29, 16 May 2024 (UTC)
- I'm not a super big fan of using author (P50) for something like this because it can be confused with the postcard publisher, illustrator/photographer of the postcard, Etc. Etc. In otherwards there's nothing inherent to "author" that makes it relate to the person who wrote the message on the card. Which is kind of the point. I think that's made clear by the fact that "also known as" includes terms like "maker" and "creator." So it would be cool if there was a property specifically for the writer of the message on the postal item instead of us just forcing us to use one that's so general it's essentially meaningless. Personally, I'd like to see separate properties for "sender", "sender address", "receiver", and "receiver address." I don't think addressee (P1817) alone really cuts it. --Adamant1 (talk) 21:19, 16 May 2024 (UTC)
- The description for addressee is "person or organization to whom a letter or note is addressed". How is that different from "receiver"? What issue do you see with using street address (P6375) as a qualifier? I think there's value to having a standardized way within Wikidata to specify an address.
- I see the argument for a separate property for sender. ChristianKl ❪✉❫ 09:45, 17 May 2024 (UTC)
- @ChristianKl: I guess it's semantics or how American English works but "addressee" isn't a super intuitive word. I think that's reflected in Google Search results for the term though. "People also ask: "Is the addressee the sender or receiver?", "What is the difference between addressee and address?" Etc. Etc. I guess it doesn't really matter, something being standardized also kind of insinuates it's universally understandable. --Adamant1 (talk) 23:56, 17 May 2024 (UTC)
- When it comes to the decision about whether or not to create new properties, it's important to look at the actual property. To the extend that a name of a property is hard to understand, the solution would be to change the name and not to create another property for the same content with a different name. ChristianKl ❪✉❫ 00:01, 18 May 2024 (UTC)
- That's understandable. Although I wouldn't think its good to change the name of a property on a dime either. But then what would be the name of a comparable property to it for the address of the person sending the postal item, Addresser? Author address?--Adamant1 (talk) 05:08, 18 May 2024 (UTC)
- Yes, changing the name of properties on a dime either. That's why it's generally important to put a lot of thought into creating new properties and don't create them willy-nilly.
- As I said above,there's no good reason to have a property for "address of the person sending the postal item" and for the person receiving it. street address (P6375) used as qualifier does the job. ChristianKl ❪✉❫ 09:12, 18 May 2024 (UTC)
- @ChristianKl: Not to argue about it but if you look at the "Also known as" terms for street address (P6375) they include "address", "mailing address", "postal address" Etc. Etc. and the description simply says "full street address where subject is located." What we want here is a way to include both the sender and receiver's addresses as separate properties and there's nothing inherent to the term "subject" or "address" that says street address (P6375) is inherently (or exclusively) about the "address of the person sending the postal item." Essentially all I'm asking for in the meantime is that ""mailing address" be separated from the (clearly ambiguous) property for "address." And sure we could just use street address (P6375) for mailing address, but I'm telling as someone who has worked in the area for years on Commons that it doesn't work for what we want. Since "full street address where subject is located" can be either the address of the sender or receiver depending on the situation and we need something more specific. --Adamant1 (talk) 00:33, 19 May 2024 (UTC)
- If you would use A trip to Meissen (Q92739714)street address (P6375)Leipziger Straße 57, that would be ambiguous. On the other hand if you use it as a qualifier and say A trip to Meissen (Q92739714)addressee (P1817)unknown value Help
street address (P6375)Leipziger Straße 57 there's no ambiguity. - It's worth noting here that if the postcards are notable enough to be saved and a person receives multiple postcards in many cases it will be good to have an item for that person, so that unknown value Help is not needed. ChristianKl ❪✉❫ 12:18, 19 May 2024 (UTC)
- But this way is not sufficient if your regular postcard is still notable but doesnt have a notable person on it. Still the person could be named more than once on a postcard. This will result in having many unknown values with no future intention of creating an corresponding item. I feel like this is against the intention of unknown values. It would be better in that case to use a suitable property for capturing data of the address sides of postcards. Also a dedicated property would a allow a straight forward query etc. of the data. This is now for some reason not possible. By the way I added a bunch of postcards with addressee and named as as qualifier and they do not show up in the query for the property for addresee: (Example) CuratorOfThePast (talk) 12:27, 22 May 2024 (UTC)
- This is not against the intention of unknown values. The documention explicitely says "Unknown value may also mean the value is a known object, but that there's currently no Wikidata item about the object. However, in this case it is strongly recommended to create an item for the object, if it meets the notability policy."
- With the two expectation of author name string (P2093) and affiliation string (P6424). In those case we speak about tens of millions of items. If you say this will result in many such values, do we really have hundred of thousands items that fall under these criteria in commons? I would have guessed that we are talking here about a few thousand files which is not a significant amount? ChristianKl ❪✉❫ 17:42, 22 May 2024 (UTC)
- There's currenty around 400,000 images of postcards on Commons that have been categorized, about 20,000 more that we know of, and whatever number hasn't been found yet. admittedly we don't have images of the backsides to a lot of those and not all of the ones that we have images of them for are mailed, but there's got to be more them just a few thousand that are and I'd like to extend this to other postal items if its possible. Tangential to that, but it would at least be good if there was a solution to "addresee" not showing up in search queries if this doesn't end up going anywhere. Otherwise the whole thing just seems kind of pointless. Adamant1 (talk) 10:31, 23 May 2024 (UTC)
- But this way is not sufficient if your regular postcard is still notable but doesnt have a notable person on it. Still the person could be named more than once on a postcard. This will result in having many unknown values with no future intention of creating an corresponding item. I feel like this is against the intention of unknown values. It would be better in that case to use a suitable property for capturing data of the address sides of postcards. Also a dedicated property would a allow a straight forward query etc. of the data. This is now for some reason not possible. By the way I added a bunch of postcards with addressee and named as as qualifier and they do not show up in the query for the property for addresee: (Example) CuratorOfThePast (talk) 12:27, 22 May 2024 (UTC)
- If you would use A trip to Meissen (Q92739714)street address (P6375)Leipziger Straße 57, that would be ambiguous. On the other hand if you use it as a qualifier and say A trip to Meissen (Q92739714)addressee (P1817)unknown value Help
- @ChristianKl: Not to argue about it but if you look at the "Also known as" terms for street address (P6375) they include "address", "mailing address", "postal address" Etc. Etc. and the description simply says "full street address where subject is located." What we want here is a way to include both the sender and receiver's addresses as separate properties and there's nothing inherent to the term "subject" or "address" that says street address (P6375) is inherently (or exclusively) about the "address of the person sending the postal item." Essentially all I'm asking for in the meantime is that ""mailing address" be separated from the (clearly ambiguous) property for "address." And sure we could just use street address (P6375) for mailing address, but I'm telling as someone who has worked in the area for years on Commons that it doesn't work for what we want. Since "full street address where subject is located" can be either the address of the sender or receiver depending on the situation and we need something more specific. --Adamant1 (talk) 00:33, 19 May 2024 (UTC)
- That's understandable. Although I wouldn't think its good to change the name of a property on a dime either. But then what would be the name of a comparable property to it for the address of the person sending the postal item, Addresser? Author address?--Adamant1 (talk) 05:08, 18 May 2024 (UTC)
- When it comes to the decision about whether or not to create new properties, it's important to look at the actual property. To the extend that a name of a property is hard to understand, the solution would be to change the name and not to create another property for the same content with a different name. ChristianKl ❪✉❫ 00:01, 18 May 2024 (UTC)
- @ChristianKl: I guess it's semantics or how American English works but "addressee" isn't a super intuitive word. I think that's reflected in Google Search results for the term though. "People also ask: "Is the addressee the sender or receiver?", "What is the difference between addressee and address?" Etc. Etc. I guess it doesn't really matter, something being standardized also kind of insinuates it's universally understandable. --Adamant1 (talk) 23:56, 17 May 2024 (UTC)
- I'm not a super big fan of using author (P50) for something like this because it can be confused with the postcard publisher, illustrator/photographer of the postcard, Etc. Etc. In otherwards there's nothing inherent to "author" that makes it relate to the person who wrote the message on the card. Which is kind of the point. I think that's made clear by the fact that "also known as" includes terms like "maker" and "creator." So it would be cool if there was a property specifically for the writer of the message on the postal item instead of us just forcing us to use one that's so general it's essentially meaningless. Personally, I'd like to see separate properties for "sender", "sender address", "receiver", and "receiver address." I don't think addressee (P1817) alone really cuts it. --Adamant1 (talk) 21:19, 16 May 2024 (UTC)
Not done, no consensus of proposed property at this time based on the above discussion. Regards, ZI Jony (Talk) 06:35, 5 July 2024 (UTC)
