Property talk:P143

Documentation

• Start a query
• Current uses
• Statistics by class
• List of values
• List of qualifiers
• Count

imported from Wikimedia project
source of this claim's value; used in references section by bots or humans importing data from Wikimedia projects

Represents	Wikimedia Foundation project (Q14827288)
Data type	Item
Usage notes	Describes claims imported from Wikimedia projects like Wikipedia, either by bots or manually. For other sources, use "stated in" (P248)
Robot and gadget jobs	DeltaBot does the following jobs: Move qualifier to source
Tracking: usage	Category:Pages using Wikidata property P143 (Q98094339)
See also	Wikimedia import URL (P4656), stated in (P248), reference URL (P854)
Lists	bubblechart of most frequent WMF import sources Items with no other statements Most recently created items Items with novalue claims Items with unknown value claims Usage history (total) Usage history (main statement) Database reports/Complex constraint violations/P143 Database reports/Constraint violations/P143 Map Random list
Proposal discussion	[not applicable Proposal discussion]
Current uses	Total 5,819,573 Main statement 18 <0.1% of uses Qualifier 15 <0.1% of uses Reference 5,819,540 >99.9% of uses
Search for values

[create Create a translatable help page (preferably in English) for this property to be included here]

Scope is as reference (Q54828450): the property must be used by specified way only (Help)

List of violations of this constraint: Database reports/Constraint violations/P143#Scope, hourly updated report, SPARQL

Value type “Wikimedia Foundation project (Q14827288), database derived from Wikimedia projects (Q63144794), Wikidata tool (Q20726407), Wikimedia Phabricator (Q42156541)”: This property should use items as value that contain property “instance of (P31)”. On these, the value for instance of (P31) should be an item that uses subclass of (P279) with value Wikimedia Foundation project (Q14827288), database derived from Wikimedia projects (Q63144794), Wikidata tool (Q20726407), Wikimedia Phabricator (Q42156541) (or a subclass thereof). (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303). Known exceptions: Norwegian Wikipedias (Q191769)
List of violations of this constraint: Database reports/Constraint violations/P143#Value type Q14827288, Q63144794, Q20726407, Q42156541, SPARQL

