Open main menu

Property talk:P2580

Active discussions


Baltisches Biographisches Lexikon digital ID (former scheme)
person's ID at Baltisches Biographisches Lexikon digital encyclopedia
  Distinct values: this property likely contains a value that is different from all other items. (Help)
List of this constraint violations: Database reports/Constraint violations/P2580#Unique value, hourly updated report, SPARQL (every item), SPARQL (by value), SPARQL (new)
  Single value: this property generally contains a single value. (Help)
List of this constraint violations: Database reports/Constraint violations/P2580#Single value, hourly updated report, SPARQL, SPARQL (new)
  Type “human (Q5), family (Q8436): element must contain property “instance of (P31)” with classes “human (Q5), family (Q8436)” or their subclasses (defined using subclass of (P279)). (Help)
Exceptions are possible as rare values may exist.
List of this constraint violations: Database reports/Constraint violations/P2580#type Q5, Q8436, SPARQL, SPARQL (new)
  Conflicts with “instance of (P31): Wikimedia disambiguation page (Q4167410): this property must not be used with the listed properties and values. (Help)
List of this constraint violations: Database reports/Constraint violations/P2580#Conflicts with P31, hourly updated report, search, SPARQL, SPARQL (new)
  Format “[A-Za-z][-.0-9A-Za-z]+: value must be formatted using this pattern (PCRE syntax). (Help)
Exceptions are possible as rare values may exist.
List of this constraint violations: Database reports/Constraint violations/P2580#Format, SPARQL, SPARQL (new)

{{Autofix}} {{Autofix}} {{Autofix}}

  Pattern ^(0000)(000[0-4])(\d\d\d\d)(\d\d\d[\dX])$ will be automatically replaced to \1 \2 \3 \4 and moved to ISNI (P213) property.
Testing: TODO list


Please notify projects that use this property before big changes (renaming, deletion, merge with another property, etc.)


List humans having property P2580

SELECT ?human ?humanLabel ?fatherLabel ?motherLabel ?dateOfBirth ?placeOfBirthLabel ?dateOfDeath ?placeOfDeathLabel 
?bblid ?isni ?viaf ?gnd ?geni
    ?human wdt:P31 wd:Q5 .      
    ?human wdt:P2580 ?bblid .     
    OPTIONAL{?human wdt:P22 ?father .}
    OPTIONAL{?human wdt:P25 ?mother .}
    OPTIONAL{?human wdt:P569 ?dateOfBirth .}
    OPTIONAL{?human wdt:P19 ?placeOfBirth .}
    OPTIONAL{?human wdt:P570 ?dateOfDeath .}
    OPTIONAL{?human wdt:P20 ?placeOfDeath .}
    OPTIONAL{?human wdt:P213 ?isni .}
    OPTIONAL{?human wdt:P214 ?viaf .}
    OPTIONAL{?human wdt:P227 ?gnd .}
    OPTIONAL{?human wdt:P2600 ?geni .}
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en" }
} ORDER BY ?dateOfBirth

Try it!

User:TweetsFactsAndQueries, Lucas, if there are multiple ?isni then one gets two rows, do you know how one could have multiple values in one table cell? 11:07, 23 April 2018 (UTC)

GROUP BY the other variables and use GROUP_CONCAT for the columns with potential duplicate values:
?human ?humanLabel ?fatherLabel ?motherLabel ?dateOfBirth ?placeOfBirthLabel ?dateOfDeath ?placeOfDeathLabel
    ?human wdt:P31 wd:Q5 .      
    ?human wdt:P2580 ?bblid .     
    OPTIONAL{?human wdt:P22 ?father .}
    OPTIONAL{?human wdt:P25 ?mother .}
    OPTIONAL{?human wdt:P569 ?dateOfBirth .}
    OPTIONAL{?human wdt:P19 ?placeOfBirth .}
    OPTIONAL{?human wdt:P570 ?dateOfDeath .}
    OPTIONAL{?human wdt:P20 ?placeOfDeath .}
    OPTIONAL{?human wdt:P213 ?isni .}
    OPTIONAL{?human wdt:P214 ?viaf .}
    OPTIONAL{?human wdt:P227 ?gnd .}
    OPTIONAL{?human wdt:P2600 ?geni .}
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en" }
GROUP BY ?human ?humanLabel ?fatherLabel ?motherLabel ?dateOfBirth ?placeOfBirthLabel ?dateOfDeath ?placeOfDeathLabel
ORDER BY ?dateOfBirth
Try it! --TweetsFactsAndQueries (talk) 11:15, 23 April 2018 (UTC)
Thank you! 20:43, 25 April 2018 (UTC)

