Jump to content

Wikidata:Project chat: Difference between revisions

Shortcuts: WD:PC, WD:CHAT, WD:?
From Wikidata
Browse history interactively
← Older editNewer edit →
Content deleted Content added
VisualWikitext
M2k~dewiki (talk | contribs)
4,247,354 edits
Line 455: Line 455:


Thanks a lot! [[User:M2k~dewiki|M2k~dewiki]] ([[User talk:M2k~dewiki|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 14:45, 25 January 2023 (UTC)
Thanks a lot! [[User:M2k~dewiki|M2k~dewiki]] ([[User talk:M2k~dewiki|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 14:45, 25 January 2023 (UTC)

== The first version of the new Wikibase REST API is now available on Wikidata ==

Hi everyone,

We are working on making it easier to use Wikidata's data to build applications. A big part of that is a better API. Over the past months we have been developing the first version and gotten testing and feedback for it. Last week we made it available on test.wikidata.org. Today the first version of the new Wikibase REST API is available on Wikidata. I'd like to thank everyone who helped along the way by providing feedback and testing.

You can find more information on what you can already do with the new Wikibase REST API at [[Wikidata:REST API]].

We will continue to build out its functionality and your input on what would be most useful for you will help prioritize the next steps. Please leave your thoughts on the [[Wikidata talk:REST API feedback round#The_Wikibase_REST_API_is_now_available_on_Wikidata_(January_2023)|feedback page]].


Cheers [[User:Lydia Pintscher (WMDE)|Lydia Pintscher (WMDE)]] ([[User talk:Lydia Pintscher (WMDE)|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 15:29, 25 January 2023 (UTC)

Revision as of 15:29, 25 January 2023

Edit


Linking external images with an url

How do I do that? Like with external 360 deg pano images. I like to add images to venues. Because no text describes a location like an image. The offerings from wikimedia are sometimes ok, but often there is nothing. Or its dated. On the other hand there are always good high qulity pictures of venues by the venues which are made to be public and freely used. They are just not on wikimedia for different reasons. How to add them via urls to Wikidata? Thats something that would improve the description of a venue a lot. I'm looking for something like: 

image_url: url
external_image_url: url
image_resource: url
press_image: url

Sources would be something like Flickr or press photos offered by a venue on their website. Example: here from this page. I'm new. Am I missing something? There are a few ways to link external text with an url. But no way for images? Why is that? Thanx.

I think it is not suitable for wikidata for several reasons. Yet, it has been proposed before. --Christian140 (talk) 12:43, 17 January 2023 (UTC)[reply]
I understand and agree to some of this. What about restrictions? For examples images which are clearly described as for public consumption by the issuer. Like press images. What about a restriction to certain big image providers like flickr_image_url? They have their own spam protections. I think its bad policy to say: There will be problems with images, so we don't allow ANY urls, except if they are 360 degress. Which imho doesnt make that much sense. There is also some spam in panoramas. And what about a wikimedia image urls database? You have to first add the url to the "wikimedia image url database", and if it's kept there - with whatever restrictions und rules you like - you can use it in wikidata. if the url is deleted in wikimedia, its deleted in wikidata? Databob (talk) 13:51, 17 January 2023 (UTC)[reply]
@Databob: What's the motivation of not licensing press images under an open license? It's to shut down criticism that uses the press images. Press images for public consumption should be licensed under an open license. Our policy creates incentives for doing so.
If you see a press image that you want to include, you can sent the publisher an email: "Hey, I want to include your image on Wikidata and WikiCommons. For that your image would have to be published under an open license, can you please publish it under an open license?"
If the venue truly intends the images to be freely used, the might appreciate your efforts to help their images to be seen more broadly by licensing the image accordingly. If they don't want their images to be freely used, they won't. ChristianKl ❪✉❫ 14:15, 22 January 2023 (UTC)[reply]
@ChristianKl: The reasons I can think of: 1. They venue has no clue that their PR photos can not be used everywhere unless they upload it to Wikimedia. 2. The photographer - not the venue - of the fotos doesn't allow an open license for his work, even if if the venue payed for it. My first thought was yours: Email them and ask them to upload their PR photos to Wikimedia. My second thought was: All of them? There must be a better solution.
That the venues don't open the photos because they are afraid they might be used against them? I don't understand that.

Pubblication date

Hello to community!

In the Wikipedia pages, for call software version identifier (P348), is used {{#property:P348}}. What I should write, to call publication date (P577)?

Many thanks in advance!!! 2001:B07:6442:8903:4C3B:695B:B4BB:4B7C 11:35, 10 January 2023 (UTC)[reply]

Have you tried {{#property:P577}}? Vojtěch Dostál (talk) 18:18, 10 January 2023 (UTC)[reply]
@Vojtěch Dostál: yes, but do not work since publication date (P577) is a qualifier of software version identifier (P348), not a statement. --2001:B07:6442:8903:E58D:7411:B1F3:CFA9 08:52, 11 January 2023 (UTC)[reply]
You'll probably have to use a Lua module for that. Which Wikipedia language version are you working on? Vojtěch Dostál (talk) 11:51, 11 January 2023 (UTC)[reply]
@Vojtěch Dostál: japanese --93.34.224.108 14:08, 11 January 2023 (UTC)[reply]
Best to ask on Japanese Wikipedia, then. It is difficult for me to understand the templates in Japanese Wikipedia due to the language and script barrier. Sorry. Vojtěch Dostál (talk) 16:14, 16 January 2023 (UTC)[reply]
You can use Lua to get qualifiers. Here's the documentation page: [1]. D6194c-1cc (talk) 21:04, 23 January 2023 (UTC)[reply]
It looks like you have simpler option, use ja:Template:Wikidata. Infrastruktur (talk) 06:08, 24 January 2023 (UTC)[reply]

Linking to Outreach wiki not an option

Linking to Outreach wiki is not an option among Multilingual sites of Wikidata items... Is there a (special) reason for this? Any other way to do it? --Zblace (talk) 18:40, 12 January 2023 (UTC)[reply]

I think the decision whether to promote a Wiki to be official in the sense that it's interlinked was historically done by the WMF. ChristianKl ❪✉❫ 20:44, 13 January 2023 (UTC)[reply]
phab:T171140.--GZWDer (talk) 14:53, 14 January 2023 (UTC)[reply]
That does seem like it's just an undone task. @Lydia Pintscher (WMDE):? ChristianKl ❪✉❫ 15:29, 17 January 2023 (UTC)[reply]
Mpfh. Indeed. Someone forgot to coordinate with us. I'll have a closer look what's missing. Lydia Pintscher (WMDE) (talk) 10:24, 22 January 2023 (UTC)[reply]

Watercourse distance

Most waterways distance are not referenced, which is not a problem since they can easily be checked on a map. Now, user:Fralambert is given the mission to depreciate their lengths if not referenced, which I consider a disorganization. Any advise to solve this ? Yanik B 13:20, 16 January 2023 (UTC)[reply]

Has this already been discussed somewhere? ---MisterSynergy (talk) 13:48, 16 January 2023 (UTC)[reply]
It is discussed at User_talk:Fralambert#Dépréciation. @Fralambert: is wrong to deprecate these statements. Deprection, per Help:Ranking is "used for statements that are known to include errors (i.e. data produced by flawed measurement processes, inaccurate statements) or that represent outdated knowledge (i.e. information that was never correct, but was at some point thought to be)." This is not the case with unreferenced river lengths. I don't think there is general support on WD for deprecating nor removing statements with no reference and I'm unaware of any specific support for this watercourse action. So "If there is no source for a length, I depreciate, period. No more complicated than that." is all of pointy, wrong and uncollegiate. --Tagishsimon (talk) 14:05, 16 January 2023 (UTC)[reply]
Should I delete them instead? Since they most of them seem to be original research. What I ask is for a source, nothing else. Just note that all these deletions [2], [3] or [4] come from @YanikB, not me. Fralambert (talk) 23:50, 16 January 2023 (UTC)[reply]
If you doubt them, it would sense to actually check whether the values are correct. If there's a pattern of most unsourced waterways distance being frequently wrong that might be ground to do something. In the absence of such a pattern being established the norms of Wikidata neither allow for decprication nor removal just because someone didn't provide a source. ChristianKl ❪✉❫ 22:41, 21 January 2023 (UTC)[reply]
Ok, I restore all the lenghts of Rat River (Q11984856) [5], the sourced ones, the unsurced ones, and even the one modified by @YanikB here. Just if you exclude the one of the total lenght of streems of the watersheed, their is a difference of 88 km between the smallest and the biggest values. That is a 67% of difference, that is a lot. And this is why you need reliable source. Fralambert (talk) 14:25, 22 January 2023 (UTC)[reply]
There are several possible lengths for a stream: the distance between the main source and the mouth; the distance between the farthest source and the watershed mouth; and sometimes the total length of the watershed’s streams. Ideally, the last two should be on the watershed element, however, if there is no watershed element, we can qualify the lengths and put a preferred rank on a length other than the one without qualifiers (the distance, following the course, between the main source identified on a map and the mouth). No need to devalue a volunteer’s work. --Yanik B 14:48, 22 January 2023 (UTC)[reply]
If the lenght are from your own calculation, it would be useful to use determination method or standard (P459) as a qualifier and observed in (P6531) : Toporama (Q56419922) as a the source. Not sure this is the best solution, but at least this is a source. Fralambert (talk) 15:13, 22 January 2023 (UTC)[reply]
I don’t use the Toporama calculation tool, I rely on the layout provided by Canvec on OpenStreetMap. --Yanik B 16:08, 22 January 2023 (UTC)[reply]
Then cite that you use CanVec [6] (we don't have a item for it, we should probably create it.), OSM orCRHQ. It's not that hard [7]. Fralambert (talk) 16:22, 22 January 2023 (UTC)[reply]
Find. Now, how can we specify that a length applies to the coordinates given in coordinate location (P625) ? --Yanik B 17:36, 22 January 2023 (UTC)[reply]
If you want to calculate it from the other statements on Wikidata, inferred from (P3452) is there for that. ChristianKl ❪✉❫ 19:31, 22 January 2023 (UTC)[reply]

Bot needed

Where we have instance=human and there is no description, can we have a bot fill in birth and death years in parenthesis as the description? I keep creating duplicate items, but if there was a minimal description, it would be obvious we have a variation of the name of that human already. RAN (talk) 20:48, 16 January 2023 (UTC)[reply]

doing this has caused controversy in the past. really this ought to be a feature of wikibase. BrokenSegue (talk) 21:26, 16 January 2023 (UTC)[reply]
It ought not to be controversial. If there is no description currently, then any accurate description is an improvement, no? — Martin (MSGJ · talk) 23:43, 16 January 2023 (UTC)[reply]
Some bots that currently add descriptions only add a description when the description field is empty. If you create a very minimal description than those bots would be stopped from adding a better description.
WikiFunctions moved in August into beta. I'm hoping that in the future it will be able to do the job of providing Wikidata descriptions. ChristianKl ❪✉❫ 16:09, 17 January 2023 (UTC)[reply]
'fraid I cannot buy this really this ought to be a feature of wikibase thing. First, it is perfect is the enemy of good. It'd seem to involve changes to the main UI, all APIs, the SPARQL engine and/or the triplestore; and I don't find it credible that anyone would prioritise that scale of change to do something that a pedestrian bot is capable of doing. Second, even were work to be done on this, I'm pessimistic anything would be delivered in a meaningful timescale. Third, it seems to have a perverse driver - the controversy over the pattern to be adopted for human item labels. Unclear why exactly the same controversy would not attach to it. It's depressing af that there's resistance on WD to the use of a standard pattern to include dob & dod where there is no ambiguity attached to either of those dates, but there we are; there's no accounting for folk. --Tagishsimon (talk) 23:23, 20 January 2023 (UTC)[reply]
I’m not sure about your third point: Are you suggesting that the debate would shift from “should manual descriptions contain life dates” to “should automatic descriptions contain life dates“? Because I don’t think so. --Emu (talk) 23:58, 20 January 2023 (UTC)[reply]
Weird that you oppose bots adding dob and dod, but would be alright with automatic descriptions including them. --Tagishsimon (talk) 00:14, 21 January 2023 (UTC)[reply]
the argument is that duplicating the DOB/DOD information leads to problems. it goes against the spirit of structuring the information. if the descriptions are automatic it's no problem. i'm honestly on the fence on this one. BrokenSegue (talk) 01:37, 21 January 2023 (UTC)[reply]
Exactly, thank you for summarizing the problem. --Emu (talk) 20:08, 21 January 2023 (UTC)[reply]

Request for assistance from anyone who speaks Czech and/or Polish

I'm trying to merge catechist (Q1735732) and catechist (Q11737267), because I believe they are both the same concept. I can't, because of conflicting Czech and Polish language links – cs:Katecheta vs cs:Katechista and pl:Katecheta vs pl:Katechista. Now, from what I understand, kaecheta in both Czech and Polish actually means catechist, so belongs as a link to the merged article; however, katechista in both means catechesis, and hence belongs on catechesis (Q1735729) instead. The problem is, the later is already linked to cs:Katecheze and pl:Katecheza. So, here's what I can't work out – in English, we have a distinction between catechesis (the field of Christian religious education) and catechist (a person who practices in that field). Whereas, in Czech and Polish, we seem to have not two words, but three: katecheta, katechista, and katecheze/katecheza – and I can't understand what the distinction between the three is. I take it, like English, one must be the field and the other a person who practices it, but what then is the third? Can anyone who understands Czech and/or Polish help here? SomethingForDeletion (talk) 21:59, 16 January 2023 (UTC)[reply]

In Czech (and probably also in Polish) catechist (Q11737267) is brader term and catechist (Q1735732) is only pedagogue. Cite from czech article: Technically, there is a difference between a catechist (Q1735732) in Czech - the one who prepares and leads catechesis, and a catechist (Q11737267) - the one who is legally authorized to grant baptism. JAn Dudík (talk) 21:01, 17 January 2023 (UTC)[reply]
Thanks User:JAn Dudík. But how to represent this in English–or most other languages–where the distinction does not exist? I am thinking the broader term (Q11737267 you say) is likely the equivalent in most other languages, and Q1735732 is some narrower concept which may only exist in Czech or Polish. What do you think? SomethingForDeletion (talk) 08:33, 24 January 2023 (UTC)[reply]

Automated way to upload a single entry in Findagrave?

I have creating entries in Wikidata for identified people at Commons in historic images. It would be great when I find the person at Findagrave, if I could just import that one entry into Wikidata. Do we have a mechanism in place already? RAN (talk) 23:28, 16 January 2023 (UTC)[reply]

@Richard Arthur Norton (1958- ) I suggest to create a corresponding Mix'n'Match catalogue. Vojtěch Dostál (talk) 09:35, 17 January 2023 (UTC)[reply]
New-Q5 tool is not fully automated, but it expedites the process of creating (or editing) items for humans. Pasting the birth/death dates and the URL from a Find a Grave profile (or WikiTree, or obituary, or any URL) reduces some of the tedious, repetitive steps. -Animalparty (talk) 18:25, 17 January 2023 (UTC)[reply]
@Animalparty Is there instructions or an example of this tool's use?
Thanks, -- Ooligan (talk) 20:28, 21 January 2023 (UTC)[reply]
Ooligan To my knowledge, no, aside from the GitHub documentation page. But it's fairly simple to play around with. Entering a name and (optionally) a date of birth and/or death, along with (optionally) a URL spits out a script that can be modified or run directly in QuickStatements. It sometimes automatically detects existing items with similar names (especially if the existing items lack birth/death dates), but not always: to add dates with nicely formatted reference to an existing item, I just replace "LAST" with the QID and remove "CREATE" before clicking Import QuickStatement (the script can be further modified as needed, e.g. removing the last line will prevent the addition of described at URL (P973), which is useful for reducing redundancy for for URLs that have corresponding external IDs like Find a Grave memorial ID (P535) and IMDb ID (P345)). And I always double check the item after creation to ensure things make sense (e.g. a woman's maiden surname may be recorded as a second given name, or the tool may choose the wrong name and infer the wrong gender based on homonymous names like José (Q66827836) vs. José (Q2190619)). Sometimes I just add a dummy date to get a nicely formatted, referenced statement that I can then use to source other properties (spouse, birthplace, etc.). -Animalparty (talk) 21:08, 21 January 2023 (UTC)[reply]
@Animalparty I understand the tool much better. Thank you for your very detailed response and your time. -- Ooligan (talk) 21:30, 21 January 2023 (UTC)[reply]

Personification (Q207174) statement

I think there should be a personification (Q207174) statement for example:

United Kingdom (Q145) -> Britannia (Q138396)

Berlin (Q64) -> Berolina (Q574396)

Scheldt (Q37620) -> Scaldis (Q116234451) Jhowie Nitnek 14:13, 17 January 2023 (UTC)[reply]

There is national personification (Q1142281) used with a qualifier. I think that works well enough, I don't think we need another property Vicarage (talk) 14:53, 17 January 2023 (UTC)[reply]
What qualifier exactly? Jhowie Nitnek 15:44, 17 January 2023 (UTC)[reply]
See how its used in Brittania Vicarage (talk) 16:07, 17 January 2023 (UTC)[reply]
Linking from the personification to the thing it presents like done in the Berolina item seems to make more sense. ChristianKl ❪✉❫ 15:02, 17 January 2023 (UTC)[reply]
Would a link from the thing to the personification not also be useful? GrandEscogriffe (talk) 20:07, 18 January 2023 (UTC)[reply]
Yes and no. Thing about WD is it is linked data. So long as the information is in a reasonable place - either in the subject or the object item, or an item linked to the subject or object - then we're good. Wanting all the information on Berlin to be in the Berlin item is very much WP thinking. WP is not WD. Items are not articles. --Tagishsimon (talk) 20:26, 18 January 2023 (UTC)[reply]
Its a strong WD principle that we avoid duplication of data, so we avoid inverse statements if possible. They can be inconsistent, and encourage queries that only get half the picture. So we say A is a member of B, but not also B has members including A. There are exceptions for convenience, but I don't think one is needed here. Vicarage (talk) 20:26, 18 January 2023 (UTC)[reply]

Birthhouses

We have a lot of birth house (Q19979289) such as Birthplace of Jiří Voskovec (Q33243704) which usually are not actual birth places but rather places where the person spent his/her early years. They're nevertheless still called birthhouses. What's a preferred way of modelling the relationship between these places and the person? Using instance of (P31) : birth house (Q19979289) / of (DEPRECATED) (P642) : <<person>> is frequent but looks quite clumsy to me and the property of (DEPRECATED) (P642) is now a little frowned upon. Would this deserve its own new property? Vojtěch Dostál (talk) 21:09, 17 January 2023 (UTC)[reply]

The individual can link to the house with residence (P551)object of statement has role (P3831)birth house (Q19979289). If you have more information about when the person lived in the house start time (P580), end time (P582), and point in time (P585) can provide additional information.
In the other direction, named after (P138)subject has role (P2868)birth house (Q19979289) would work. ChristianKl ❪✉❫ 21:20, 17 January 2023 (UTC)[reply]
@ChristianKl Thanks! The idea with residence (P551) is good. Vojtěch Dostál (talk) 13:46, 18 January 2023 (UTC)[reply]

Number of viewers/listeners vs. Number of views/streams

Hello, I'm fairly new around here and I'd like to know if it would make sense to have a separate page from number of viewers/listeners (Q114771092) for number of views/listens or views/streams. If you go to Last.fm, for instance, artist pages have two separate numbers for their total amount of Listeners and Scrobbles, and currently I suppose there isn't a way to add 2 qualifiers for both numbers under Last.fm ID (P3192), only for one of them (Listeners). Moreover, for Spotify we might need to have a way to show monthly listeners. Of course, this type of data changes over time but so do other qualifiers such as number of subscribers (Q114771100), which is probably why users add point in time (P585). "Number of views" and "number of listens" being aliases seems misleading. Lily Allen having 720,956,190 views on YouTube doesn't (necessarily) mean that almost 721 million people watched her videos since one person (or bot) can watch multiple videos and/or watch the same video multiple times. We can easily realize this by looking at her Last.fm in which she has 2.6 million listeners vs. 80.9 million scrobbles. Guttitto (talk) 01:07, 18 January 2023 (UTC)[reply]

Numbers of views is something that consistently changes as such it doesn't work well for a non-changing external ID qualifier. ChristianKl ❪✉❫ 15:26, 19 January 2023 (UTC)[reply]
There is already a property for number of viewers/listeners (P5436) though, which I forgot to include in the original topic, and it is also variable. Guttitto (talk) 23:00, 21 January 2023 (UTC)[reply]
Same for number of subscribers (P3744) or social media followers (P8687). Guttitto (talk) 23:01, 21 January 2023 (UTC)[reply]
Also I didn't propose an external ID this is data type quantity. Guttitto (talk) 23:03, 21 January 2023 (UTC)[reply]


The Wikibase REST API is now available for testing on Test.Wikidata

Hello everyone,

As you may already know, we are developing a new REST API to improve programmatic access to data from Wikidata and other Wikibase instances. Many thanks to everyone who gave us the initial feedback on the proposed implementation plan of the REST API and subsequently tested the experimental phase of it on Beta Wikidata.

All the items listed in our previous communication as still needing to be completed for the initial release have now been completed and we are pleased to announce that the Wikibase REST API is planned to go live on Wikidata about a week later.

What is the current state capable of doing?

  • Retrieve the data of an Item with GET /entities/items/{item_id} and filter what fields (i.e. type, labels, descriptions, aliases, statements, sitelinks) are returned when reading the Item data
  • Retrieve all statements of an Item with GET /entities/items/{item_id}/statements
  • Retrieve the data of a single statement of an Item with GET /entities/items/{item_id}/statements/{statement_id} or GET /statements/{statement_id}
  • Conditionally request the data only if it has changed since the specified revision/timestamp (using If-None-Match, If-Modified-Since HTTP headers)
  • Create a statement on an Item with POST /entities/items/{item_id}/statements
  • Authenticate and authorize as a Beta Wikidata user when making edits using the API, as well as provide edit tags and edit comment, and mark an edit as one made by a bot.
  • Replacing the statement on an Item with PUT /entities/items/{item_id}/statements/{statement_id} or PUT /statements/{statement_id}
  • Removing the statement from an Item with DELETE /entities/items/{item_id}/statements/{statement_id} or DELETE /statements/{statement_id}
  • Automated edit summaries

The following functionality is still awaiting a final security review of a library and will be enabled once that is finished:

  • Editing a statement on an Item with PATCH /entities/items/{item_id}/statements/{statement_id}’ or ‘PATCH /statements/{statement_id}

Please note that the following items previously listed under "The following will likely not be available in the first version but follow later" have not yet been finished and will not be available in this initial release:

  • Creating or deleting an Item
  • Getting a statement from an Item based on the Property ID in the statement
  • Any operation (reading, adding, editing, removing) on sitelinks, labels, descriptions and aliases
  • Any operation on entity types other than Items (i.e. Properties, Lexemes, …)
  • Translated error messages

However, we will continue to work on these items in the future to provide a more comprehensive REST API. In order to prioritize our next steps, we would greatly appreciate feedback on which missing features you would find most useful to add next.

If you have any questions or want to provide feedback please let us know at Wikidata talk:REST API feedback round. As this new API is more tailored to the Wikibase data model than the Action API, we have outlined the differences in the JSON data format between the two for you for easy comparison.

Thank you for your patience and support as we continue to improve the Wikibase REST API.

Cheers, -Mohammed Sadat (WMDE) (talk) 18:55, 18 January 2023 (UTC)[reply]

coordinates from Google

Do we have any property for coordinates from Google? Do we have any plan to take coordinates from Google (perhaps Google Maps)? Geagea (talk) 09:38, 19 January 2023 (UTC)[reply]

No, and no. Such a thing as their copyright in their work & all. --Tagishsimon (talk) 11:35, 19 January 2023 (UTC)[reply]
Are coordinates copyrightable? Feels like they'd be some subset of PD-ineligible. DS (talk) 14:54, 19 January 2023 (UTC)[reply]
If they're just coordinates, WD has P625. If they're coordinates from google - i.e. the coordinate that google cites for an identifiable entity - then imo copyright exists in the arrangement of the entity with the specific coordinate. --Tagishsimon (talk) 18:19, 19 January 2023 (UTC)[reply]
The coordinates almost certainly aren't covered by copyright, however Google does have database rights over the entire collection of coordinates. Extracting coordinates from Google Maps would therefore likely be an infringement on these rights, at least in jurisdictions which recognise database rights either because they form part of domestic law or by mutual recognition of foreign "intellectual property" laws. meta:Wikilegal/Database Rights discusses this. --M2Ys4U (talk) 18:28, 19 January 2023 (UTC)[reply]
M2Ys4U thanks for the link. So, the database is protected as a compilation "the author made certain choices". The choice considered to be "creative expression", so it's part of copyright.
A. Google have coordinates for every location. Could this considered to be an "author made certain choice"?
B. Is there any database that is in the public domain?
Geagea (talk) 11:16, 20 January 2023 (UTC)[reply]
@Geagea I am not a lawyer but I don't think Google maps would be protected "because the author made creative choices" but because there are database rights attached to a mass use of any compilation, both in the US and EU. As for B, the closest thing to that would be any CC-0 database such as Wikidata. Vojtěch Dostál (talk) 11:56, 20 January 2023 (UTC)[reply]
@Vojtěch Dostál: Since when database rights exist in USA? But yes, despite CC0 usage of Wikidata in UK or EU has serious limitations due to basically ignoring database rights Mateusz Konieczny (talk) 13:04, 20 January 2023 (UTC)[reply]
@Mateusz Konieczny It's true that my layman knowledge of database rights is formed by the EU experience so I will not speculate any further on Google maps. Vojtěch Dostál (talk) 13:23, 20 January 2023 (UTC)[reply]
My understanding is that someone in USA can ignore database rights (sui generis database rights do not exist) - but such product may be illegal to use in EU or have severe limitations on its use (where database rights exist). This applies also to Wikidata, and its claimed CC0 license is quite misleading. Mateusz Konieczny (talk) 13:27, 20 January 2023 (UTC)[reply]
@Geagea: "Do we have any property for coordinates from Google?" - yes, many were indirectly harvested when copying Wikipedia data, where many coordinates were added by users copying them from Google Maps and asimilar sources. English Wikipedia openly encourages to copy coordinate data from Google Maps/OpenStreetMap/etc. which is perfectly legal in USA but database created from that is likely not legally usable in EU (warning: I am not a lawyer) Mateusz Konieczny (talk) 13:27, 20 January 2023 (UTC)[reply]
Usually, when a user manually ads a coordinate from Google Maps or OpenStreetMap they will chose the exact spot themselves. For cities that will usually mean that they are not choosing exactly the same point as Google Maps or OpenStreetMap. That's unprobleatic. It gets more complicated when you copy the exact location down to the meter and that choice is nontrivial (it's not simple the center). As far as I remember the question whether or not that's allowed is unsetteled. ChristianKl ❪✉❫ 01:52, 22 January 2023 (UTC)[reply]
@ChristianKl: people often copied this info semi-automatically or automatically, without choosing own spot. Also even if they selected exact spot in OpenStreetMap then they did it based on OpenStreetMap data only. And yes, that is likely not fully settled or not settled at all how much you can copy before database rights starts to apply (I am not a lawyer, none of my posts in this thread is an official opinion) Mateusz Konieczny (talk) 10:42, 22 January 2023 (UTC)[reply]

remove multilingual wikispecies on Cryptolechia rectimarginalis (Q20686360)

Cryptolechia rectimarginalis (Q20686360) contains wikispecies link under multilingual sites, however, wikispecies is only in english language. how do we proceed? remove from multilingual sites or maintain status quo? <_>Jindam vani (talk) 02:31, 20 January 2023 (UTC)[reply]

Most of the business on Wikispecies is in English, but a lot of the content is in Latin and there are homepages in many languages. —Justin (koavf)❤T☮C☺M☯ 02:45, 20 January 2023 (UTC)[reply]
Having the link is important and the multilingual tab is currently the one that links to Wikispecies. I think you could argue that maybe a name like "Other Wikiprojects" would be better than "Multilingual sites" but that's not a discussion about individual items. ChristianKl ❪✉❫ 14:53, 20 January 2023 (UTC)[reply]


[Survey for Wikidata data Reusers] Help us Improve Wikidata by Sharing Your Experience on Ontology Issues and Data Reuse Impact

Hello,

We are conducting a survey to better understand the ontology issues within Wikidata and their impact on data reuse.

You may recall that in 2021 and 2022 we run the Data Quality Days, which generated a lot of very useful discussions on the processes around increasing/maintaining data quality and utility on Wikidata. We identified various types of ontology issues, and we would like to get input on which of these are the most problematic for you in your use of Wikidata's data.

This survey has two sections and will take 20–25 minutes to complete. Optional open-ended questions may lengthen the completion time.

In the first section, we will present descriptions of the ontology issues we have found. We will ask you to evaluate the impact of these issues on your work, and you are also invited to share any other ontology issues you have detected in case we missed them.

The second section focuses on how you use data from Wikidata. Most of the questions in this section are optional, meaning you do not have to share details of your work unless you find them relevant to the issues you would like to share with us. They are helpful to us in understanding the context of your issues better, however.

This survey is anonymous, but there is an optional email field at the end for follow-up questions. Providing an email will make your responses not completely anonymous. A summary of the results of the survey will be published as a whole at Wikidata:Ontology issues prioritization and will not include any identifying information.

If you would like to participate, please use this link (LamaPoll): https://wikimedia.sslsurvey.de/ontology-issues/

We kindly request your participation by Friday, February 17th at 23:59 UTC.

If you have any questions, please do not hesitate to let us know by replying directly to this message or leaving a note at Wikidata talk:Ontology issues prioritization.

Many thanks in advance for your participation.

Cheers, -Mohammed Sadat (WMDE) (talk) 16:50, 20 January 2023 (UTC)[reply]

Merging corvée Q466259 and Corvée Q1369542

I think merging these two would be good. 178.26.170.21 12:28, 21 January 2023 (UTC)[reply]

A few of the language wikis appear to have distinct articles for both items, so you'd have to understand what's going on there; normally (despite the labels) there's a distinction to be drawn between the two item concepts; or else the wikis have duplicate articles, which ceb-wiki apart, is less likely. --Tagishsimon (talk) 13:07, 21 January 2023 (UTC)[reply]

Updating population of Hungarian municipalities

Please review my bot action to update the population of Hungarian municipalities, and if you are fine with that, please express your support on my request. Thank you. --Bean49 (talk) 16:48, 21 January 2023 (UTC)[reply]

Scope of identifiers: must they be general and official?

@Буквы

  • Greetings Wikidata editors, I was examining some additions of YouTube video ID (P1651) and YouTube channel ID (P2397) (YouTube links) to many many items, such as Chernobyl disaster (Q486). The addition is here. However, it seems that most other Wikidata:Identifiers are for database entries that describe the whole item, such as a general encyclopedia entry. These YouTube links are sometimes to a specialized video, unofficial niche material, or to an unverified channel, and in general they seem to be more appropriate as references/reliable sources, if at all, than Identifiers in their own right. Perhaps I am wrong, and perhaps the usage of Identifiers is more general than I had assumed. What do you think?

Elizium23 (talk) 18:38, 21 January 2023 (UTC)[reply]

yeah I think the item should be official in some way. Maybe the official upload of the music video or the official youtube channel. Just a youtube channel about the subject or a random upload of a video of the subject are not correct uses for these properties. BrokenSegue (talk) 19:37, 21 January 2023 (UTC)[reply]
(change to using P and Q templates above) My preference is to add a new identifier for the YouTube channel, and then add the videos as described by source (P1343) with qualifier URL (P2699), see HMS Victory (Q213958) which promotes the excellent videos by Drachinifel (Q112737775). If useful I add a title qualifier too. That way the source can build up its own portfolio. Occasionally I use described at URL (P973). I think this is better than asserting a single YouTube video for the item as a whole. I certainly don't get hung on justifying the addition. I add things which I consider enhance the item, my standards are lower for more obscure items. Vicarage (talk) 19:45, 21 January 2023 (UTC)[reply]
Thank you both for this guidance.
On a related note, I've noticed "Described in source Obalky.cz" added to many items. Is this the right way to do that? Obalky doesn't seem to have any substantial information, and my translator informs me that this is a book catalog, not intended as a general encyclopedia or database.
@Vojtěch Dostál - thoughts? Elizium23 (talk) 02:53, 22 January 2023 (UTC)[reply]
This database provides pictures, often even in cases when Wikimedia Commons has none. Anyway, book catalogues are no less an integral part of Wikidata than general encyclopedias. Vojtěch Dostál (talk) 08:52, 22 January 2023 (UTC)[reply]

Fixing incorrect merge of publishing concepts

Previously we had the concept of "publication in German copyright law" under publication in German copyright law (Q15852766) and "publishing - process of production and dissemination of literature, music, or information" publishing (Q3972943). The former appears to be about a specific concept in German law for the very moment of publication. The latter was about the broader concept of publishing as it applies to the whole world. These were then merged on 6 November 2022 by User:DerMaxdorfer.[8] We are now left with an item that says the concept of publishing for the entire world is based solely on German law. This is clearly a mistake but I'd like a second opinion on how to fix it. Using the principles of managing conflations, if this was a recent merge we would reverse it and if it is a longer term merge we would have to manually split the concepts into two new items and deleted the conflated item. Do we think this is recent enough to just reverse the merge? From Hill To Shore (talk) 23:17, 22 January 2023 (UTC)[reply]

Based on this diff, I would restore the pre-merge versions of both items and then re-apply the handful of recent edits. PKM (talk) 00:41, 23 January 2023 (UTC)[reply]
I merged the two items because of the chaos in the linking of Wikipedia articles in different language versions and I did my best to connect always those articles that describe the same topic. To be honest, I didn't care enough about the statements already existing in the different Wikidata items, otherways I would have deleted some the statements dealing exclusively with the German copyright law. In my opinion the German term doesn't need an own item. The description as "publication in German copyright law" in publication in German copyright law (Q15852766) is a mistranslation/misinterpretation of the original German description added here. Originally, this German definition translates as "in the German copyright law: moment, in which a work is made available to the public" and should probably only make aware of the fact that the word could have slightly different definitions in other languages even if it means the same thing.
To make it more clear: There is no specific concept called "publication" in German copyright law. The German copyright law (§ 6.1) only has its own short paragraph defining from which day to count the copyright rules we all know from Commons or Wikisource. That one sentence translates as: "A work is (= counts as) published, when it is made available for the public with consent of the authorised entity." In my eyes this sentence doesn't create something different from the one thing that is internationally called "publication" – but that can of course be seen differently. Therefore I have two possible solutions:
1.) Leave everything as it is.
2.) Re-create the item about the defined instant of time at which a work of art, literature etc. is counted as published in the German copyright law. But that item can only refer to the already cited §6.1 UrhG, not to any Japanese or Dutch terms as previously mentioned in the Wikidata item.
Please let me know which solution you choose so that I can at least arrange the German Wikipedia articles according to the new arrangement of the Wikidata items. --DerMaxdorfer (talk) 06:17, 23 January 2023 (UTC)[reply]

Wikidata weekly summary #556

Here's your quick overview of what has been happening around Wikidata over the last week.
  • Events
    • Past
    • Upcoming
      • Next Linked Data for Libraries LD4 Wikidata Affinity Group call January 24, 2023: We will be discussing plans for 2023, and requesting feedback and ideas for future programming. Based on a previous recommendation to host a discussion on advocacy for Wikidata within libraries, we will introduce and provide time to complete a short survey to foster conversation in a future Group Call. Please come ready to share your thoughts Agenda
      • Introductions to Wikidata, online meetings organized by Wikimedia Australia on January 25, 26 and 31
  • Development
    • Wikibase REST API: The new API is now available for testing on Test.Wikidata
    • Ontology issues: We finalized and published the survey to better understand which types of ontology issues are most problematic for reusers of our data.
    • Wikipedia and co: Fixing a regression where there is no entry in recent changes and watchlist when an Item is deleted that was connected to an article on that wiki (phab:T326082)

You can see all open tickets related to Wikidata here. If you want to help, you can also have a look at the tasks needing a volunteer.

View it! for adding missing P18 statements

Screenshot with View it! enabled.

We have shared about View it! before in the weekly summaries, but I wanted to post here to explicitly call out a new Wikidata-specific feature. View it! is a user script that will show you related images at the top of the page you are viewing—looking at a Wikidata item, it will show you any images in the Commons category if there is a Commons category (P373) statement and any images in a SDC depicts (P180) statement that use that Wikidata item.

Now there is a "+" button for every displayed image (see screenshot) that will allow you to easily add a missing image (P18) statement with a click—if the script is pulling up images but the item has no P18. We've been having some fun testing this feature. For example, here's a query of almost 500 Rijksmonument (Q916333) sites with no P18 statements, but with P373 statements, implying they have images available. Open them up in tabs and you can quickly click-to-add on them without ever leaving Wikidata (and faster even than Drag'n'drop). There is also a copy-to-clipboard button that copies the file name, in case you want to copy the name of an image you are seeing on the top bar in any other image property, like logo/flag/etc.

Please let us know if you have any feedback on using this tool, or would like to see it as a full gadget. Dominic (talk) 18:07, 23 January 2023 (UTC)[reply]

Nice idea, especially if gets more photos of my beloved forts. I sometimes go looking for aerial views, models and design plans of sites to add, so a possible extension would be a dropdown to choose which image type is to be populated. Vicarage (talk) 18:12, 23 January 2023 (UTC)[reply]
@Vicarage: We considered allowing other property types, but we didn't want to add too many clicks to the P18 experience or confuse users, if P18 is likely to be 95% of the usage. Maybe there's a different way to do it, though. Dominic (talk) 18:19, 23 January 2023 (UTC)[reply]
Had a go. The confirmation would start to irritate if I was doing it a lot, and I did wish that a tap on the photo would bring up a bigger image so I could judge it better, rather than going to the commons page. Vicarage (talk) 18:50, 23 January 2023 (UTC)[reply]

meta:Community Wishlist Survey 2023/Wikidata/Popup to link to or create a new Wikidata object after creating an article

Please see

Thanks! M2k~dewiki (talk) 18:54, 23 January 2023 (UTC)[reply]

Notability of the author of a Wikipedia source

Hi there,

Is the author of a Wikipedia source considered notable for Wikidata? This point is not clear for me.

Thanks in advance! 92.184.117.74 07:39, 24 January 2023 (UTC)[reply]

See Wikidata:Notability, especially Criteria 2 and 3. If by Wikipedia source you mean the author of a publication (book or journal article), then both the publication and the author would likely be notable: many authors can be clearly identified and described in catalogs like VIAF or ORCID, and a vast number of items for scientific journal articles and authors have already been mass imported (although the articles might not all be linked to their respective authors). If you mean the Wikipedian who created a Wikipedia article, then they are probably not notable enough for a Wikidata item. -Animalparty (talk) 08:36, 24 January 2023 (UTC)[reply]
Wikipedia uses a lot of blogs for sources. Blog authors mostly wouldn't be notable. --Christian140 (talk) 10:00, 24 January 2023 (UTC)[reply]
@Animalparty, Christian140: thank you! But what about such a source (which is not a scholarly article nor a blog: see CTHS person ID (P2383))? 92.184.107.173 11:06, 24 January 2023 (UTC)[reply]
Whether or not something is a blog isn't really the central criteria. We don't want that everyone who has a blog adds themselves for self-promotion purposes to Wikidata and thus don't treat that as being enough. The key question is whether there's a strutural need. In a case like your need I likely wouldn't create an item if there's just a single source for a certain person. If a person is however used frequently as a source there's a structural need to store that information in Wikidata. ChristianKl ❪✉❫ 15:18, 24 January 2023 (UTC)[reply]
In this specific case, the linked person has a French Wikipedia article, and existence of a Wikipedia article is automatic grounds for notability here. The entry can be found at Monique Kuntz (Q55758958). ChristianKl's explanation remains valid for similar cases lacking other grounds for notability. From Hill To Shore (talk) 09:00, 25 January 2023 (UTC)[reply]

Junk items. last report.

even though i dont give a fuck about junk on wikidata, i'll report this one last time. (previous reports: Wikidata:Project_chat/Archive/2022/12#IP_user_creating_lots_of_items_for_commons-only_cats Wikidata:Administrators'_noticeboard/Archive/2023/01#Report_concerning_User:G6zLZz2cEPKdEXB.)

these users, and possibly other accounts/ip that i didnt find out, have created hundreds of junk items ( https://xtools.wmflabs.org/pages/www.wikidata.org/G6zLZz2cEPKdEXB https://xtools.wmflabs.org/pages/www.wikidata.org/218.102.0.123 ) that link to granular commons cats that dont need an item, e.g. Q116298299 Q116298452. RZuo (talk) 12:41, 24 January 2023 (UTC)[reply]

✓ all deleted. Thanks for notifying @RZuo! Let we know if you discover another IPs/users. Estopedist1 (talk) 18:59, 24 January 2023 (UTC)[reply]
@Estopedist1: We have the same behaviour from the user at User talk:218.102.0.44 with large scale creation of bare items with only a Commons category site link. The pattern of edits (and similar ip) appears to indicate it is the same editor. From Hill To Shore (talk) 04:23, 25 January 2023 (UTC)[reply]
I spoke with them as shown in that talk. They were definitely operating a bot without approval but it seems they now understand not to do that. I'll go through and nuke the old items. BrokenSegue (talk) 05:42, 25 January 2023 (UTC)[reply]
also User:42.200.150.136 there's probably more too. BrokenSegue (talk) 06:05, 25 January 2023 (UTC)[reply]

Invalid CSRF token

Dear devs,

after having troubles and needing 10x tries to get logged in I'm getting invalid CSRF token on many actions.

How long does it take until all my zombie sessions have timed out on the server? Zachary Zulock (talk) 21:03, 24 January 2023 (UTC)[reply]

there's an outage https://phabricator.wikimedia.org/T327815 BrokenSegue (talk) 21:09, 24 January 2023 (UTC)[reply]

Adding/Removing leading zeros for URL formatter

Hello, regarding this discussion: Topic:Xbcy58fywxh6shvz / Property:P381

Is it possible to add or remove leading zeros for parameters using the URL formatter?

For example, instead of

using

without leading zeros? (while keeping the same ID in the related object d:Q19362321)

Thanks a lot! M2k~dewiki (talk) 14:44, 25 January 2023 (UTC)[reply]

Using different URLs for the URL formatter, depending on a property?

Hello, regarding this discussion: Topic:Xbcy58fywxh6shvz / Property:P381

Property:P381 links to the Heritage-Tool-DB

For class/category A objects there would also be a official URL available:

The official URL is not available for class/category B objects:

Is it possible to use different URLs for the URL formatter, depending on a property? For example, depending on Property:P1435:

  • value Schweizer Kulturgut von nationaler Bedeutung -> official URL
  • value Schweizer Kulturgut von regionaler Bedeutung --> Heritage-Tool-DB

Thanks a lot! M2k~dewiki (talk) 14:45, 25 January 2023 (UTC)[reply]

The first version of the new Wikibase REST API is now available on Wikidata

Hi everyone,

We are working on making it easier to use Wikidata's data to build applications. A big part of that is a better API. Over the past months we have been developing the first version and gotten testing and feedback for it. Last week we made it available on test.wikidata.org. Today the first version of the new Wikibase REST API is available on Wikidata. I'd like to thank everyone who helped along the way by providing feedback and testing.

You can find more information on what you can already do with the new Wikibase REST API at Wikidata:REST API.

We will continue to build out its functionality and your input on what would be most useful for you will help prioritize the next steps. Please leave your thoughts on the feedback page.


Cheers Lydia Pintscher (WMDE) (talk) 15:29, 25 January 2023 (UTC)[reply]

Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Project_chat&oldid=1819074268"