User talk:Dcflyer

From Wikidata
Jump to navigation Jump to search


I'm confused by your edit summary and revert here. What purpose does "inception" serve there that "date of official opening" does not, especially with less precision (year versus day)? Thanks, Pi.1415926535 (talk) 04:10, 1 April 2021 (UTC)Reply[reply]

@Pi.1415926535, you left out the fact that the above revert was the undoing of your revert. The properties inception (P571) and date of official opening (P1619) are distinct concepts; inception is when an entity came into existence or was formed, while date of official opening, per its en label, is the "date or point in time an event, museum, theater etc. officially opened." The latter property's proposal was made as an addition to the property officially opened by (P542). In addition to the fact that an entity cannot logically have a date of official opening, grand opening, etc. without previously or simultaneously having come into existence, queries for the inception (P571) of items would be negatively affected if P1619 was solely used as item statements.

13,760 items with the instance of railway station (Q55488) currently utilize both of these properties: N.B.: an item with a date output of January 1, XXXX, is for the year XXXX, e.g., January 1, 1976 = 1976. ⚊⚊ DCflyer (talk) 10:32, 1 April 2021 (UTC)Reply[reply]

I'm still confused, sorry. So you're saying that P571 and P1619 should both exist for railway stations, but that P571 should be the year and P1619 the date? To me that seems like pointless duplication. There are a number of different times you could peg as the station coming into existence - when it was first proposed, when construction was approved, when construction began, when construction was completed, or when it opened (which is sometimes before construction is completed). All of the current uses of P571 for railway stations are simply duplications of the year of P1619, which doesn't seem to hold any value. Pi.1415926535 (talk) 17:41, 1 April 2021 (UTC)Reply[reply]
I did not say that "P571 and P1619 should both exist for railway stations, but that P571 should be the year and P1619 the date."
inception (P571) : "date or point in time when the subject came into existence as defined" = owl:equivalentProperty ,
date of official opening (P1619) : "date or point in time an event, museum, theater etc. officially opened" ≈
Two different concepts. ⚊⚊ DCflyer (talk) 01:34, 2 April 2021 (UTC)Reply[reply]
You're still not answering the questions: what does coming into existence mean for a train station, and why add it with only a year (as you have done) when the exact opening date is know? Pi.1415926535 (talk) 19:02, 9 April 2021 (UTC)Reply[reply]
A train station coming into existence: the date the physical structure was built (completed). Official opening: the date it officially opened to the public and/or commenced service, which for some classes appears to be the same as service entry (P729). ⚊⚊ DCflyer (talk) 19:16, 9 April 2021 (UTC)Reply[reply]

Deleting data[edit]

Please do not delete data. Marking data as "deprecated", then immediately deleting it because it is "deprecated" is unethical. --EncycloPetey (talk) 20:15, 8 May 2021 (UTC)Reply[reply]

Data is on Library of Congress Classification (works and editions) (P8360). Your false accusation is bad faith and unethical. ⚊⚊ DCflyer (talk) 20:24, 8 May 2021 (UTC)Reply[reply]
You have not explained why you marked data as "deprecated" then removed the data for being "deprecated". Please cease the removal of data. --EncycloPetey (talk) 20:32, 8 May 2021 (UTC)Reply[reply]
Adding an undiscussed property constraint to justify your actions is also unethical. --EncycloPetey (talk) 20:34, 8 May 2021 (UTC)Reply[reply]

TikTok username as a qualifier[edit]

"It is it not also used as a main value?"

It is, but this constraint raises a warning when it is used as a qualifier. (See "social media followers" on Among Us (Q96417649)) I don't know much about property constraints. AntisocialRyan (Talk) 19:18, 24 August 2021 (UTC)Reply[reply]

My apologies for not adding the property scope (P5314) as qualifier (Q54828449). I added the property scope constraint (Q53869507) (as main value (Q54828448)), because the lack of property scope constraint for property constraint (P2302) was itself creating a constraint violation. I did see that out of 3,696 uses of TikTok username (P7085), 42 are as qualifier; as well as 17 as reference. I can add property scope as reference (Q54828450), if you think that it's appropriate as a reference. ⚊⚊ DCflyer (talk) 19:51, 24 August 2021 (UTC)Reply[reply]
Oh no worries, I didn't know they worked like that. I've seen many identifiers used as reference (Q54828450), so I think that would be good too. Thanks! AntisocialRyan (Talk) 23:15, 24 August 2021 (UTC)Reply[reply]

title (P1476)[edit]


The purpose of the change was to allow multiple titles. I'm saying that multiple titles should be allowed.

There are so many songs and works out there that are published with 2 or more titles in different languages. The constraint is not helpful. Lectrician1 (talk) 19:41, 5 September 2021 (UTC)Reply[reply]

