Shortcuts: WD:PC, WD:CHAT, WD:?

Wikidata:Project chat

From Wikidata
Jump to navigation Jump to search

Wikidata project chat
A place to discuss any and all aspects of Wikidata: the project itself, policy and proposals, individual data items, technical issues, etc.

Please use {{Q}} or {{P}} the first time you mention an item or property, respectively.
Other places to find help

For realtime chat rooms about Wikidata, see Wikidata:IRC.
On this page, old discussions are archived after 7 days. An overview of all archives can be found at this page's archive index. The current archive is located at 2024/08.

How to describe printed work?

[edit]

There is general term publication (Q732577) for any published, than physically printed work and printed book (Q11396303) is limited to just book. How to call any of such printed release of newspaper or any release looking like this? Eurohunter (talk) 19:28, 5 August 2024 (UTC)[reply]

@Eurohunter Do you mean periodical issue (Q21995230) ? Vojtěch Dostál (talk) 12:29, 8 August 2024 (UTC)[reply]
@Vojtěch Dostál: I don't think so. It don't indicate paper release. In case of music there are CD, vinyl or digital version, in case of books there is paper and digital version. Eurohunter (talk) 19:27, 8 August 2024 (UTC)[reply]
Do you want to model the specific exemplar or the fact that this newspaper was released via print? Uniwah (talk) 17:47, 11 August 2024 (UTC)[reply]
@Uniwah: Yes I want to model the fact that this newspaper was released via print. Eurohunter (talk) 07:44, 15 August 2024 (UTC)[reply]

Inconsistencies in the list of countries by continent

[edit]

I try to list the sovereign state (Q3624078) included (has part(s) (P527)) in each continent (Q5107) with an ISO code (ISO 3166-1 alpha-3 code (P298)}).

See the query

SELECT ?item ?itemLabel ?country ?countryLabel ?code WHERE {  ?item wdt:P31 wd:Q5107;    (wdt:P527*) ?country.  ?country wdt:P31 wd:Q3624078;    wdt:P298 ?code.  SERVICE wikibase:label { bd:serviceParam wikibase:language "en". } }
Try it!

I find many countries included to two different continents.

One source of error is do to the following statement: Africa (Q15)has part(s) (P527)Middle East (Q7204). This leads to the misleading consequence that Israel belongs to Africa. I propose to remove the statement.

Another problem is that France, Chili, and the United States are considered part of Oceania.

Finally, we have a problem with countries in Central America. They are considered to be part of both South America and North America.

How could we have a consistent list of countries by continent? PAC2 (talk) 12:51, 7 August 2024 (UTC)[reply]

More inconsistencies: Denmark and the Netherlands are missing (because the constituent countries are included in the continents, not the sovereign state), Georgia, Armenia, Azerbaijan and several countries in the Middle East are missing, Russia is included in Europe but not Asia, and there is no consistency with countries with limited recognition - Palestine and Taiwan are there, but Kosovo is not. Peter James (talk) 19:08, 7 August 2024 (UTC)[reply]
@Peter James You're right. It isn't always easy to find missing values.
I've written a small notebook to explore the data : https://observablehq.com/@pac02/list-of-countries-by-continent-in-wikidata.
How could we have consistent data for this simple query? is there any reliable source on this topic? PAC2 (talk) 21:17, 7 August 2024 (UTC)[reply]
Turkey and Russia do span continents. And lots of island chains are either of full status, like Tahiti and Hawaii, or a muddle of dependant territory rules. I think your query should expect to reflect that, use of preferred values won't help here. Vicarage (talk) 06:51, 8 August 2024 (UTC)[reply]
OK @Vicarage what would you suggest? PAC2 (talk) 14:08, 8 August 2024 (UTC)[reply]
Like pretty much anything to do with countries, the results you get will depend very heavily on how exactly you frame the question. The concepts of "country" and "continent" are both quite fuzzily defined, with significant differences between sources even on how many of each exist, never mind where their boundaries are, and in pretty much any permutation there will be many countries that span more than one continent. It's not particularly surprising that France would come back as being part of Oceania, for example, given French Polynesia (Q30971). (There's a difference between "All of France is in Oceania" and "Some of France is in Oceania"). Other permutations of the query would also show parts of France within Africa (Réunion (Q17070)), North America (Saint Pierre and Miquelon (Q34617)) and South America (French Guiana (Q3769)). If that's unexpected or unwanted, then you'll need to reword the question in a much more precise manner. Then if needed we can help express that in SPARQL and fix any errors or gaps in the underlying modelling or claims to make sure the various queries all get the correct answers. --Oravrattas (talk) 08:56, 10 August 2024 (UTC)[reply]