Allowed entity types are Wikibase item (Q29934200), Wikibase lexeme (Q51885771), Wikibase sense (Q54285715), Wikibase form (Q54285143), Wikibase property (Q29934218): the property may only be used on a certain entity type (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P143#Entity types

This property is being used by: en:Template:Infobox airport/Wikidata pt:Predefinição:Info/Assentamento/Wikidata Please notify projects that use this property before big changes (renaming, deletion, merge with another property, etc.)

Likely incorrect values
values with 5+ uses. If there are many, ask for conversion at Wikidata:Bot requests (Help)
Violations query: SELECT ?item ?ct WHERE { { SELECT ?item (count(*) as ?ct) WHERE { ?stmt pr:P143 ?item } GROUP BY ?item HAVING(?ct > 4) ORDER BY DESC(?ct) LIMIT 2000 } MINUS { ?item wdt:P31 wd:Q10876391 } FILTER ( ?item != wd:Q565 ) FILTER ( ?item != wd:Q28563569 ) MINUS { ?item wdt:P31 wd:Q15156455 } MINUS { ?item wdt:P31 wd:Q22001389 } MINUS { ?item wdt:P31 wd:Q19826567 } MINUS { ?item wdt:P31 wd:Q55657495 } MINUS { ?item wdt:P31 wd:Q20671729 } FILTER ( ?item != wd:Q13679 ) } ORDER BY DESC(?ct) ASC(?item)
List of this constraint violations: Database reports/Complex constraint violations/P143#Likely incorrect values

Discussion

relevance ?

I have left a message to User:Denny Vrandečić (WMDE) to see if we can get more info on sources, but "Wikipedia" does not look like a property to me. A property defines a relation between a thing and another thing. "Wikipedia" does not do that. In the cases for which this property was intended, my guess is that we should have something like source: imported from Italian Wikipedia --Zolo (talk) 09:37, 24 February 2013 (UTC)

I think the property should be renamed, but I have no other concern with it. Could we call it something like "import source" for now? This property should be viewed as a placeholder, a way of recording where imported data came from in the early stages of the project. Espeso (talk) 09:52, 24 February 2013 (UTC)

It sounds good to me. My point was just that a property name should define the type of relation with the property value, and, less importantly, that it could also be used for imports from non-Wikipedia sources. --Zolo (talk) 10:05, 24 February 2013 (UTC)

Sounds good to me too. HenkvD (talk) 12:24, 24 February 2013 (UTC)

Thanks, I updated the label to "import source", and the description to "source of this claim's value (use only in Sources section)". Feel free to adjust. I used the word "claim" here, which I believe is technically accurate: a claim becomes a "statement" once a source attached. Using this property in Sources makes the whole package a "statement". Espeso (talk) 12:34, 24 February 2013 (UTC)

I wanted to change the nl label and desctiption too, but I seem unable. Label "import bron" and description "bron van deze claim (gebruik alleen in Bronnen sectie)" HenkvD (talk) 13:18, 24 February 2013 (UTC)

Probably a bug. Did you try to add "www." to the URL.

I have changed the label to "imported from". I think it sounds more natural, this is already in a "source" field.

I think the description should be something like "used in the source section, to mean that the data was automatically imported from the following website or database". "source of this claim's value " is rather vague, and could be used for any type of "source property". --Zolo (talk) 19:16, 24 February 2013 (UTC)

Indeed I need www.wikidata.... HenkvD (talk) 16:13, 26 February 2013 (UTC)

Wikipedia as a source?

Why should Wikipedia be considered a source, when an Wikipedia article itself is a synthesis of information from different sources found across the internet, books, etc.? The problem with this is that when a claim is supported by a Wikipedia article, the source (the Wikipedia article) is not stable and can have information deleted from it any time. This will very well result in circular referencing, as Wikidata will be feeding information to Wikipedia in the future. --Wylve (talk) 15:23, 24 February 2013 (UTC)

I guess a Wikipedia source can only be temporary. To me this property means something like: "the claim was made on Wikipedia in some language, please check there if the claim has better references". In any case, there is a lengthy discussion on the issue at Wikidata:Project_chat#Proposal:_preventive_control_of_imported_data_correctness. --Zolo (talk) 19:19, 24 February 2013 (UTC)

It can't be a source never ever, even temporary. All unsourced data should be removed immidiately. Who will clean up the mess numerous bots are doing? --Matthiasb (talk) 17:13, 12 March 2013 (UTC)

 Wikimedia source (as any other source) could be permanent and with a deprecated rank in order to prevent re-entry of incorrect data but it is almost always better to fix the text. d1g (talk) 07:03, 23 March 2017 (UTC)

There's a problem. We can use the qualifier "imported from": (P143) to give "Wikipedia in <language>", but we cannot link its source article correctly (except by using the ugly qualifier "URL", which is URL-encoded and forces the choice of the HTTP or HTTPS protocol and server name).

I tried to add the additional qualifier "subject of" (Property:P805) to specify the Wikidata item that should contains the link to the article on that subject.

But there's still no relevant qualifier to indicate the relevant anchor. For that we should have another qualifier "anchor" (Property: ???) to give the anchor name within that article. For now I used the qualifier "section, verse, or paragraph" (Property:P958), by setting the value as "#<section-id>" but as this is free text it is too much permissive and we should have better qualifiers for anchors in Wikipedia articles (and those anchors could then be checked by bots if the articles are modified or the section headings are edited, changing their default ID). That additional "anchor" property will be relevant only for the Wikipedia language edition specified in "imported from:".

May be we should also have a new qualifier for the "article version ID" (notably on Wikipedia editions whose articles are reviewed), which should be preferable to the indication of the date of the import. It will more easily identify also the authors of the article in question. Verdy p (talk) 01:44, 10 February 2016 (UTC)

For Commons too ?

Is this property is useful for the files from Commons? For example, see the item Q535 (Victor Hugo) who has a signature which is a file from Commons. I just want to know if we use this property to indicate that the source is from Commons in this case, or no. Thanks by advance. Automatik (talk) 19:23, 12 March 2013 (UTC)

Any property that can have a file attached to it is going to use a Commons file. So stating that the "Commons media file" is from Commons is redundant and unnecessary. :) Espeso (talk) 19:35, 12 March 2013 (UTC)

