Wikidata:Property proposal/creator name string

creator name string edit

Originally proposed at Wikidata:Property proposal/Creative work

Withdrawn

Description	string to store unspecified creator name for artworks; use if Wikidata item for creator (P170) does not exist or is not known
Data type	String
Domain	Artworks, at least initially
Example 1	Q55767840 → "Prohovnikov, P."
Example 2	Q56460643 → "Tuisk, A."
Example 3	Q50378233 → "Viski, J."
Example 4	Q51051528 → "Vološin, M."
Planned use	Import the name strings for Estonian paintings we don't yet have an author item for
See also	author name string (P2093), creator (P170)

Motivation edit

Talk on IRC and here has convinced me it makes sense to propose this. It's supposed to be an equivalent to author name string (P2093) for cases where the appropriate property replacement is not author (P50) but creator (P170). At Wikimedia Eesti‎ (Q12379207) we've been working into importing paintings in Estonian museum collections and have found quite a few cases where the name string and info provided is not enough to identify the creator. While in some cases we can just create an item for the creator using the string (mostly when there's a full name provided and it doesn't match anything already on WD), in many cases there's no good option: we can not indicate a creator, create a possible duplicate without enough info to easily identify it, or use author name string (P2093) which will make bots and even users think the string should be replaced with author (P50) if the creator is identified. Having a more generic property for creator (P170) (and possibly marking author name string (P2093) as subproperty of (P1647) of it) seems to be an improvement over all three of the options. Reosarevok (talk) 17:38, 4 February 2019 (UTC)[reply]

Discussion edit

WikiProject sum of all paintings has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead.

Support David (talk) 06:55, 5 February 2019 (UTC)[reply]
Support author name string (P2093) has been extremely useful to have as an interim property (at least). So this sounds useful by analogy. ArthurPSmith (talk) 19:57, 5 February 2019 (UTC)[reply]
Support - PKM (talk) 04:11, 6 February 2019 (UTC)[reply]
~~{{s}} per what I've written already.~~
Oppose per further discussion below. --Marsupium (talk) 04:16, 6 February 2019 (UTC), 01:40, 14 February 2019 (UTC)[reply]
Support Germartin1 (talk) 14:35, 9 February 2019 (UTC)[reply]
Support I've wanted this for a while Lewis Hulbert (talk) 16:23, 9 February 2019 (UTC)[reply]
Oppose Use creator (P170) = somevalue with qualifier object named as (P1932) = <string>, the same as we do for other properties (other than author) where there is no item but we want to record a string. Jheald (talk) 20:39, 11 February 2019 (UTC)[reply]
- @Jheald: Oh, interesting and good point! Where exactly is this used? --Marsupium (talk) 07:21, 12 February 2019 (UTC)[reply]
  - I personally have used it for publisher (P123) where we don't have an item for the publisher, or there's not been a straightforward identifiable match. Others may have used it for other properties. Jheald (talk) 11:02, 12 February 2019 (UTC)[reply]
    - The approach mentioned by Jheald is quite often used if for a person no item exists and not enough information are available to create a new item. For example for editor (P98) [1], cast member (P161) [2] or child (P40) [3]. I personally prefer this approach because it can be applied to all properties. --Pasleim (talk) 13:10, 12 February 2019 (UTC)[reply]
@Reosarevok: what do you think of the above solution mentioned by Jheald? Can you try it and see if this is acceptable? It does seem a reasonable approach. ArthurPSmith (talk) 17:19, 12 February 2019 (UTC)[reply]
@Jheald: This approach sounds reasonable - why isn't the same done for author name string (P2093) then though? Is there a drawback I'm not currently seeing? Reosarevok (talk) 08:15, 13 February 2019 (UTC)[reply]
- I assume simply historical inertia. We do have at least tens of millions of author name string (P2093)'s now so you could argue it deserves a unique property from the extent of need/use. ArthurPSmith (talk) 18:35, 13 February 2019 (UTC)[reply]
  - Author name string is also used as a qualifier see example. Multichill (talk) 20:12, 18 February 2019 (UTC)[reply]