made-for-TV film whose subsequent re-runs have been divided into seperate television series episodes

[edit]

Do we have any items or properties that can be used to indicate this? And to indicate the relationship between the movie and the seperate episodes? Trade (talk) 17:48, 9 August 2024 (UTC)[reply]

Movie in question--Trade (talk) 17:48, 9 August 2024 (UTC)[reply]
Unfortunately, I don't think there's an established, documented way of modeling such editions (film cut into episodes, series cut into a movie, or movies that are sometimes released as one, two or more parts). Various such pilot movie items simply have has part(s) (P527) statements with the different episode items as values. But that doesn't really convey the exact nature of their relationship. Maybe edition or translation of (P629) and has edition or translation (P747) could be used. based on (P144) on the other hand is probably too generic, IMHO.
Tried to look up how this case is modeled on EIDR, but they simply list the three separate episodes and the film as just episodes of the show. And ISAN doesn't even have an entry for the film version, only the three episodes. So no help there, unfortunately. --2A02:810B:580:11D4:64A3:4ECC:9AC4:295B 21:26, 10 August 2024 (UTC)[reply]
Why not use derivative work (P4969)? Trade (talk) 14:37, 14 August 2024 (UTC)[reply]
Right, that would also a good candidate, didn't think of that. Though it kinda has the same "problem" as based on (P144), in that it is somewhat generic and doesn't necessarily fully convey the exact relation.
Though now I'm not even sure how we can properly model the details without creating items for the parts of the movie (like chapters of a book), and then use something like edition or translation of (P629) or derivative work (P4969) to connect those to the episode items. But that approach would probably be too detailed and also too cumbersome.
We also have the same problem (only parts of a work edited into a new work/edition) with other things like comics or literature published in serialized form.
Maybe we need a new property specifically to describe the exact relationships between individual works? Something like "relationship to other work" linking to the movie item, with qualifiers like "object has role" -> "movie cut into episodes" or "original work" + "subject has role" -> "episodic edit of a movie". That might even be useful for stuff like sequels, prequels, reboots or remakes that we also don't have a good way of modeling so far. --2A02:810B:580:11D4:B022:D696:BA14:90A3 00:31, 15 August 2024 (UTC)[reply]
I have now created television film later divided into television series episodes (Q129086536). Please suggest a better name or description because this isn't too great--Trade (talk) 14:38, 14 August 2024 (UTC)[reply]
[edit]

I don't understand what's the difference between these badges. "sitelink to redirect" description says "do not apply this badge manually; if you manually apply a badge you likely want to apply "intentional sitelink to redirects" instead". so "sitelink to redirect" is only for bots? if we add a wikilink that's actually a redirect we should use "intentional sitelink to redirect" instead? Did I understand that correctly? Why though? Or is it something else? The thing is, it's possible to add "sitelink to redirect" manually and I see users actually add that one, so what's the point? Tehonk (talk) 23:42, 9 August 2024 (UTC)[reply]