So no source is necessary in this case? Automatik (talk) 19:37, 12 March 2013 (UTC)

No. Any source information for the image/file itself should reside on the file's Commons page. Espeso (talk) 19:38, 12 March 2013 (UTC)

Thanks. Automatik (talk) 19:39, 12 March 2013 (UTC)

Deprecated

This property should be avoided: use instead stated in (P248). Current use is still allowed in order to give teh time to change the source information. More information about sourcing policy in Help:Sources. If you don't know how to use the current properties or if you have a problem to use them please add a comment on the talk page. Snipre (talk) 15:33, 4 July 2013 (UTC)

I do not agree. This property is still very useful for bots who import statements from Wikipedia but is unable to verify them using the sources in Wikipedia. It is also better than stated in (P248) for claims that only exists in Wikipedia like Commons category (P373). /Esquilo (talk) 06:02, 6 July 2013 (UTC)

Please comment the use of this property there. Snipre (talk) 08:27, 6 July 2013 (UTC)

Oh geez, yet another guideline discussion. I doubt I'll ever find my way around here at Wikidata. /Esquilo (talk) 14:46, 6 July 2013 (UTC)

There seems to be no consensus there, that this property should be deprecated at this point – P143 may probably be used to indicate source of trivial statements, such as XXX is a man/woman. I think it should not be changed before the end of the RfC. Littledogboy (talk) 15:24, 14 July 2013 (UTC)

There is a consensus to source statements with external sources, please see [[1]] and Help:Sources: there is no mention of imported from Wikimedia project (P143) so if the term of deprecated is not appropriated, there is at least a strong discussion about the use of this property and the correct behaviour is to stop to use it until the RfC Wikidata:Requests for comment/Sourcing requirements for bots is closed. Snipre (talk) 08:00, 15 July 2013 (UTC)

Like Esquilo said: imported from Wikimedia project (P143) is very useful for bots. For example: Imported form English Wikipedia. stated in (P248) would be irritating since Wikipedia is not a reliable source. But we need a documentation: Please use with qualifier retrieved (P813) etc. --Kolja21 (talk) 18:33, 23 December 2014 (UTC)

Useful for bots but not for wikidata: several wps have already anounced their opposition to use wikidata if no proper references are available. imported from Wikimedia project (P143) is typically the type of indication with no interest: who takes care of information coming from Russina or Chinese wikipedia ? Too few persons can read these wp articles to retrieve the good sources. So what is the purpose of WD: make bots happy or to see the data from WD used in WPs ? The problem is not coming from opposition between stated in (P248) or imported from Wikimedia project (P143): if you can't use stated in (P248), this means that your data is not sourced. Snipre (talk) 18:04, 4 January 2015 (UTC)

Use only for unreliable source

Is it correct to assume that all sources referenced by this property are unreliable, and that P143 exists primarily as an equivalent of stated in (P248) for generally unusable sources? --Yair rand (talk) 06:06, 10 February 2016 (UTC)

No. This property was initially used to source data from Wikipedia only. For all others cases we should use the model described in Help:sources. P143 will be deleted in the future when all statements will be correctly sourced. Snipre (talk) 12:29, 10 February 2016 (UTC)

So, should this property never have any value other than a Wikipedia? --Yair rand (talk) 13:09, 10 February 2016 (UTC)

I would say yes, this was the only value accepted at the beginning. Using this property as a regular property for sources will be a mess when extracting source data so don't used it in another case. Snipre (talk) 15:40, 10 February 2016 (UTC)