List humans having property P2580 and no other identifier

# items with property P2580 and no other identifiers
SELECT ?item ?itemLabel ?value ?st
       SELECT *
       { ?item wdt:P31 wd:Q5 .
          ?item wdt:P2580 ?value ; wikibase:identifiers 1
       LIMIT 1000
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
ORDER BY ?value

Try it!

List humans having property P2580 and no ISNI

SELECT ?human ?humanLabel ?fatherLabel ?motherLabel ?dateOfBirth ?placeOfBirthLabel ?dateOfDeath ?placeOfDeathLabel 
?bblid ?isni ?viaf ?gnd ?geni
    ?human wdt:P31 wd:Q5 .      
    ?human wdt:P2580 ?bblid .     
    OPTIONAL{?human wdt:P22 ?father .}
    OPTIONAL{?human wdt:P25 ?mother .}
    OPTIONAL{?human wdt:P569 ?dateOfBirth .}
    OPTIONAL{?human wdt:P19 ?placeOfBirth .}
    OPTIONAL{?human wdt:P570 ?dateOfDeath .}
    OPTIONAL{?human wdt:P20 ?placeOfDeath .}
    MINUS {?human wdt:P213 ?isni .}
    OPTIONAL{?human wdt:P214 ?viaf .}
    OPTIONAL{?human wdt:P227 ?gnd .}
    OPTIONAL{?human wdt:P2600 ?geni .}
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en" }
} ORDER BY ?isni ?viaf ?dateOfBirth

Try it!


Mix'n'match catalogue

User:Jonathan Groß found you at I think I have also seen a catalog for "Baltisches Biographisches Lexikon digital ID" Property:P2580, but cannot find it at . Could you help? 12:43, 23 April 2018 (UTC)

@ This - ? --Tagishsimon (talk) 13:33, 23 April 2018 (UTC)
Tagishsimon - Yes! Just a minute ago I found it at the Property page. Do you know why it is not listed at ? I see 169 then 182 - no 177. 13:52, 23 April 2018 (UTC)
@ Seems to be filed under Biography - ... not clear how Magnus draws the distinction. And I lied, below, and created some more BBLIds whilst having a tea-break :) --Tagishsimon (talk) 13:56, 23 April 2018 (UTC)
Thanks for the info and turning a statement about the future into a "lie" ;-) 15:12, 23 April 2018 (UTC)

Mix'n'match create more items

User:Tagishsimon you created an item with mix'n'match and in the 4th edit added BBLd ID (P2580) [1]. Can you create more BBLd items? 13:27, 23 April 2018 (UTC)

Probably not. I mix'n'match when I've run out of inspiration. Right now busy with stuff. Sorry. --Tagishsimon (talk) 13:33, 23 April 2018 (UTC)
Thanks! 13:52, 23 April 2018 (UTC)

Mix'n'match update connections

sync manually :

connections here, but not on Wikidata

Tagishsimon it says "48 connections here, but not on Wikidata" - this needs QS (QuickStatements) and Widar-login - could you do that? "" 15:12, 23 April 2018 (UTC)"

@ I'm not following you; where does it say that? Link please. I have Widar, so can do when I understand. Might be later tonight. Magnus has fixed the name of BBL in M'n'M. --Tagishsimon (talk) 15:54, 23 April 2018 (UTC)

Tagishsimon and then click on "Update Wikidata". In the list of statements I saw some before that did not look good and work on the items manually. Now the list looks fine. Please scroll through, all items should be in the form "Abcde-Abcde optional(xyz)-YYYY-YYYY", where the last two are year of birth and of death. If there is no YYYY-YYYY please remove the statement before running the list. Please tell here when it has been done, I can then check your edit hist and click each item and try to add ISNI, GND ID, VIAF if not present. 16:44, 23 April 2018 (UTC)