Good question. I was thinking the same and some items have both badges. Eurohunter (talk) 00:05, 10 August 2024 (UTC)[reply]
"intentional sitelink to redirect" is for humans, so that they can insert a link to a redirect, declaring the intention. In fact, this is the only possible way.
"sitelink to redirect" is indeed for bots. They cannot tell if the link intentionally links to a redirect or not, it's just an indicator for users who can deal with it. --Matěj Suchánek (talk) 09:40, 10 August 2024 (UTC)[reply]
I would probably add "sitelink to redirect" to an existing sitelink if I found a redirect and did not know if it was correct (if it could be a duplicate article or a redirect not relevant to the item). Peter James (talk) 10:39, 10 August 2024 (UTC)[reply]

Q2842000 is missing some info

[edit]

Ambazonia (Q2842000) has quite a ton of missing info. The presidents for example, need to have things identifying that they are "The President of the Interim Government". Remember, there are many factions. Also, you gotta have two new presidents in the "head of state" section; Marianta Njomia and Chris Anu.
And also, you need to add the vice presidents of the four. Dabney Yerima for Ayuk Tabe, Eric Ateh for Sako, Hariscine Abongwa for Marianta, and Rev Njini for Chris.
Since we're assuming that that page is just for the Interim Government and nobody else, there are three sites you need to put in there: "statehousebuea.org" for Sako, "federalrepublicofambazoniagov.org" for Marianta, and "ambazoniagov.org" for Chris Anu. Make it so that the link to ambagov.org leads to an archive of the page too.
People also seem to sometimes erroneously call the Interim Government's state not as the Federal Republic of Ambazonia, but as the Republic of Ambazonia. Not to be confused with the faction "Republic of Ambazonia". Gotta add that to the "also known as" part of the page.
The emblem of Ambazonia shouldn't be here too. I've read the constitution and I can provide an exerpt from it, Article 4, Section 4: "The national coat of arms shall be an escutcheon supported by two crossed fasces with the motto 'JUSTICE-UNITY-DEMORACY'. The escutcheon shall be composed of two gold stars and triangle gules, charged with the geographical outline of Ambazonia in azure and surcharged with the scales of Justice." (hold on, did copy-pasting this exerpt from the constitution break the rules?)
And guess what, Sako changed the coat of arms of the interim government at the start of 2024, and the constitution Sako made isn't even ON the web.
So since the two coat of arms of the IG haven't been uploaded to Wikicommons yet, let's just use the seals of the Interim Government.
Ambazonia also left the UNPO in 2021, it seems.
But everything else seems fine. Please try to edit the things described in this post into the Ambazonia Wikidata page. Thanks. Kxeon (talk) 13:36, 10 August 2024 (UTC)[reply]

Using low numbers for commonly used properties

[edit]

Summary

[edit]

Property:P6 is the only one of P1-P9 that currently exists. Since these numbers that are easy to type and remember, should we could move common properties to them or redirect them to the existing common property numbers?

Property history

[edit]

P7 and P9 were deleted in 2016 and probably had substantial use. I don't think we should overwrite these any time soon.

P11 and P12 were deleted in 2013 with no substantial usage. (P11 log, discussion; P12 log, discussion). I'm inclined to overwrite these.

Suggested properties

[edit]

I'd suggest the following properties:

  1. instance of (P31)
  2. subclass of (P279)
  3. part of (P361)
  4. has part(s) (P527)
  5. inception (P571)
  6. head of government (P6) (Already exists)
  7. P7 (P7) (Reserved from recent usage)
  8. dissolved, abolished or demolished date (P576)
  9. P9 (P9) (Reserved from recent usage)
  10. video (P10) (Already exists)
  11. start time (P580)
  12. end time (P582)
  13. publication date (P577)

I based this list on properties that I subjectively regard as basic, and prioritized items I thought most likely to be used by humans (as opposed to automated tools) in queries and manual entry.

One list of most frequently used properties is at Wikidata:Database reports/List of properties/Top100. It might be useful to compare another list which excludes properties used in references.

I offer this list to help illustrate my proposal, but I'd suggest we postpone discussing which properties to choose before answering the feasibility and desirability questions below.