If the plan is to deprecate the property, there should be some signal to people not to use it. Having this appear on tens of thousands of items makes it really confusing if the idea is to get rid of it. --I9606 (talk) 19:06, 24 September 2016 (UTC)

Making the usage of this property clearer

This property was introduced back in the day when we started mass importing data from Wikipedia (and later other projects). We don't consider Wikimedia projects real sources and this property is used to track imported data so we can change the reference to a real source. This property should only be added (as a reference) when mass importing statements based on a Wikimedia project. Unfortunately this isn't very well documented so this property ended up being used in a lot of different (incorrect) ways. To make the usage clearer and make it more like Wikimedia import URL (P4656) I update the value type constraint so the target should always be a Wikimedia Foundation project (Q14827288) and I also changed the label in English and Dutch. I don't expect a lot of objections to this and would like to ask you to translate it also in your language. Multichill (talk) 20:00, 4 July 2018 (UTC)

I think the former label should be kept as an alias, at least if changing the label is not literally appending two words to the old one (for example in French: note the de → du change), so that it’s easy to find the property if somebody only knows the previous name. —Tacsipacsi (talk) 20:44, 4 July 2018 (UTC)

Makes sense. Also, should we try to make sure that we don't use just imported from Wikimedia project (P143) by itself, but also add Wikimedia import URL (P4656) with a permalink to the revision of the page?

It is possible to import data from a Wikipedia page that is different from the sitelink on the item itself (see for instance the Inverse Listeria tutorial).

@Pasleim: would you consider adding permalinks in references added by HarvestTemplates? − Pintoch (talk) 20:46, 4 July 2018 (UTC)

@Tacsipacsi: would love to make this property less findable actually. Too much bad usage. But yes, you're right.

Adding permalinks for new cases makes sense. I rather have that than having to also add the retrieval date. Multichill (talk) 20:59, 4 July 2018 (UTC)

HarvestTemplates adds permalinks now.--Pasleim (talk) 22:28, 4 July 2018 (UTC)

Created phab:T198839 for Pywikibot.

BTW, I also added DBpedia (Q465) as being acceptable. That's just data coming from Wikipedia so it should get a real source. Multichill (talk) 10:05, 5 July 2018 (UTC)

Thanks a lot Pasleim, that's fantastic!

Also, ArthurPSmith noted in Project chat that we should probably not say that this property is reserved to bots, and I agree - sometimes I find myself manually adding references with imported from Wikimedia project (P143) because the information itself is not clearly sourced in Wikipedia (which happens often for uncontroversial defining characteristics of the topic). − Pintoch (talk) 14:46, 5 July 2018 (UTC)

Description has to be brief so you might have some loss of information. Did that on purpose to have people back off. I'd rather have that than a description where people accidentally use it anyway. Multichill (talk) 13:14, 6 July 2018 (UTC)

Tidy up constraint violating usage?

Do we have bots that now tidy up the newly wrong uses of this reference property? I think we should at least do so for some of the values which are used on a larger scale, such as Virtual International Authority File (Q54919) for instance with 600k+ cases. In most cases, stated in (P248) would be the appropriate target property. --MisterSynergy (talk) 06:56, 5 July 2018 (UTC)

We were chatting a bit about this on irc yesterday and poking at it. My first goal is to prevent future incorrect usage. For this the labels, descriptions and usage instructions of this item have been updated and I updated Help:Source (feel free to improve). This has to drizzle down into the other languages. Do we update more things? Do we need to communicate this somewhere?

Before we start mass updating and changing things it might be worth to take a step back to look how we actually want to source it. Take for example Lucas Pieters Roodbaard (Q2586191)

• I thing we agree on stated in (P248), but it seems to be missing sometimes.
• Do we use reference URL (P854) or identifier property or maybe both? I would normalize on identifier property, although the downstream user will have to mess with formatter url's to construct the reference
• Do we use retrieved (P813) or publication date (P577) in combination with last update (P5017) (or all?)? For example the RKD entry provides "Ingevoerd op: 1993-12-16; Gewijzigd op: 2017-10-18", much better than retrieved
• I'm not sure why we're using subject named as (P1810), no mention of that on Help:Sources