@ Done. I imagine it might take some time before mix-n-match updates its understanding of the situation. --Tagishsimon (talk) 16:46, 23 April 2018 (UTC)
Tagishsimon, I thought I could have a break, but then I saw you run the QS-list, so I clicked through all of them, added some more extIDs. MnM doesn't show the section "connections here, but not on Wikidata" - so I assume it means there are none. 17:50, 23 April 2018 (UTC)

Tagishsimon, can you run these:

Q36538626	P2580	"Beggrow-Hartmann-Olga-1862-1922 "
Q2646847	P2580	"Brasse-Forstmann-Alice-1903 "
Q52151754	P2580	"Behr-Helmut-1903-1981 "

I would like to know what QS does with the spaces. Yes, they are required, see 20:26, 23 April 2018 (UTC)

QS1 returns an error. QS2 trims the final space off it. You cannot put in the string by hand if there's a trailing space. So it's not right now looking good for these. --Tagishsimon (talk) 20:41, 23 April 2018 (UTC) --Tagishsimon (talk) 21:14, 23 April 2018 (UTC)

connections on Wikidata, but not here

Also 48, no idea what can be done. 15:12, 23 April 2018 (UTC)

User:Magnus Manske - it says "Done! 46 IDs from Wikidata not found in Mix'n'match." - How can they be transferred to MnM? 17:51, 23 April 2018 (UTC)
User:Magnus Manske - or maybe they shall be deprecated in WD because not present on site anymore - but how to find them? 00:07, 25 April 2018 (UTC)
Last update seems to have added them? --Magnus Manske (talk) 14:55, 25 April 2018 (UTC)

@Magnus Manske: - dont think so. Here's the result I got a minute ago. And what's with the Wikidata says, M'n'M says? --Tagishsimon (talk) 15:25, 25 April 2018 (UTC)

  • Done!
  • 48 IDs from Wikidata not found in Mix'n'match.
  • 6 mismatches between Wikidata and Mix'n'match
  • Enty #9929029: Wikidata says Q36538626 [Q36538626], Mix'n'match says Q36538626 [Q36538626]
  • Enty #9929033: Wikidata says Q52151754 [Q52151754], Mix'n'match says Q52151754 [Q52151754]
  • Enty #9929317: Wikidata says Q2646847 [Q2646847], Mix'n'match says Q2646847 [Q2646847]
  • Enty #9929095: Wikidata says Q52152633 [Q52152633], Mix'n'match says Q52152633 [Q52152633]
  • Enty #9929275: Wikidata says Q50641037 [Q50641037], Mix'n'match says Q50641037 [Q50641037]
  • Enty #9931863: Wikidata says Q12358822 [Q12358822], Mix'n'match says Q12358831 [Q12358831]
OK, I fiddled with the autoscraper and got ~700 new entries, but still ~30 from WD not in Mix'n'match. Not sure why. Details here. --Magnus Manske (talk) 12:52, 26 April 2018 (UTC)

Trailing space in IDs

Q36538626	P2580	"Beggrow-Hartmann-Olga-1862-1922 "
Q52152633	P2580	"Bergholz-Nikolaus-James-1902-1977 "
Q2646847	P2580	"Brasse-Forstmann-Alice-1903 "
Q52153094	P2580	"Engelhardt-Karl-1852-1930 "
Q52151754	P2580	"Behr-Helmut-1903-1981 "
Q50641037	P2580	"Bordelius-Max-v.-1886-1964 "
Fixed the IDs on Mix'n'match.--Magnus Manske (talk) 15:00, 2 May 2018 (UTC)
@Magnus Manske: - thanks, but there's still an issue, described at --Tagishsimon (talk) 16:18, 2 May 2018 (UTC)

fundamental change in access URLs

Please note that the access URL has recently (2018-09-04) changed to an ISNI-derived scheme cf. Unfortunately, no direct mapping from previous values to current ones seems to exist. -- Gymel (talk) 19:00, 12 September 2018 (UTC)

  • We already store ISNI. Please don't delete valid entries in the old format. --- Jura 19:29, 12 September 2018 (UTC)
  • Reading, they say that they have converted 1,153 ids to ISNI, but I'm having trouble seeing what their long-term plan is. Do they plan to change all ids to ISNI eventually? What about entries that have no ISNI equivalent? Will they maintain information on the old ids? Should we (as Jura1 suggests) stick with their old ids because storing ISNIs would be redundant for us? Is anyone in contact with bbld? According to this query, there are 109 items for which we know both BBLD and ISNI, but all but 4 appear to be post-conversion. Bovlb (talk) 15:44, 13 September 2018 (UTC)