Questions

[edit]
  1. Is it possible there were uses of these low-numbered properties in Wikidata history that we should care about that aren't showing up in "Main public logs" at Special:Log?
  2. Is moving a highly-used property inherently a bad idea because it will increase server load due to increased redirects? (eg. redirecting P31 to P1) This will decrease over time.
  3. Is making a highly-used redirect inherently a bad idea because it will increase server load due to increased redirects? (eg. redirecting P1 to P31). This will continue perpetually.
  4. Do others think moving or redirecting would be good or bad for other reasons besides questions 2 and 3?
  5. Which is better, redirecting P31→P1 or P1→P31?
  6. Should we move or redirect over deleted properties that were never substantially used, eg. Property:P11? How much time should we give for existing uses to transition after deletion? (eg. 10 years)

Daask (talk) 18:58, 10 August 2024 (UTC)[reply]

It is a tremendously bad idea to repurpose deleted items or properties, regardless of the reasoning. Doing this would require millions and millions of changes to existing items. And furthermore, the item and property numbers aren't how most human interact with them -- instead they rely on the autocompletion of the labels and aliases. Your proposal seems to be a solution in search of a problem. I see no problem with the status quo. William Graham (talk) 20:36, 10 August 2024 (UTC)[reply]
@William Graham: Not repurposing answers question 6. "Millions and millions of changes" seems to oppose moving, but doesn't address creating redirects. As for what problem this solves: I often rely on my memory for common Wikidata property numbers for queries. Obviously, there are far more properties than can be memorized, so we do need user-friendly systems for searching for properties by label, but I thought having low numbers for the most common ones would make Wikidata more accessible to new users. Daask (talk) 12:34, 12 August 2024 (UTC)[reply]
 Strong oppose Creating redirects would make item histories nonsensical. There are a nontrivial number of historical (deleted) statements of deleted properties. If the Property number came back into existence then it would make it look like the value from the historical deleted statement applied to a completely different property. Also redirects in the property namespace will create scenarios where the results from Wikidata Query Service are missing results or provide unreliable results. Those are just some of the reason that your proposal is bad for data integrity and the useability of the knowledge base. William Graham (talk) 15:47, 12 August 2024 (UTC)[reply]
It certainly would be nice to have the most common properties at the low numbers that are much easier to memorize. And if we had to built the project again from the ground up, that would certainly be something that would be done. But after more than a decade into the project's existence, I think changes like that are simply not easily doable and would most likely have too many downsides and potential unintended side effects. --2A02:810B:580:11D4:68ED:8DC0:B68B:72FE 21:40, 10 August 2024 (UTC)[reply]
 Oppose I think everybody's going to have their own list of properties they'd like to be easier to enter, but really 2 characters vs 3 or even 5 is not a big deal. Plus most properties in my experience are just entered via autocomplete (or bots) where the property number is irrelevant. If I was to pick my priority properties it would probably be human-related ones like occupation (P106), employer (P108), affiliation (P1416) and some of the properties related to name (P2561). ArthurPSmith (talk) 14:21, 12 August 2024 (UTC)[reply]