Would be nice to get consensus here, properly document it and update a bunch of tools so we provide more consistent sourcing.

One thing to mention there is that references in in RDF work similar to Wikipedia. If you use the same reference for two statements, you'll just have one reference with two statements pointing at it. This only works if the references are exactly the same, so slightly different formatting or a different retrieved (P813) will make it multiple references. If we manage to normalize it more it will be much easier to measure how well sourced (how many different sources) and item has.

For starters we could run over VIAF to clean that part up and than move over to other subsets. Multichill (talk) 09:48, 5 July 2018 (UTC)

Thanks. I understand your points, but I think we should repair only one aspect at once. If we stick to the "imported from: VIAF" cases, I think we agree that we move them to the database reference format defined on Help:Sources#Databases, in spite of lacking reference qualifiers in many situations. In order to complement them properly to a form where all necessary reference qualifiers are in place, one would have to write a lot of code, so I think it would be easier to move the references without taking care whether they are "complete" (in terms of Help:Sources#Databases) or not. This would also have the advantage that very soon the move process shows up on many watchlists, so we could point to this discussion about the background of the move and the fact that P143 is no longer allowed to be used with values other than Wikimedia projects.

Actually, I think I have some code which could just move all P143:Qxxx to Pyyy:Qxxx per item in one edit. I just (still) don't have a botflag on my bot account :-) --MisterSynergy (talk) 10:11, 5 July 2018 (UTC)

Forgot to share the fun queries

• All sorts of incorrect links, very much work in progress. Useful to get an idea what is out there. Maybe we can make a constraint violations query based on this that actually completes
• Viaf imported from VIAF

I'm not in favour of quick and dirty. I don't think it's a lot of code because the logic can be quite simple. Go over all the items that have VIAF ID (P214)