Could you please respond to this? Lectrician1 (talk) 10:57, 9 September 2021 (UTC)Reply[reply]
@Lectrician1, regarding the following, "... so many songs and works ... are published with 2 or more titles in different languages", were you referring to songs and textual works that are published with multilingual titles, but retain their original monolingual linguistic content?
However, whether the main content is multilingual or not, the constraint was not an arbitrary addition, as it follows the practices and utilizes the schemas and classification and cataloguing models developed and used by national libraries, other cultural heritage organizations, and standards bodies. For books, Wikidata is in relative alignment with the most widely used conceptual model, Functional Requirements for Bibliographic Records (Q16388) (FRBR) — see WD:Books. If additional titles (multilingual) added as aliases, or a brief note of "also known as" in the description prove to be insufficient, a new item could be created as a version, edition, or translation (Q3331189) for any of these borderline new expressions/manifestations of the original creative work, especially if it was discovered that a differing title also differed in its date or location of publication, publisher, content size, and/or distribution format, etc.; i.e., an actual new manifestation.
Also, the issue of the title language of written works and songs has been discussed for other properties, and consensus was reached to merge in at least one case, but ultimately deprecated due to the large amount of items which would have been affected. See original language of film or TV show (P364) : "language in which a film or a performance work was originally created. Deprecated for written works and songs; use P407 ('language of work or name') instead." & Property talk:P364#Decision is to delete; mark as deprecated & Properties for deletion : 1.9 - language of work or name (P407) and original language of film or TV show (P364. ⚊⚊ DCflyer (talk) 15:52, 9 September 2021 (UTC)Reply[reply]
This problem mostly pertains to songs, and mostly KPOP songs (I mostly work for WP Music). KPOP songs can sometimes be published with English and Korean names. These instances are just one song, not different songs published with respective lyrics in English and Korean. For example, this song.
I am very well aware of the FRBR model as I had to research about it extensively when proposing and arguing for translation of (P9745). I understand completely that different items should be created for books that have different editions in different languages and therefore different titles. I just think that because these instances come up with songs where they are actually published with twos titles, the constraint should be removed, as it's quite annoying. Lectrician1 (talk) 17:31, 12 September 2021 (UTC)Reply[reply]
Any response? Here is another example of a music album that has 2 titles. Lectrician1 (talk) 23:32, 26 September 2021 (UTC)Reply[reply]

MDOT State Highway Administration[edit]