Tech comment re 1 – my understanding is that in the early days of Wikibase, the list of reserved Entity IDs was shared between all Entity types, so P1–P5 never existed because Q1–Q5 were reserved (Universe (Q1), Earth (Q2), life (Q3), death (Q4), human (Q5)). Lucas Werkmeister (WMDE) (talk) 16:02, 12 August 2024 (UTC)[reply]
 Oppose – IMHO the justification for this proposal is pretty weak; I’ve previously argued (meta:Talk:Abstract Wikipedia/Reserved ZIDs#Spreading out numbers) that core Wikidata entity ID numbers not being consecutive or clustered in a small numeric range is actually a good thing. Lucas Werkmeister (talk) 16:05, 12 August 2024 (UTC)[reply]
I can never remember the number of family name (P734) because it's right next to given name (P735), so I strongly agree with this argument. —Xezbeth (talk) 06:31, 14 August 2024 (UTC)[reply]
 Oppose I see no good reason to re-number existing properties. And even if there were a reason, it would have to be a really good one to justify the technical problems that such a renumbering would cause. M2Ys4U (talk) 16:56, 12 August 2024 (UTC)[reply]
 Oppose no, please no! Multichill (talk) 16:32, 13 August 2024 (UTC)[reply]
 Oppose many people tent to remember something by its look or name. Changes like this, makes the environment to them unfriendly. --Juandev (talk) 07:20, 14 August 2024 (UTC)[reply]
[edit]

How can I add a link from https://ru.wiktionary.org/wiki/*dailijaną to https://en.wiktionary.org/wiki/Reconstruction:Proto-Germanic/dailijaną? This https://www.wikidata.org/wiki/Q127874798 doesn't work. ПростаРечь (talk) 21:25, 10 August 2024 (UTC)[reply]

Also see Wikidata:Wiktionary/Sitelinks M2k~dewiki (talk) 14:28, 11 August 2024 (UTC)[reply]

Lots of population statements

[edit]

For a nearby municipality, official population count for each village is available online with monthly precision going back about 15 years. Is there anything wrong with adding ~200 statements per village to reflect that data? It seems "bad" in some way but I can't figure out any concrete problems. Uniwah (talk) 13:09, 11 August 2024 (UTC)[reply]

@Uniwah: Large items (with more statements) are slower to load, and there is a fixed limit on item size (which is usually reach at something like 5000 statements). But we do have a property specifically for this problem of lots of population data: tabular population (P4179) - the datasets go on Commons, with a link from the Wikidata item. ArthurPSmith (talk) 14:28, 12 August 2024 (UTC)[reply]

Wikidata weekly summary #640

[edit]

Blue plaques

[edit]

Hello folks - I've been considering how specific instances of blue plaque (Q885849) (used to commemorate notable people in the UK) should be represented on Wikidata. A few have been created as their own Q item (e.g. Annie Besant blue plaque (Q123737173), First Flying bomb on London fell here (blue plaque), Tower Hamlets (Q83187836), Helene Aldwinckle blue plaque (Q116544313)). One building, Colonnade Hotel (Q5148462) "has part" blue plaque, which commemorates Alan Turing.

Would there be less redundancy if the person recognised by the plaque had a statement saying something like "commemorated by / award received > blue plaque" and then qualifiers for date, awarding body, and coordinate locations? Or is the separate item preferable because of the material and geographical nature of plaques? I'm thinking probably the building approach is not ideal because most buildings home to plaques will not be on Wikidata already and so that would be a barrier.

What do you think? Zeromonk (talk) 09:42, 13 August 2024 (UTC)[reply]

I don't think we should compete with the good people at Open Plaques (Q23018437), and should use Open Plaques plaque ID (P1893) rather than create lots of new items Vicarage (talk) 14:27, 13 August 2024 (UTC)[reply]
I agree with Vicarage. Multichill (talk) 16:32, 13 August 2024 (UTC)[reply]
Thanks both, that makes total sense! Do you know if it's possible to write a query in the Wikidata Query service to pull in things like coordinates from OpenPlaques to represent alongside data about people? Zeromonk (talk) 09:38, 14 August 2024 (UTC)[reply]
I don't, but you might also like to look at Historical Marker Database (Q21815238) which also has a WD property. Generally WDQS returns WD information, and you'd need to scrape URLs mentioned there to get further information on the 3rd party site. Vicarage (talk) 15:55, 15 August 2024 (UTC)[reply]

Problematic items for Brazilian people

[edit]

P31|Q5|S460|Q18382802

Some items for Brazilian people have wrong references

Each item has said to be the same as (P460) sex or gender (Q18382802) as their reference of instance of (P31) human (Q5)

I fixed some item such as Fabiana Andrade (Q10279109). Sharouser (talk) 15:56, 13 August 2024 (UTC)[reply]

We should fix these items and add citizenship information to them.
I think this is just bullshit. At least this is conflicting with human rights (Q8458) which might be the reason Brazil makes such silly laws. --Matthiasb (talk) 05:56, 14 August 2024 (UTC)[reply]

SELECT ?item ?reference WHERE {

 ?item wdt:P31 wd:Q5 .
 ?item p:P31 [ prov:wasDerivedFrom [ pr:P460 ?reference ] ] .

}

I will fix them. Sharouser (talk) 11:41, 14 August 2024 (UTC)[reply]

QuickStatements Community Consultation

[edit]

Hello, fellow Wikidata contributors!

QuickStatements has become an essential tool for many of us in the community, helping to streamline our contributions to Wikidata.

In light of the new developments around this tool, we want to hear from you about QuickStatements and where we can improve it.

For that, we've created a brief 19-question survey to gather your valuable insights on QuickStatements.

It will take just 15-20 minutes of your time and it will really help us refine the tool towards your needs and make it even more effective for everyone.

The survey will be open until August 31st.


Share your insights here!


Thank you in advance! EPorto (WMB) (talk) 19:20, 13 August 2024 (UTC)[reply]

P248

[edit]

Why stated in (P248) is vague and we dont have properties for different types of resources, like book, article, database etc.? Juandev (talk) 07:15, 14 August 2024 (UTC)[reply]

We want to be wary of multiplying up properties, as it generates more edge conditions and slows queries. As with described by source (P1343), its better to have a vague general property and use qualifiers to narrow it down. Vicarage (talk) 07:46, 14 August 2024 (UTC)[reply]
@Juandev Please don't create items like Q128840843 for each URL you want to cite in a reference. It is perfectly adequate to just cite it using a more general stated in (P248) value such as Vetřelci a volavky (Q98538810) and specify URL or authors using reference URL (P854) and author name string (P2093) *in the reference itself*. See Help:Sources#Web_page for a general quideline. Vojtěch Dostál (talk) 11:08, 14 August 2024 (UTC)[reply]
Creating items for chapters such as Umění v hotelu ČSSR (Q128836594) is also unnecessary, see Help:Sources#Books where usage of chapter (P792) is explained. Vojtěch Dostál (talk) 11:10, 14 August 2024 (UTC)[reply]

Deleted qaulifier

[edit]

Is this possible to find deleted qualifier by label? Eurohunter (talk) 07:43, 15 August 2024 (UTC)[reply]

Populated places and their industries

[edit]

My interest is in using Wikidata to capture and present aspects of Scottish history. After a recent conversation about the decline of the Scottish fishing industry, I looked at the available data. Petscan gives a decent category-based list of towns [1], but the place items themselves (e.g. Eyemouth (Q1020260)) lack any data association with fishing.

Looking around, I can see some use of instance of (P31) fishing village (Q1317251) but that seems inappropriate for say Aberdeen. There is also occasional use of industry (P452) on a place (e.g. Bonon (Q2910327), but with warnings that it breaches the Subject Type Constraint, as the property is reserved for use on companies, etc.

I wonder if there is another property to capture the industries of a place? If not, should there be? Or should the use of P452 be relaxed to allow its use for populated places? It strikes me that this or some other Property can underpin a richer understanding of what forms of work activity led to a town emerging/declining: fishing, weaving, salt panning, etc. AllyD (talk) 13:02, 15 August 2024 (UTC)[reply]

Should they be opposite of (P461) or inverse property (P1696) of each other? JuguangXiao (talk) 09:14, 16 August 2024 (UTC)[reply]

I don't think they have that relationship. Usually inverse properties are when tboth have a data type of a Q item and it is normally the case that the statements will link two items in both directions, like has parts and part of or child and mother/father. William Graham (talk) 02:01, 17 August 2024 (UTC)[reply]