I have no direct communications with but have been told that the long-term plan is to convert all URLs to the ISNI-based scheme. The current situation seems to be a fluid mix of both schemes: The old "IDs" cease to exist exactly in the moment when the entry is associated with an ISNI... So I see the rise of another instance of the discussion whether Wikidata should take up the task of documenting "historic" identifiers of (still living but rather carelessly operating) external projects in order to faciliate third parties a future conversion of their link collections. -- Gymel (talk) 19:12, 13 September 2018 (UTC)
That's ... not how identifier schemes are supposed to work. :( Thanks for the explanation. Bovlb (talk) 21:58, 13 September 2018 (UTC)
  • As we already have a property for ISNI, changing some values in a random manor to ISNI seems inconsistent. We are here to provide structured data and this includes stable identifiers. It seems that some premature changes need fixing. BTW, when editing this property, please bear in mind not to help block evasion. --- Jura 08:58, 25 September 2018 (UTC)
  • Look here. Don't know, how to change properties to make adequate link from Wikidata pages immidiately --Arachn0 (talk) 07:09, 6 October 2018 (UTC)
    • This property can't link to that website any more as they changed their website structure. For ISNI, please use the ISNI property. --- Jura 08:05, 6 October 2018 (UTC)
      • I think it can work for both variants: both for digits (for example Q2116) and for different symbols as a part of url-adress (for example Q89382). But sometimes it doesn't work. For example, Q445283 (for different symbols). I think the problem is either in Property:P1793 or in Q21502404. Could You help to fix it?--Ksc~ruwiki (talk) 20:19, 8 October 2018 (UTC)
        • Sure, I will try to do some cleanup. The problem with this property is that we keep getting disrupted by what appears to be a globally blocked user. Please avoid furthering any such efforts. If you want to make use of the ISNI scheme in ruwiki, please use its property (ISNI (P213)) instead. I will check if it's available consistently. --- Jura 08:47, 9 October 2018 (UTC)
          • Thank You! And what do you mean by "cleanup"? I am not in course of situation with the user You mentioned. In fact I am not very active participant in Wikidata discussions (not in Russian I mean). The major thing I'm relly inerested in is propper functioning of Wikidata, when it's statements import to Wikipedia (and some else aspects of course). So dead or just nonfuctioning links are not good both for editors and readers of Wikipedia at any languge. In my opinion if a link can be fixed it should be fixed. At the same time You are right, of course, saying rules should be followed. --Ksc~ruwiki (talk) 21:09, 9 October 2018 (UTC)
            • We need to get this back in line with the property definition. It's currently used to convey that Wikidata doesn't provide stable data while actually some website just started using other identifiers. Obviously, it's regrettable that I got drawn into a general different of some user with Wikidata, but at some point I suppose everyone will be and we need to ensure the stability of our data. --- Jura 13:21, 13 October 2018 (UTC)

Wikidata:Property proposal/Baltisches Biographisches Lexikon Digital ID (new scheme)

There is now a property proposal for the new 16-digit URL scheme of this database. Please support this proposal for quick property creation, in order to avoid further damage to this one. —MisterSynergy (talk) 18:03, 4 January 2019 (UTC)



"Wikidata publishes fake information about the BBLD IDs, the regex stated in Property:P2580 is an invention by Wikidata as is the name stated there. There is no such thing as "former scheme".

--Superbass (talk) 10:45, 20 January 2019 (UTC)

Siehe dazu de:Diskussion:Wikidata#Kritik_durch_Baltische_Historische_Kommission. Kurzfassung: Besagte BBLD-Seite ignorieren. Steak (talk) 12:14, 20 January 2019 (UTC)

How to proceed

I am aware that there has been some unfortunate trouble around this property. Dwelling on this seems counter-productive, and there are reasons to move forward.