Hi there, I see you reverted a change I made to the Maryland State Highway Administration wikidata (Q5203575). I made the edit in my official capacity as an MDOT representative (you can email me at if you'd like to verify). Perhaps the way I updated the name was wrong (novice at wikidata here), but we're trying to shed the "Maryland SHA" identity. Can you help? The only official titles for MDOT SHA are:

  • Maryland Department of Transportation State Highway Administration
  • MDOT State Highway Administration

I can send you our identity guide if you'd like, or publish it somewhere. We rebranded in 2017. Many places on the web still use the old name --Eplack (talk) 05:01, 22 September 2021 (UTC)Reply[reply]

Labels can be ambiguous[edit]

That is as per Help:Label#Labels can be ambiguous. I do notice that country name is included in labels in several other languages and in Wikipedia category names (Special:Diff/1529402962), but what should we make out of it really? I can't say for sure, possible sources in some language have adopted names of these national designations differently, so that country names are included. Though, in most cases its unlikely and labels in other languages should be corrected as well. As for Wikipedia category names, these don't compare to item labels really. For instance, generic description "Buildings in Paris" is also category name, but we probably wouldn't say that individual buildings in Paris are of special building type named "building in Paris". Titles of Wikipedia overview articles may as well include country name for disambiguation purposes, but as pointed, this is not needed on Wikidata, where we can and should use accurate terms as labels.

A national designation is its own thing, an individual concept, as defined in national legislation, not some category-like pseudo-class with an ad hoc name, if that's what you might think. National park in this case is defined and listed in Estonian legislation, see official English translation, where the term for this type of protected area is simply "national park". As you can check via external identifers added to this item, this is also reflected in EUNIS database, where English name is simply "national park". In fact, I don't know any sources where name of this designation would include country name. Hence current label, including country name, is misleading, as this definitely isn't the "item's most common name" (again, see Help:Label). The same aplies to similar designations in other countries, as you can easily check via CDDA designationTypeCode (P9800) links now. 2001:7D0:81DA:F780:500A:1DCE:4F95:DAB1 08:59, 18 November 2021 (UTC)Reply[reply]

Inception citation[edit]

revision 😞 Why? Lectrician1 (talk) 17:46, 13 February 2022 (UTC)Reply[reply]

@Lectrician1: A citation needed constraint (Q54554025) was added to the property inception (P571); however, there is neither comment, nor discussion regarding this significant change at Property_talk:P571: P571 is a property that is utilized for virtually every item that is not an instance of a Wikimedia related item, e.g., category, list, permanent duplicate item, or a subclass of another item. Additionally, the only suggestion/example given at Help:Property constraints portal/Citation needed for the constraint's use is for properties likely to be challenged, e.g., properties that may violate privacy. ⚊⚊ DCflyer (talk) 19:00, 13 February 2022 (UTC)Reply[reply]

I just added it because I got frustrated at trying to make sure the statements were actually valid. I'd consider the validity of a date to be pretty important and every statement should have one. Other date properties like announcement date (P6949) also require citations. Lectrician1 (talk) 19:13, 13 February 2022 (UTC)Reply[reply]
I'd consider the validity of a date to be pretty important and every statement should have one.
I fully agree with the first part of your statement. However, there are an inordinate amount of other property statements that contain non-date/time values which could be considered to have equal or similar importance, but based upon the collaborative nature of the editing process, it's not any single editor's role to unilaterally alter one of the most utilized Wikidata properties: inception (P571). That's why there are 24 previous comments/discussions on this property's talk page, including the renaming of this property without discussion. ⚊⚊ DCflyer (talk) 20:06, 13 February 2022 (UTC)Reply[reply]
Okay, I have created a discussion about adding the constraint: Property talk:P571#Require citation Lectrician1 (talk) 20:16, 13 February 2022 (UTC)Reply[reply]
Sounds good. Thanks. ⚊⚊ DCflyer (talk) 20:33, 13 February 2022 (UTC)Reply[reply]

Kings County (Q156358)[edit]

Hello Dcflyer, could give a brief reason for these edits? Why did you remove many valid statements such as population (P1082) and instance of (P31)Metropolitan Statistical Area (Q1768043)? We retrieve data about US places directly from German Wikipedia, and your changes lead to bad data quality, which is why the data retrieval does not work for Kings county. Thanks and best regards, Yellowcard (talk) 16:18, 21 April 2022 (UTC)Reply[reply]

Hello @Yellowcard:, thank you for contacting me, as I was intent upon contacting you.

  1. Regarding Kings County (Q156358), it is not an instance of (P31) of a Metropolitan Statistical Area (Q1768043). It is a county of California (Q13212489) which is part of (P361) the Metropolitan Statistical Area (Q1768043) designated as Hanford-Corcoran, CA Metropolitan Statistical Area (Q9098500). However, it appears that Kings County is coextensive with (P3403) Hanford-Corcoran, CA Metropolitan Statistical Area (Q9098500)

Partial sources: Federal Reserve Economic Data (Q5440399) : , Metropolitan Statistical Area / Metropolitan Division: 25260 - Hanford-Corcoran, CA, 2016 (NAID 142657384) (Q67167645), Metropolitan Statistical Area / Metropolitan Division: 25260 - Hanford-Corcoran, CA, 2015 (NAID 142656562) (Q67168018) (2016), Metropolitan Statistical Area / Metropolitan Division: 25260 - Hanford-Corcoran, CA, 2012 (NAID 142654148) (Q67168698) (2015), Metropolitan Statistical Area / Metropolitan Division: 25260 - Hanford-Corcoran, CA, 2012 (NAID 142654148) (Q67168698) (2012), Metropolitan Statistical Area / Metropolitan Division: 25260 - Hanford-Corcoran, CA, 2010 (NAID 142652572) (Q67169320) (2010), Metropolitan Statistical Area / Metropolitan Division: 25260 - Hanford-Corcoran, CA, 2008 (NAID 142650986) (Q67170256) (2008), Metropolitan Statistical Area / Metropolitan Division: 25260 - Hanford-Corcoran, CA, 2007 (NAID 142650204) (Q67170485) (2007), Metropolitan Statistical Area / Metropolitan Division: 25260 - Hanford-Corcoran, CA, 2005 (NAID 142648650) (Q67170926) (2005), Employment Development Department (Q5374334) : , and Census Reporter : .

  1. Regarding your statement that "your [my] changes lead to bad data quality," this accusation is completely unfounded.
    1. Instead, your batch additions of the properties of population (P1082) and number of households (P1538) on countless numbers of items utilized the same invalid reference URL, which do not make the statements verifiable:,%241600000&y=2020 , e.g., Wheaton
    2. The use of stated in (P248) 2020 United States Census (Q23766566) is additionally problematic, as the 2020 United States Census/United States Census 2020 is a recurring event (Q15275719), subclass of (P279) census (Q39825), and not a work, online database, website, etc. Also, there appears to be an interlingual difference (de and en) between the properties editor (P98) and publisher (P123), with the former property utilized in the references.
  2. Number of housing units is a different metric from number of households, e.g., Wheaton : 16 803 households, versus 2016–2020 American Community Survey (Q111610221) : : 15 864 households.
  3. The batches have added duplicative data to multiple items which had, prior to these batch edits, statements for the same property or properties for the same point in time (P585).

Also, as an example applicable to other items, for 1 077 654 number of households of Brooklyn (Q18419), batch #80946 added the point in time of 2020-04-01, in addition to the prior existing, point in time of 2020, plus a reference; then the batch added 1 009 804 number of households for the same point in time of 2020-04-01, utilizing the same exact reference. However, according to the American Community Survey 2016–2020, there were 972 314 households (1 065 399 housing units on 2019-07-01) : . Brooklyn (Q18419)'s number of households of 1 077 654 in 2020 and on 2020-04-01 and 1 009 804, also on 2020-04-01, is a veritable exemplar of "bad data quality."

Please let me know if I can assist in updating the reference (URL and qualifiers) utilized for the aforementioned properties for all relevant items. Thank you. ⚊⚊ DCflyer (talk) 22:34, 21 April 2022 (UTC)⚊⚊ DCflyer (talk) 23:16, 21 April 2022 (UTC)Reply[reply]

Introduction of Constraint Violations

  1. The use of the qualifier statement supported by (P3680) for population : An allowed qualifiers constraint (Q21510851) violation — Statement supported by is not a valid qualifier for population. See Metropolitan Fresno (batch #80807).
  2. Stated in 2016–2020 American Community Survey (Q111610221) : A value-type constraint (Q21510865) violation — Values of stated in statements should be instances or subclasses of one of the following classes (or of one of their subclasses), but 2016–2020 American Community Survey currently isn't: information, work, version, edition, or translation, catalogue, database, correspondence, information system, project, archive, digital library. See College Park (batch #83483).⚊⚊ DCflyer (talk) 03:06, 22 April 2022 (UTC)Reply[reply]
Hello DCflyer, thank you very much for your response. First of all, please apologize my statement about the "bad data quality". I was not aware about your intentions, sorry.
You're outlining quite a lot of aspects. Let us try to separate, so I believe we will find reasonable solutions for each of the aspects.
  1. Kings County and the Hanford-Corcoran, CA Metropolitan Statistical Area (Q9098500): Basically I agree, that's two different items, with the same geographic borders, same demographics etc. There are many situations in the US where MSAs are coexistent with one county, and for many of those there is no separate item for the MSA yet. Do you think we should create items for all of those MSAs, and who is capable to do this work? But as mentioned, technically I agree that it's two different things with many shared properties.
  2. As for the number of households:
    • I agree that the definition of "number of households" is not as clear as it seems in the first glance. It's a separate definition by the USCB, but as we have to avoid OR, we should just use the USCB data. Unfortunately, even the USCB mixes the terms "number of households" and "number of housing units" in some sources, which does not make this easier to understand what exactly has been counted. Basically, what the Census Bureau consideres number of households is rather number of housing units, with some specialities. However, this is the defintion by the USCB and in my opinion we should stick with it. (Alternatively, we could create a new porperty "number of housing units", but as this is neither very clear, I am not sure this is a good approach.)
    • The data from the census 2020 data is definitely preferrable towards the ACS data, as the census has counted every inhibitant and every household, while the ACS is just a random sample (a very big one, though, however the data has been taken over five years) that necessarly bears margins of error. This margin of error is stated for each number in the ACS by the USCB thankfully, but as we have household numbers from the census, the household numbers from the ACS are rather irrelevant in my opinion. The numbers from these two sources are definitely not comparable (different timespan, different determination method, and especially most likely a different definiton of "number of households").
    • I cannot understand your edits in Brooklyn (Q18419) either. As above: We have a very reliable data from the US census about the number of households, why would you remove this very accurate data and replace it by estimated data from the ACS? This does not seem to be reasonable for me (of course, we can have ACS and Census data in parallel, but replacing census data by ACS data?).
    • Regarding the two datasets about the number of households in Brooklyn: That seems to be a technical error, I will have a closer look at that. The correct number from the US Census 2020 for Kings County, equal with Brooklyn, is 1,077,654 (source). I will check where the 1,009,804 statement comes from.
  3. Regarding the qualifiers, I am very open for better suggestions. I dicussed this a lot on German wikipedia, we have huge discussion threads on the USA portal there, but the comments from a more experienced Wikidata editor like you are very valuable. Some comments from my side:
  4. As for the source link: The US census bureau has published a very strong tool with the CEDSCI tables. These are the core data, and all other tools like QuickFacts and other sources just base on this core data. QuickFacts is much easier to use, but only utilized for places with more than 5,000 inhibitants, and third-party websites have obvious problems as they can never be as reliable as the core census data. The problem with the CEDSCI tables is, however, that linking is difficult. Using the link stated in the references leads you to the data source table, but then it is required to select the specific place to see the data in the browser. It is also possible to download CSV and Excel files for bigger data batches, which makes this data source very valuable. However, the statements are definitely verifyable, it just needs a little more work than one click. That's not an argument against the source, however, as it is not a requirement to have the data all directly available (same with a printed book etc., it might be some effort to access the reference). In this case, use the link in the references, download the CSV table, look for the place you desire and you will have the data verification. Also, the data is accessible with the browser, using the menu on the left.
    • I will check for further batches whether a better linking is possible, so the dataset can be retrieved with one click. As the USCB has made some improvements in the data table access, this might be possible by now; it was not some months ago.
I hope I have covered all aspects. Looking forward to your opinions and inputs. Best regards, Yellowcard (talk) 07:37, 22 April 2022 (UTC)Reply[reply]

Physical Review B, C, etc. were not discontinued in 2015[edit]

Hi - I'm confused by why you created Physical Review A, Atomic, Molecular, and Optical Physics (Q109300557), Physical Review B, Condensed Matter and Materials Physics (Q109339486), and Physical Review C, Nuclear Physics (Q109253008) (were there others)? These journals did not in any way cease publishing or be replaced by something different at the end of 2015. There may have been arcane reasons why ISSN's were changed or reissued, but as far as the journals are concerned they have published continuously with steadily increasing volume numbers and no discontinuity since 1970. There are certainly things that change from year to year - the specific editors, subtitles, what they declare as their mission or coverage, etc. But none of that I think qualifies as a discontinuity justifying separate items. Can you explain? ArthurPSmith (talk) 21:28, 31 May 2022 (UTC)Reply[reply]

These journals did not in any way cease publishing or be replaced by something different at the end of 2015. [emphasis mine]
National libraries and related institutions state otherwise in their serials cataloging bibliographic records. For example, Physical Review A, Atomic, Molecular, and Optical Physics (Q109300557) (ISSN 1050-2947, eISSN 1094-1622, optical disc ISSN 1538-4446, ISSN-L (P7363) 1050-2947, ISO 4 abbreviation (P1160): Phys. Rev., A At. Mol. Opt. Phy., CODEN (P1159): PLRAAN) ceased in 2015.[1][2] This serial was both renamed and continued by Physical Review A (Q3382012) (ISSN 2469-9926, eISSN 2469-9934, optical disc ISSN 2469-9942, ISSN-L 2469-9926, ISO 4 abbreviation Phys. Rev. A, CODEN PRAHC3) and continued in part by Physical review. E, Statistical physics, plasmas, fluids, and related interdisciplinary topics (ISSN 1063-651X).[3][4][5][6][7][8][9]. In my experience, many/most, but not all, serials subsume articles published in preceding title(s) into the renamed or continuation title(s) which are manifested online. However, institutional and individual holders of print editions and their facsimiles remain in possession of serials identified by their specific titles and/or subtitles and ISSNs. Additionally, these items utilize the property followed by (P156) (aliases include: continued as and succeded by), not replaced by (P1366). ⚊⚊ DCflyer (talk) 08:19, 1 June 2022 (UTC)Reply[reply]
@Dcflyer: It is true that Phys Rev A did split off a portion as E - but that happened in 1993 (see, not 2015. The Library of Congress record you point to claims Phys Rev A started in 1990 (with volume 41!) - in fact it has been publishing continuously since 1970 (see Librarians may think something changed in 1990 and 2015, but no physicist I know would agree. The American Physical Society has been publishing these Physical Review journals ("series 3") continuously, with only routine turnover in editorship and other attributes, since 1970. ArthurPSmith (talk) 21:29, 4 June 2022 (UTC)Reply[reply]
@ArthurPSmith: Item Physical Review A, Atomic, Molecular, and Optical Physics (Q109300557) contains the property followed by (P156), with six attached references. Similarly, this same item contains the property follows (P155), with the following references: (1) the U.S. Library of Congress: Continues Physical review. A, General physics 0556-2791 (DLC) 75021361 (OCoLC)1083925, (2) the U.S. National Library of Medicine: Continues: Physical review. A, General physics ISSN 0556-2791, (3) the British Library: Related Titles: Earlier Title: Physical review. A, General physics 0556-2791, (4) le Système universitaire de documentation : Suite de [continues/following] : Physical review. A, General physics, ISSN 0556-2791, (5) l'Archivio Collettivo Nazionale dei Periodici: Continues Physical review. A, General physics
Librarians may think something changed in 1990 and 2015, but no physicist I know would agree. [emphasis mine] I'm not a librarian, but that broad-brush statement reeks of stereotyping and disparagement of an entire profession—and by extension its practitioners—entirely based on an anecdotal evidence of the purported greater knowledge of different group of professionals. But the fact remains that the ISSN National Centre for the USA issued three sets of ISSNs (three ISSN-Ls) based on two subsequent serial title changes. However, there is apparently one significant discrepancy, whereas at least according to the APS Librarian Portal, the serial is divided into two separate titles & ISSNs, and not three: Physical Review A (2016-Current Year) and Physical Review A - Atomic, Molecular, and Optical Physics (1970-2015). Contacting the APS and/or the U.S. ISSN Center and the updating of one or more of the records, if necessitated, is one possible route to resolve the conflicting publication data. ⚊⚊ DCflyer (talk) 02:48, 9 June 2022 (UTC)Reply[reply]
OCLC WorldCat: Physical review. A, General physics. [©1970]-1989.
Bibliothèque nationale de France : Physical Review. A, General physics ; - Devient [becomes] : Physical review. A, Atomic, molecular, and optical physics = ISSN 1050-2947
CiNii: Physical review. Third series. A, General physics ; Published for American Institute of Physics by American Institute of Physics, 1970-1989 ; Vol. 1, no. 1 (Jan. 1970)-v. 40, no. 12 (Dec. 1989)
LIBRIS: Physical review. A, General physics ; Publicerad: New York : American Institute of Physics, 1970-1989
HathiTrust: Physical review. A, General physics. New Title: Physical review. A ; v.1 1970 pp.979-1846 — v.40 1989 pp.4837-6148 ⚊⚊ DCflyer (talk) 03:28, 9 June 2022 (UTC)Reply[reply]
CAS Source Index / CASSISM database:
Title: Physical Review A: Atomic, Molecular, and Optical Physics
Entry Type: Changed Title Serial
Title Notes: "1970-1989 subtitled General Physics. From 1990-1992 odd numbered issues subtitled Atomic, Molecular, and Optical Physics and even numbered issues subtitled Statistical Physics, Plasmas, Fluids, and Related Interdisciplinary Topics"
Former Title Note(s): Supersedes in part
Former Title(s): Physical Review
History: s3 v1 n1 Jan. 1970-s3 v92 n6 Dec. 2015
Publication Notes: From 1993 superseded in part by Physical Review E
Successor Title Note: Changed to
Successor Title(s): Physical Review A [CODEN PRAHC3]
⚊⚊ DCflyer (talk) 04:20, 9 June 2022 (UTC)Reply[reply]
@Dcflyer: Six references is no better than 1 reference if all 6 are based on the same underlying source (here the change in ISSN, caused by a change in the words in the title). The central question here is, do we consider ISSN (or ISSN-L, since ISSN already has multiple ID's for different media formats, or CODEN) to be an identifier of the sort that forces us to have separate Wikidata items, even though by other considerations the item is a single entity with continuity over time? This is important as the Wikidata item for the journal is what identifies where scientific articles were published, so having that split arbitrarily is confusing for our users and likely a large fraction of articles will be linked to the "wrong" journal (I believe this is true right now looking at publication dates and relation counts). For something that continues over time in general (like organizations - or people!) we keep only a single Wikidata item, and use properties with from/to date qualifiers to indicate changes over time. This seems a much better solution in this case too. There are many other serials in Wikidata with multiple ISSN-L's - for example UNESCO Courier (Q3106922), International Labour Review (Q15716344), Journal of the Illinois State Historical Society (Q27722141). ISSN-L granularity does not match the natural granularity of Wikidata and I am certain this is another case where this should apply. ArthurPSmith (talk) 13:52, 9 June 2022 (UTC)Reply[reply]

Former entity[edit]

@Epìdosis, Emu, MisterSynergy: Could one of you please explain Dcflyer what reason for deprecated rank (P2241) is meant for? He keeps marking IDs as "former entity" that are still valid. [10] Thanks in advance. --Kolja21 (talk) 02:37, 28 July 2022 (UTC)Reply[reply]

@Kolja21, Even though you are not addressing me on my own talk page and failed to the discuss the issue, I will. For the item Intelsat (Q778126), its current (third) official name is Intelsat S.A. The suffix Consortium was its original established form, see . The suffix Organization/Organisation/Organización was its second established form. While the use of former entity (Q110770329) may or may not be the best or appropriate reason for deprecated rank, it was used to make all of the identifiers in alignment (second established form), and done so irregardless of VIAF cluster. ⚊⚊ DCflyer (talk) 02:58, 28 July 2022 (UTC)Reply[reply]

GND stands for en:Integrated Authority File:
  • GND 4717-X (Intelsat) is a valid ID.
  • GND 5294944-8 (INTELSAT) is a valid ID (duplicate).
Both IDs refer to the same company otherwise, they would be marked as predecessor and successor. They are from different databases: Corporate Bodies Authority File (Q872551) and Subject Headings Authority File (Q897080). Both IDs are valid until they are revised and merged.
In other cases like Q778126#P244 you can use subject named as (P1810), start time (P580), end time (P582) and mark one of the IDs with "preferred rank", see Help:P227. reason for deprecated rank (P2241): former entity (Q110770329) is only allowed if an ID no longer exists. --Kolja21 (talk) 04:02, 28 July 2022 (UTC)Reply[reply]
I'm well aware of what GND stands for. Reexamining 4717-X, I now see that it contains the other name of International Telecommunications Satellite Organization and references that the entity is the subject of the 2020 publication INTELSAT. : Restrukturierung einer internationalen Telekommunikationsorganisation. / Isabel Polley. Similar, but different, BnF authorities (Q19938912) contains a singular corporate name and authority file for Organisation internationale des télécommunications par satellite (forme internationale français), with a start date of 1964-08-20. BnF authorities (Q19938912) can also be accessed via I'll restore/fix Intelsat (Q778126). ⚊⚊ DCflyer (talk) 04:34, 28 July 2022 (UTC)Reply[reply]

Could you help me on this, please?[edit]

The details are here: 09:28, 4 September 2022 (UTC)Reply[reply]

Yes, glad to help. It is now resolved. I moved the site link拉斯維加斯 from item Las Vegas (Q23768) to item Las Vegas (Q1570252). ⚊⚊ DCflyer (talk) 03:53, 5 September 2022 (UTC)Reply[reply]
Thank you! 09:30, 5 September 2022 (UTC)Reply[reply]

Qualified names on Wikidata[edit]

Hello, I noticed your changes to the English labels on items for Baltimore neighborhoods. The naming conventions on Wikidata items are not the same as Wikipedia, we do not use qualified names which have disambiguation in them as there is no need to include them when Wikidata already has unique IDs for each item. The ", State" names in item titles across the US were actually all originally removed in an automated query and regularly removed by users doing maintenance cleanup.

A number of data consumers rely on Wikidata for labels of geographic place names, and using the qualified names breaks this behavior for them / results in user complaints. See for example (and the lengthy discussions about this in said map's GitHub issues)

I will change the names back as this is a general rule on Wikidata and someone will do this anyway even if I do not.

Also, I am somewhat confused by your issue with the edits to the Downtown Baltimore items. The Wikivoyage page is not congruent with the statistical area calles Downtown Baltimore. Middle river exports (talk) 13:45, 9 September 2022 (UTC)Reply[reply]

Also, it may not be obvious, but there is in fact a neighborhood called Chinquapin Park adjacent to Chinquapin Run which is not a park. Middle river exports (talk) 14:22, 9 September 2022 (UTC)Reply[reply]
I'm sorry, I do not understand your description of your issue with the labels. A more significant issue is the mass changes that took place to instances of neighborhood (Q123705), with the unsourced Neighborhood Statistical Area of Baltimore (Q111902602) — including making a hospital (Johns Hopkins Bayview Medical Center (Q14692069)) an instance of Neighborhood Statistical Area of Baltimore (Q111902602), as well as at least four parks: Carroll Park (Q34871578), Chinquapin Park (Q34924557), Herring Run Park (Q42450165), Patterson Park (Q3660981), and two college campuses (JHU Homewood and Morgan State). Also, the extensive movement of site links, moved to newly created and unsourced items, e.g., the case with Downtown Baltimore (Q3038329) and Downtown Baltimore (Q113785980). ⚊⚊ DCflyer (talk) 14:25, 9 September 2022 (UTC)Reply[reply]
GeoNames and GNIS is class park. ⚊⚊ DCflyer (talk) 14:27, 9 September 2022 (UTC)Reply[reply]
Is a hospital a neighborhood? A park? A college campus? ⚊⚊ DCflyer (talk) 14:29, 9 September 2022 (UTC)Reply[reply]
Yes, according to the city of Baltimore. The source may be seen in the references for the population statistics. These were added directly from the CSV table provided by the city using open refine.
Also, I reiterate that Chinquapin Run Park and Chinquapin Park are not the same thing. Carroll Park is both a park and a neighborhood, but Chinquapin Park is not a park at all (same is true for Kenilworth Park, Morgan Park, Roland Park, and so on.)
The neighborhood statistical area of baltimore statements are in the process of being moved to the "statistical unit" property as this is a better place for that information than instance of.
The new "unsourced" Downtown Baltimore item simply matches the content of the sitelinks.
If GeoNames is wrong, you can edit it. It is essentially a wiki. GNIS is editable as well if you email them, I have done this for a place on the Eastern Shore once. Middle river exports (talk) 15:01, 9 September 2022 (UTC)Reply[reply]
If it would help to better understand the label issue, maybe a more helpful way to explain it would be that Wikidata has to have different conventions due to its status as a multilingual site. If we base the English label off of English Wikipedia rather than.using a consistent convention across languages, this reduces Wikidata's utility in providing multilingual labels for places. Middle river exports (talk) 15:04, 9 September 2022 (UTC)Reply[reply]
You may find something like this to be more satisfactory: Downtown Baltimore (Q113785980). (I added more detail and allowed for accounting the different definitions of where downtown begins and ends according to different sources.) The site links are all about a grouping of downtown neighborhoods, except for the Hebrew Wikipedia article, which as far as I can tell explicitly mentions the street boundaries of the statistical area/official neighborhood at Downtown Baltimore (Q3038329) and described at .
I am happy to work together on updating these items, but I would rather you did not remove pertinent information from items, especially population and housing statistics. You may use statistical unit (P2353) to indicate Neighborhood Statistical Area of Baltimore (Q111902602) (and see this map for the boundaries ), and coextensive with (P3403) if you wish to create separate items for coextensive historic districts, parks, campuses, etc. which is often a good idea. (I have been leaning towards always doing this for historic districts, some of the time for campuses depending on the context, and for parks the same item unless they have different boundaries in which case they are not the same entity. Baltimore designates various parks as "neighborhoods" for statistical purposes, but I would say that statistical neighborhood Druid Hill Park and Baltimore City maintained park Druid Hill Park are not separate entities. And for that matter, there are a few people who do in fact live with in the boundaries of Druid Hill Park.) Middle river exports (talk) 23:41, 9 September 2022 (UTC)Reply[reply]
Sorry one more remark on your changes... I would also add that deprecating valid names of neighborhoods is not a good idea. I know this probably was not your intent but deprecating "Whitelock" could come across as racially charged (it is a common sentiment that Reservoir Hill is the "white" name for the neighborhood, whether you agree with this or not).
The above and below comments comprise a specious, not-so-veiled false accusation. You conveniently leave out the fact that I also deprecated the name (P2561) Reservoir Hill (English), as well: Special:Diff/1724302817. Qualifiers for deprecation were not added because none of the currently available ones appeared applicable; however, the fact remains that on 7 May 2022 you added a statement for official name (P1448) and two statements for name (P2561). All three statements added without reference, and in regard to expressiveness, the lack of qualifiers, e.g., object has role (P3831), valid in period, start time, end time, etc., as applicable. And yet conveniently again, you commenced to add references to the three statement after you left the above message. Special:Diff/1724925733. Also, and are two different entities. I will create a an item for
Sort of similar concern with renaming Cross Keys to "Village of Cross Keys" and describing it as a "private community." The neighborhood used to be predominantly black and is named after an inn in the area. There are still a few houses from the original Cross Keys standing on the side of Falls Road opposite the private complex. Middle river exports (talk) 00:37, 10 September 2022 (UTC)Reply[reply]

Wikimedia human name disambiguation page without sitelinks[edit]

your two creations are here: Wikidata:Database reports/to delete/empty human name disambiguation items, namely Q113308673 and Q113666932. Are you done more such items without sitelinks? Estopedist1 (talk) 11:50, 11 September 2022 (UTC)Reply[reply]

These are the only two such items. I was hesistant to create these two items without site links; however, I erroneously assumed it was preferable to adding multiple different from (P1889) statements to each item. My apologies for not investigating further before I created these two items. ⚊⚊ DCflyer (talk) 12:02, 11 September 2022 (UTC)Reply[reply]

please add rather than remove info[edit]

  • You removed "catalog: Google Finance" with the explanation "value-type constraint violation".
  • I've added type "data set" to "Google Finance" and restored the statement: now there should be no violation

Rather than deleting statements, please add data! Vladimir Alexiev (talk) 13:14, 25 November 2022 (UTC)Reply[reply]

Hi @Vladimir Alexiev, you are correct. It was my mistake to remove the catalog statement and I apologize for this. Apparently in haste, I failed to recognize that Google Finance (Q1198691) is more than just an instance of a website, especially given the fact you had provided the reference URL for the statement added to Stock Exchange of Thailand (Q1330208), which outlines and describes the exchange codes (catalog codes), comprising a data set. Thank you. ⚊⚊ DCflyer (talk) 01:40, 1 December 2022 (UTC)Reply[reply]

Union city vs Essex county, Ontario[edit]

Thanks for your revert !

I did something more: moved WorldCat Entities ID "E39PBJbWBQDw8ByPCCWXFybw4q" ( from Essex county to Union city in the same county.

Oh, the joys of VIAF and Worldcat conflations are endless! Vladimir Alexiev (talk) 13:35, 25 November 2022 (UTC)Reply[reply]

It appears that the conflation involved the VIAF ID 139472893 and the two Wikidata items Essex County (Q953088) and Union (Q7885285), as the latter item had the en label "Union, Essex County, Ontario" until I made my edits, and still has the nl label "Union, Essex County, Ontario". Consequently, the Library of Congress authority ID (P244) n83203775 (Essex (Ont. : County)) was added as part of a batch of edits, which ultimately created a match for the VIAF ID, which in turn created a match for the WorldCat Identities ID. Instead of reverting the edits for the VIAF and WorldCat Identities IDs, I should have moved the statements, or deprecated them with the addtional qualifier of intended subject of deprecated statement (P8327). ⚊⚊ DCflyer (talk) 06:52, 1 December 2022 (UTC)Reply[reply]