• Grab viaf data
• Make a list of properties backed by the viaf item and generate the proper reference
• Go over all the current identifiers (including VIAF ID (P214) and if it's only backed by imported from Wikimedia project (P143), replace the reference with the proper reference

Wait to complete. Multichill (talk) 10:22, 5 July 2018 (UTC)

This more sophisticated approach might work with some references on some identifiers statements, but I'm not convinced that it is good for other claims as well (e.g. dates of birth). You really need to compare the statement to the source, and it depends on many factors how to do that. There may also be cases where the item does not have a VIAF claim, or no VIAF claim with the (unknown) VIAF ID from which was imported. What you actually suggest here is to re-do the entire reference import someone else hasn't properly done in the past, based on highly incomplete information about the past process.

IMO the move should be done rather soon, in order not to confuse users with "imported from Wikimedia project: VIAF" and the like. --MisterSynergy (talk) 10:42, 5 July 2018 (UTC)

Also, we should be careful about retrospectively adding VIAF references to existing claims - because VIAF harvests Wikidata, so we might add references to them for information that they actually got from us. − Pintoch (talk) 14:50, 5 July 2018 (UTC)

Do you know exactly which kind of data they harvest here? (I would be really interested!) To my knowledge, they rearrange links to Wikidata based on our VIAF ID (P214) claims and update that information roughly monthly, but I am not aware that there is more data taken... --MisterSynergy (talk) 19:08, 5 July 2018 (UTC)

I don't know exactly how VIAF works, but I assume they probably look at the other identifiers we store. For instance, suppose a Wikidata item contains an ISNI and a GND ID, incorrectly matched to each other. I would not be surprised if that would trigger a merge of the corresponding VIAF clusters, and then we would retrospectively source the ISNI and GND with a reference to the same VIAF id… But maybe they have mechanisms against that? One thing is sure: they do not rely solely on VIAF ID (P214) to match an item to a VIAF cluster - there are many cases where they become aware of the connection before Wikidata does - so that has to rely on some data, and probably not just labels and aliases (otherwise it would be really unreliable). − Pintoch (talk) 07:38, 6 July 2018 (UTC)

https://xkcd.com/978/ ? Multichill (talk) 13:11, 6 July 2018 (UTC)

Well, as long as we can today verify that according to a VIAF cluster some other external identifiers belong to a particular item, I don’t see a problem here. —MisterSynergy (talk) 20:59, 6 July 2018 (UTC)

Multichill's link summarizes the issue pretty well. I think we should not add references in this case for this reason - and anyway, this is beyond the scope of a migration from imported from Wikimedia project (P143) to VIAF ID (P214) − Pintoch (talk) 16:27, 8 July 2018 (UTC)

This sounds as if you want to remove those incomplete references, rather than move them to another property with or without completion. Is this correct? In my opinion it does not make sense to move them, if we don't want to complete them at any time. —MisterSynergy (talk) 07:16, 9 July 2018 (UTC)

This query gives an overview which kind of claims are referenced with imported from Wikimedia project (P143): Virtual International Authority File (Q54919) sources: query. For VIAF, there are indeed predominantly external identifiers where I could imagine that a substantial part of them could be completed with automated tools. @Multichill, are you working on code to try this? We should not risk that this repair gets stalled. —MisterSynergy (talk) 07:16, 9 July 2018 (UTC)

While I think it makes sense for this property to eventually be only used for Wikimedia projects, I don't think properties should be redefined when there is still so much data to change. It has always been acceptable to use this property for non-Wikimedia sources and lots of bots were approved which did that, from shortly after the property was created until as recently as last month. Now there are millions of references which will need updating (quite literally... English Heritage alone has over a million). Even a bot running 24/7 is likely to take months to do that many edits. I particularly object to changing the constraints before any cleanup has been done, because that has created millions of constraint violations and now most pages I load have multiple constraint violations, which cover the page in exclamation marks and cause the page to jump about while I'm trying to edit. It's really putting me off editing. - Nikki (talk) 19:56, 23 July 2018 (UTC)

Given that the constraint currently disrupts the workflows of some users, I am temporarily removing the constraint. Feel free to add it back once the bulk of violations have been cleaned with a bot. − Pintoch (talk) 10:43, 25 July 2018 (UTC)

As long as the labels contain “… Wikimedia project”, I don’t think we should remove the formal requirement (constraint) to use it with those values only. Editors need to learn this anyways, and it would probably be the best if the change is visible in items. Also, without the formal constraint, there is also even less motivation to repair anything here, and we risk to continue with the broken situation around this property. It is complicated to justify efforts for potentially millions of edits, for a change that might or might not happen in future. —MisterSynergy (talk) 10:56, 25 July 2018 (UTC)

Nobody (that I'm aware of) is saying we shouldn't migrate non-Wikimedia "imported from" references to better properties, so the (temporary) lack of a constraint shouldn't be a factor in whether to run a bot for that. I wouldn't object to reverting the changes to the label too until there's been enough cleanup, if people want either both changes or neither, but leaving the label as it is means people who are using it manually will hopefully stop using it for non-Wikimedia references (if they use it anyway despite the label, I don't think constraint violations will stop them). - Nikki (talk) 11:13, 27 July 2018 (UTC)

@Multichill, Pintoch, Nikki and others: You might have seen a couple of repairs done by my bot account on your watchlists recently, since I have started to repair certain references which used imported from Wikimedia project (P143) but shouldn’t. Until now, there was typically enough information about the source in the reference, so that I was able to reshape them to more standard forms as defined in Help:Sources. Now I’m about to deal with incomplete references (e.g. only imported from Wikimedia project (P143) and optionally retrieved (P813), but no external identifier or reference URL (P854)), where it is not so clear what to do. Summarizing (parts of) the discussion above, we have a couple of options for these incomplete imported from Wikimedia project (P143) references:

1. Don’t touch anything; this would leave us in an inconsistent situation where we don’t agree to put a formal constraint on the property, but the labels tell “imported from Wikimedia project”. Certainly not desirable.
2. For incomplete references, simply move imported from Wikimedia project (P143) to stated in (P248) reference qualifiers, and ignore the fact that important information is still missing after this change; this could rather quickly reduce the amount of mis-uses to reasonable numbers, but it asks for another, independent repair.
3. More sophisticated scripts could try to reveal the missing reference information and compare the value to the external reference, in order to make complete references during the move from imported from Wikimedia project (P143) to the stated in (P248) reference qualifier. This works probably in certain cases, but it is much more complicated to do; there is also Pintoch’s concern of citogenesis.
4. Simply remove incomplete references; that way, editors wouldn’t easily be able to track provenance of the information any longer; incomplete references, e.g. just “stated in: VIAF”, are still better than no references at all.

Any ideas how to proceed? I am still in favor of the second option, which seems to be the least bad option, and it is a much more doable task compared to the third option. To provide numbers for VIAF: we talk about 176.000 statements with references only containing imported from Wikimedia project (P143): Virtual International Authority File (Q54919) and retrieved (P813) with some data, and 430.000 statements with references imported from Wikimedia project (P143): Virtual International Authority File (Q54919) standalone. Similar numbers can be found for a couple of other identifiers, such as ISNI (P213). Any comments? Btw. who else is actively working on this task? —MisterSynergy (talk) 23:26, 6 August 2018 (UTC)

There are already plenty of references using only stated in (P248), so the second option won't create a new problem. I'm perfectly happy for you to do that for the majority of them. One thing I'm not sure about is external identifiers themselves. It seems pointless to add references to external identifiers saying that the value is stated in itself, unless they explicitly link back to Wikidata or there's no formatter URL and you need to provide a link to the dataset. Otherwise every external identifier would be automatically self-sourcing and adding explicit references would just be a waste of time and space/bandwidth. In those cases I would be in favour of removing the P143 references instead of migrating them.

- Nikki (talk) 10:32, 7 August 2018 (UTC)

References on identifier claims are a difficult problem. On the one hand there it is indeed rarely mentioned explicitly in the external source to which Wikidata item it belongs (exceptions like VIAF exist, of course), but on the other hand someone has somehow managed to extract this information and it is useful to have some indicator at the identifier claim to track its provenance. Any thoughts? Should we ask at Project chat for more input? —MisterSynergy (talk) 16:01, 9 August 2018 (UTC)

This isn't an easy problem. Let's focus for viaf for now to at least get a lot of stuff done?

1. If VIAF ID (P214) and the item has a backlink, source it based on viaf. Probably nice to have some sort of indication that it's derived from the backlink. Any suggestion on how to best model that?
2. Go over all the other properties that are on the Wikidata item and the viaf item and source it to the viaf item (using stated in, viaf id & retrieved)

Is that a doable approach? Multichill (talk) 15:57, 11 August 2018 (UTC)

Not sure whether I understand #1 correctly. Regarding VIAF, the references to update are—with only little exceptions—either on external-id claims or on sex or gender (P21) claims (query). I currently verify the references on external-id claims, and re-build them to P248+P214+P813 if the identifiers to source are in the VIAF profile linked from the item, and the VIAF-profile links back to the Wikidata item as well. Later, I can do the same with the P21 claims.

More in general: we still have around 5.7M references to fix, with VIAF being responsible for around 10% of the total number. Other important items, which are more than 10.000 times used as values in imported from Wikimedia project (P143) references, are (descending by number of references): English Heritage (Q936287), Virtual International Authority File (Q54919), Wiki Loves Monuments monuments database (Q28563569), GeoNames (Q830106), JPL Small-Body Database (Q4026990), China Biographical Database (Q13407958), NCBI Gene (Q20641742), International Standard Name Identifier (Q423048), Museu Nacional d'Art de Catalunya (Q861252), MusicBrainz (Q14005), catalogo.beniculturali.it (Q52897564), Quora (Q51711), Google Knowledge Graph (Q648625), Historic Scotland (Q111854), Freebase Data Dumps (Q15241312), Kinopoisk (Q2389071), Danish Film Database (Q16323348), Narodowy Instytut Dziedzictwa database (Q43301933), BabelNet (Q4837690), Autores.uy (Q22975461), Minor Planet Center (Q522039), Consortium of European Research Libraries (Q1127581), DBpedia (Q465), Wiki Loves Monuments Italia (Q19960422), Cadw (Q1025341), National Inventory of Architectural Heritage database (Q55020794), Mix'n'match (Q28054658), Hansard 1803–2005 (Q19204319), OpenStreetMap (Q936), Natural History Museum, London (Q309388), directory of German Library Codes (Q28657655), Commons Creator page (Q24731821), DOI.org query endpoint (Q28946522), Open ISNI for Organizations (Q28527677), Ontology Lookup Service (Q22230760), Bechdel Test Movie List (Q45150204), Yahoo! JAPAN Talent Database (Q27048656), and Bibliothèque nationale de France (Q193563). —MisterSynergy (talk) 16:23, 11 August 2018 (UTC)

An update: use of Virtual International Authority File (Q54919) as value for imported from Wikimedia project (P143) in references has now been repaired as much as automatically possible. When I started this in July, there were more than 600k of such references, and these 11.5k ones are still remaining. In most of those remaining cases, the information to be sourced is no longer part of the VIAF cluster; in a smaller amount of cases, there is no VIAF identifier any longer in the items; only very few of the remaining cases could probably be repaired automatically, so manual work is now required. There is also a property statistics which indicates that most of the remaining references are located in a Bibliothèque nationale de France ID (P268) or IdRef ID (P269) statement.

I now plan to look at one of the other values listed in my comment from 11 August on this page. However, progress is really slow here, and we still have 5.1 million references to repair. It’d be great if others could also invest some effort here. —MisterSynergy (talk) 14:02, 15 November 2018 (UTC)

GeoNames

The change [2] make a constraint to GeoNames ID (P1566). The constraint is about imported from Wikimedia project (P143) -> GeoNames (Q830106). I think all statements with P1566 have the same reference. Xaris333 (talk) 14:26, 6 July 2018 (UTC)

Freebase and DBpedia

Many statements have as reference imported from Wikimedia project (P143)= Freebase Data Dumps (Q15241312) or imported from Wikimedia project (P143)=DBpedia (Q465). Should we change those references to stated in (P248)? --Pasleim (talk) 18:57, 27 December 2018 (UTC)

Yes, I think they should be moved. Two sections above there is a (stale) discussion about other values with the same problem. Basically anything which is not an instance of Wikimedia project should be moved, but it is often not so simple to do this in my opinion. --MisterSynergy (talk) 23:37, 27 December 2018 (UTC)

I don’t know where Freebase data comes from, but DBpedia is Wikipedia data, just stored on another domain, and as such, it has almost the same reliablity—although a bit even lower, as one can click on the sitelink (and hopefully find the statement with a reference next to it), but it’s not the case for DBpedia, so there is no trace where the data actually comes from. I think stated in (P248) is for somewhat reliable sources, which is clearly not true for DBpedia. —Tacsipacsi (talk) 00:05, 30 December 2018 (UTC)

Enabling the value type constraint

@MisterSynergy: My bot task is complete, thanks for the help with your own bot. According to your query, it seems that the remaining problematic values would all violate the current type constraint on stated in (P248) (they are mostly organizations). So I think we could enable the value type constraint now - this will still flag a lot of references as having an issue, but rightfully so: these reference genuinely need a fix that is more involved than just switching properties (the value should be fixed too). − Pintoch (talk) 17:13, 17 May 2019 (UTC)

 Support, of course. There will be ~500.000 constraint violations, of which I plan to fix some more. However, I am awaiting other users' input as the values need to be moved as well… —MisterSynergy (talk) 20:21, 17 May 2019 (UTC)

P1037 Wolfgang Grupp

Hi, there is a weird statement for this property that should be removed: P1037 (director / manager) with Q2589769 (Wolfgang Grupp) as its value. Sorry, I am not auto-confirmed, so I can't do it. Clou (talk) 02:16, 19 March 2024 (UTC)