Can we agree on the following:

  • The BBLD is the issuing authority for the IDs of this property
  • The BBLD "former scheme" was a combination of person name and (where available) dates
  • The BBLD is replacing these IDs with ISNI, where possible
  • The "former scheme" IDs are becoming increasingly meaningless, as the "former" URLs fail to work; even the current "Wikidata property example" link is broken
  • The "former scheme" IDs are, therefore, increasingly relevant only for historic reasons, which are probably few
  • The BBLD is publishing a (live) BEACON file of all currently used IDs
  • As it stands, the property is of little practical use

Therefore, it seems to me that the reasonable approach is:

  • to use the IDs from the BEACON file as values of this property
  • optionally, to preserve the "former scheme" IDs somehow (a qualifier?), if that is wanted
  • rename this property to remove the "former scheme" label to indicate that the IDs are current

I volunteer to keep the associated Mix'n'match catalog up-to-date accordingly. --Magnus Manske (talk) 11:54, 28 February 2019 (UTC)

Identifiers, i.e. URL + string, are meant to be stable. It is useful to have resources provided under the URLs, but not necessary. Why should we not stick to these very basic linked data principles in this case when we otherwise do so? Certainly not because of the excessive trolling we have experienced in the past month.
I clearly prefer to have a new property for the new URL + new identifiers (beyond the native BBLD format and ISNI format, some of them also have GND format or ISBN format; maybe we see other "external" formats in the future as well) as in #Wikidata:Property proposal/Baltisches Biographisches Lexikon Digital ID (new scheme), and set this one and its identifier values back to where it was before BBLD changed everything on their side, i.e. pre September 2018 or so. Unfortunately we have seen a lot of trolling from a globally banned user regarding this property, thus nobody is willing to maintain it in useful shape right now. —MisterSynergy (talk) 13:23, 28 February 2019 (UTC)
  • Yes, I think we should store only stable identifiers on Wikidata.
Occasionally it happens that such identifier are no longer used by the source website or the source website goes offline (some websites are only short term projects or their internal workings lead to cease them operating).
I think we should attempt to see beyond a presentist approach. Some unfortunate edits we already had need to be undone. Unfortunately the website and its promoters seems to take up too much of the Wikidata volunteer time and anything related to it appears to be hard to maintain. Maybe we should discontinue support for it entirely.
Did I follow it correctly: is part of the data (added by Magnus Manske and/or some promoter or the website) based on data received from them directly now called "fake data" by them? --- Jura 13:43, 3 March 2019 (UTC)
It appears to me that their BEACON file contains all their current IDs. It also appears they are slowly changing them to ISNI, so that list is not stable. Neither are the identifiers, unless they are ISNI format. I would have no problem just leaving this property as it is, and creating a new one, but honestly what is the use case for keeping old, non-functional IDs around? --Magnus Manske (talk) 09:33, 5 March 2019 (UTC)
Identifiers are there to identify entities in the first place, and people rely on their stability. They do not become invalid just because the resource vanished (side note: it would have been appropriate if BBLD had provided a redirect service from the old URLs to the new ones, but this is unfortunately not the case).
So the use case is: assume someone has used the old BBLd identifier from Wikidata; now both the formatter URL and the identifier change ... so do we identify another subject now? No, we don't, although it appears that we do. However, if we keep this old property P2580 and create a new one and use both identifiers in items, it is totally clear that both BBLd/BBLD identifiers identify the same entity, and external users can gradually move from the old to the new resources.
Btw. please note that there are not only ISNI-style identifiers in the new scheme, there are also several GND-style identifiers and some ISBN-style identifiers. Not sure what else is to come here. For changing values in the new scheme, we can use multiple values in a new property and ranks to manage the situation. --MisterSynergy (talk) 09:51, 5 March 2019 (UTC)
Delete the property. It's a private project (mis)using Deutschbaltisches biographisches Lexikon : 1710 - 1960 / im Auftr. der Baltischen Historischen Kommission begonnen von Olaf Welding und unter Mitarb. von Erik Amburger und Georg von Krusenstjern hrsg. von Wilhelm Lenz - See Deutschbaltisches Biographisches Lexikon 1710-1960 (Q50624788) (see also Cover and DNB) . --Succu (talk) 19:04, 17 March 2019 (UTC)
Reasonable aproach is to use the IDs from the BEACON file as values of this property. Links generated now leads to, it's contains only ask for donation. Looks fakely, in't it ? Arachn0 (talk) 07:49, 24 March 2019 (UTC)
More game playing: BBLD ID Spezifikation. Ohne Worte. --Succu (talk) 19:49, 25 March 2019 (UTC)
Der Vorschlag von Magnus Manske hat schon deutlich etwas für sich (zumal er die beklagte künftige Arbeitslast auf sich ziehen will...), schließlich muss es in der Sache selbst vorwärts gehen, unabhängig von mehr oder weniger nachvollziehbaren Befindlichkeiten, aus deren Bewertung man sich als Dritter besser raus hält.--Kresspahl (talk) 14:06, 17 June 2019 (UTC)
  • It seems that we get also sorts of stuff that shouldn't be using this property gets add with it. As we can't seem to agree on a property for ISNI, I'm moving them over to the ISNI property. There are also a few other that got mixed into this one needing cleanup. --- Jura 15:50, 21 July 2019 (UTC)