- (ec) Only, for these cases where P170 is needed as a qualifier it's not so clean to put object named as (P1932) as a parallel qualifier, but should work anyway. --Marsupium (talk) 01:40, 14 February 2019 (UTC)[reply]

@Multichill as potential user: You have any opinion here? You're probably the one dealing with the most cases of this problem. :-) Would you consider to convert your system hitherto to one of the two proposed solutions? @Jarekt: as participant in the related earlier discussion. Maybe you two have any considerations as well? Thanks, --Marsupium (talk) 01:40, 14 February 2019 (UTC)[reply]
Neutral I have seen a lot of author name string (P2093) properties, but have never seen the solution using object named as (P1932) proposed by Jheald. I like object named as (P1932) solution, although it would not work for properties used as qualifiers, but creator is rarely used as qualifier so that would not be an issue. One advantage of new property would be that I like similar solutions for similar issues and creator name string would be for creator (P170) what author name string (P2093) is for author (P50). But than we might need architect, published, illustrator, translator, etc. strings as well. So I am undecided. --Jarekt (talk) 03:23, 14 February 2019 (UTC)[reply]
Weak oppose so I've imported quite a few paintings here and also ran into the problems of not very well described persons. So I ended up having to create quite a few not so complete items. Quite a few of these items ended up being expanded or merged (yah for watchlist). That wouldn't ever have happened if it was just hiding in some string property. If you really want to do it, Jheald's suggestion seems to cover your case best. Multichill (talk) 20:12, 18 February 2019 (UTC)[reply]

As Multichill says, creating items for the people has benefits, even for people where it may seem that there is next to nothing that one can say. But IMO being able to add just the string either via "author name string" or "stated as" can be a useful staging-post for a complicated upload. It means one can get items for the objects uploaded on the basis a decent first pass at creator/author matching, and then come back and do a really solid job of trying to match the remaining authors, or research them and create items for them, as a second stage of the process. Being able to split up a data upload into stages like this I do find can be quite helpful. The danger is I may get distracted to something else, and the "stated as" strings may never get worked on. That can happen and it's not ideal. But it's not the end of the world, and at least the strings are there for somebody else to take up, if they feel inspired. And possibly if the only thing we know about someone is e.g. that their name appeared on one drawing once, with nothing else known about them, and no other works known anywhere, then I can see the sense in Multichill's advice to make an item, but just leaving it as "stated as" may not be such a great loss. Just my 2 cents, anyway. Jheald (talk) 22:12, 18 February 2019 (UTC)[reply]

I actually do it in two stages most of the time. First stage imports most metadata and leave the painter information in the description as "painting by <some person>" example. Based on that another bot comes along. https://tools.wmflabs.org/multichill/painters/index.php?collection=Q1505892 is also based on this. Multichill (talk) 10:32, 19 February 2019 (UTC)[reply]

Comment I would prefer subject named as (P1810) over object named as (P1932) as it is not sure that the name is the original way it was written, but the preferred name in the collection system. --Hannolans (talk) 19:58, 22 February 2019 (UTC)[reply]

I guess it makes sense to try what Jheald suggested then! :) --Reosarevok (talk) 13:58, 23 February 2019 (UTC)[reply]

@Reosarevok: You want to withdraw the proposal then? --Marsupium (talk) 12:00, 11 March 2019 (UTC)[reply]

Thought that was obvious from context! Yeah, at least until there's a clear reason why the other approach doesn't work --Reosarevok (talk) 15:04, 11 March 2019 (UTC)[reply]

Weak oppose given creator is mainly used in the field mentioned by Multichill, I'd proceed as he suggested. --- Jura 09:04, 24 February 2019 (UTC)[reply]