Revert autofixes?

Vandalism - mass removal of BBLD IDs

In your reccent vandalism in Wikidata you mass removed BBLD IDs. It is well documented in d:Property_talk:P2580 that the property is used in dewiki, ruwiki, etwiki, lvwiki etc. Your vandalism removed external links from these Wikipedias. Ping user:Arachn0 00:41, 23 июля 2019 (UTC)

It's not vandalism - links on site really exists. Masque at d:Property_talk:P2580 not adequate -- Arachn0 обс 16:58, 23 июля 2019 (UTC)

User:Arachn0 - could you undo ? 09:02, 26 июля 2019 (UTC)

No, I don't know how to do it -- Arachn0 обс 14:19, 28 июля 2019 (UTC)

User:Arachn0, the commands must be deleted. :

 {{Autofix|pattern=(0000)(000[0-4])(\d\d\d\d)(\d\d\d[\dX])|replacement=\1 \2 \3 \4|move_to=P213}}

There was no consensus for this. He just hopped it, and Ivan followed the orders and removed ~ 2200 IDs. 00:07, 29 июля 2019 (UTC)

Yesterday you broke hundreds of links in at least five Wikipedias

Yesterday you broke hundreds of links in at least five Wikipedias. Please fix this as soon as possible. 09:24, 23 июля 2019 (UTC)

  • Could you provide link to some edit? — Ivan A. Krestinin 22:52, 23 июля 2019 (UTC)
    • 2220 removals of IDs that really exist on - The IDs are also used by ruwiki, dewiki, lvwiki, frwiki, ping: user:Arachn0 20:14, 24 июля 2019 (UTC) : Futhermore: "move to ISNI" can insert mistakes, because it can be valid in but not in anymore, sometimes ISNI reassignes IDs to new persons, due to first mix up two persons and then later split out the original item for the ID - then then "invading person" has the old ID, but in BBLD the old person may still have the old ID. It is not 1:1 20:18, 24 июля 2019 (UTC)

When will you fix it? user:Arachn0 spent time on adding the IDs, and you with your bot removed many of them - and did remove links in several Wikipedias. 09:00, 26 июля 2019 (UTC)

Could you discuss this on d:Property talk:P2093? — Ivan A. Krestinin 15:46, 26 июля 2019 (UTC)
No. Please just revert. Если вы разорвете ссылки в 5 Википедиях, то, возможно, вам стоит сначала обсудить это? 720 pages broken in dewiki: 00:06, 29 июля 2019 (UTC)

Jura1 did vandalize in September 2018, Magnus Manske then had to run an extra batch (example). Now Jura1 and you broke the links again. Это должно быть отменено. 00:16, 29 июля 2019 (UTC)

You broke the beacon - ~2200 missing .... 22:36, 29 июля 2019 (UTC)

I have no complete vision of the situation. Need I execute some actions, for example, revert something? — Ivan A. Krestinin (talk) 05:33, 31 July 2019 (UTC)


The IDs used for this property are not stable. Some IDs consist of names, others of name+date, VIAF or GND. They are changing regularly. Since the BBLD user seems to be active again I have requested the deletion of this property to put an end to this chaos: WD:PFD#Property:P2580. --Kolja21 (talk) 14:14, 31 August 2019 (UTC)

Return to "P2580" page.