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]
@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.
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]
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."
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]
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]
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]
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]
@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.
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]
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 eplack@mdot.maryland.gov 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 SHA
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]
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:DAB108:59, 18 November 2021 (UTC)[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]
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]
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) : https://www.census.gov/quickfacts/table/PST045215/36047 . 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]
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.
Kings County and the Hanford–Corcoran metropolitan 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.
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.
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:
As for the constraint violations, it might be reasonable to change/expand the constraint violations when we have found a reasonable structure. The constraint violations are not absolutely coherent for all cases.
The additional qualifier to specify the exact event such as 2010 United States Census (Q523716) is definitely debateable. I used statement supported by (P3680) for the census data; and I found that editor (P98) will work for the publisher of the ACS, but I am very open for suggestions on improvement. There might also be language barriers or differences in definition, indeed.
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.
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]
@Dcflyer: It is true that Phys Rev A did split off a portion as E - but that happened in 1993 (see https://journals.aps.org/pre/about), 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 https://journals.aps.org/pra/about). 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]
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]
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
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
@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]
@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 http://id.loc.gov/authorities/names/n80022852 . 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]
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 https://zelonewolf.github.io/openstreetmap-americana/
(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]
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 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]
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 https://livebaltimore.com/neighborhoods/downtown/ .
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 https://planning.baltimorecity.gov/sites/default/files/Neighborhood%20Statistical%20Areas%201216.pdf ), 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]
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).
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]
Wikimedia human name disambiguation page without sitelinks
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]
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]
If I follow your edits they essentially change the name for the relationships rather than change the relationships themselves? My concern is that this is a complicated series of journals (for their history see 1802–2018: 220 ans d'histoire des périodiques au Muséum (Q93462644), and I have created thousands of links between them and the articles they contain, hence changes to the journal items can have serious knock on effects.
Obviously there are multiple ways to model relationships between journals, and one outcome of this is that I may have to extend my queries to include has part(s) (P527). I just wanted to reach out, and make you aware that changes in modelling these things can have unexpected side effects for those building things on top of Wikidata. Rdmpage (talk) 08:15, 15 February 2023 (UTC)[reply]
FYI here's the visualisation of the history that disappeared after your edits, but which I've recreated by adding has part(s) (P527) to the SPARQL queries that generate the graph.
After my initial WTF!? I think either way of modelling this is fine. From my perspective it's the connections between items that matter more than the specific labels that we attach to them. I've modified my app to include has part(s) (P527) and part of the series (P179). Hence I'm happy to leave things as they are.
If you wanted to make a decision between which properties to use, I guess one approach is to do a SPARQL query to find out which property is the most popular on Wikidata and go with that. Rdmpage (talk) 08:47, 18 February 2023 (UTC)[reply]
Hi, I noticed you reverted two edits made by me to J. R. R. Tolkien (Q892). Youre propbaly right, it was just my attempt to suppress the warning. May you suggest another workaround? Besides J. R. R. Tolkien (Q892) has a lot of issues:
birth name (no ref)
manner of death (no ref)
Esperanto
University of Oxford degree
Influenced by (no ref)
Fellow of the Royal Society of Literature (no ref)
Historical Commission of the Bavarian Academy of Sciences
@Carnby, it's highly problematic that you created two demonstrably false items in order to suppress the warning of constraint violations. While obviously lacking the intent for, the result is little different than vandalism. -- DCflyer* (talk) 11:44, 11 August 2023 (UTC)[reply]
@Dcflyer, I don't see anything "false" about them. In fact, "translated text" seems a better fit than "translation", as a genre. Carnby is working in good faith, and vandalism is narrowly defined here on Wikidata, and Carnby deserves better than basically being accused of vandalism. I see nothing highly problematic about those edits that were easily reverted, and creation of only two items. Those are drops in the bucket where Wikidata is concerned. Carnby, please accept my commendation for your work on this important item. Thank you. Elizium23 (talk) 08:08, 13 August 2023 (UTC)[reply]
You've modified both items since Carnby used them, and little would prevent us from adding the qualities that you say are lacking. This is a wiki, after all. Elizium23 (talk) 09:12, 13 August 2023 (UTC)[reply]
@Elizium23, I agree with one thing that you wrote: this is a wiki. You or another editor are free to revert the edits that I made to the two merged items. Or, at your request, I can undo the merges and related edits. But what then? Keep the unsupported claims that literary studies and translation are instances of literary genre? Or, do you have access to any source(s) that support the claims that literary studies and translation are indeed literary genres? If not, does an editor model these merged items after literary studies (Q208217) and translated edition (Q39811647), respectively? If so, won't the two most recently created items duplicate the two previously existing ones — the reason why I merged them? Also, if the latter is the case, the reason for creating the items — to not have property constraint violations triggered — will not be fulfilled. Ultimately, the fact remains that Wikidata items model real world entities and concepts, and creating items solely to avoid triggering internal Wikidata property constraint violations — that can be addressed by alternative means, or potentially not at all — is incompatible with that fact. -- DCflyer* (talk) 11:11, 13 August 2023 (UTC)[reply]
Hi @Carnby, there were neither fixes needed, nor fixes made for the first two items regarding P7859 (P7859). Likewise, no fix is necessary for the additional three items.
Hi, why did you delete P8138 in so many different data sets? We actually use it to add the MSA inhabitant numbers in these Principal city articles. Thanks in advance for your reply. Regards Stefan (talk) 18:08, 6 September 2023 (UTC)[reply]
"Both metropolitan and micropolitan statistical areas are composed of entire counties. 'Central counties' are those that contain the population nucleus mentioned above. These nuclei are identified by a separate geographic statistical program, the urban areas program at the Census Bureau. 'Outlying counties' qualify to join a central county based on demonstrating sufficient commuting with the central county or counties of the area. Counties that do not fall within metropolitan or micropolitan statistical areas [emphasis mine] are 'outside of a CBSA. '" (paragraph 16)
"Metropolitan Statistical Area (MSA)—A Core Based Statistical Area associated with at least one Urban Area that has a population of at least 50,000. The MSA comprises the central county or counties containing the core, plus adjacent outlying counties [emphasis mine] having a high degree of social and economic integration with the central county or counties as measured through commuting." (paragraph 136)
"Metropolitan statistical areas consist of the county or counties (or equivalent entities) [emphasis mine] associated with at least one urban area of at least 50,000 population, plus adjacent counties [emphasis mine] having a high degree of social and economic integration with the core as measured through commuting ties."
"The Core Based Statistical Area Standards do not equate to an urban-rural classification; many counties and county-equivalents included in Metropolitan and Micropolitan Statistical Areas [emphasis mine], and many other counties, contain both urban and rural territory and populations." (page 2)
"Metropolitan and Micropolitan Statistical Areas are delineated in terms of whole counties or county equivalents."
"Of 3,144 counties in the United States, 1,186 are in [emphasis mine] the 387 Metropolitan Statistical Areas, and 658 counties are in [emphasis mine] the 538 Micropolitan Statistical Areas (1,300 counties are outside [emphasis mine] the classification)." (appendix page 2)
"The geographic components of Metropolitan and Micropolitan Statistical Areas and Metropolitan Divisions are counties and equivalent entities (e.g., boroughs, a city and borough, and a municipality in Alaska, planning regions in Connecticut, parishes in Louisiana, municipios in Puerto Rico, and independent cities in Maryland, Missouri, Nevada, and Virginia)." [emphasis in the original] (appendix page 3)
The following are just some of your erroneous and unsourced/unsupported edits/claims that I reverted or removed:
You added the claim that Maui County (Q111409) is a metropolitan statistical area (MSA); however, the Kahului‐Wailuku‐Lahaina Metropolitan Statistical Area was comprised of Maui County (the central county) and Kalawao County (Q494546) beginning with the OMB 2013-02-28 delineation (see [11]), and the aforementioned two counties now compose the Kahului-Wailuku, HI Metropolitan Statistical Area (see appendix page 57 at [12]).
Hi Dcflyer, thank you for your reply. First of all, let me make clear that I do not act alone here, but as part of the German language US portal in Wikipedia, and we have worked out how to insert the new 2020 census data. As Wikidata is only a back-up project to support displaying data in Wikipedia, we did not care for the fact that a county is not a MSA. We just worked out, how to add the new census data in a reasonable expense. In fact, WD still lacks of actually most of the MSA data sets where a MSA comprises only one county, as you yourself might know. Therefore, we were not aware that these missing data sets would have an important need to become created at all. If there is a need to create them, as there is an important need to distinguish between an administrative purpose and a statistical one in WD, then we kindly invite you to create the missing MSA sets. Help us to extend and correct everything what is needed, in order to put the MSA census data back to the principal city articles in Wikipedia, as soon as possible. Every edit what someone makes in WD has a meaningful purpose and is no random guesswork. We in our US project spent weeks and months and thought about how to work out all this, to add this mass of data to Wikipedia. As your knowledge seems to be highly valuable, I invite you to participate at our portal discussion.
Regarding one of your other points: See here at the bottom of page 60 of this Bulletin of March 6, 2020, it says that the New Haven-Milford, CT Metropolitan Statistical Area only comprises the New Haven County. The w:en:New Jersey statistical areas article says the same. If this document and the WP article are outdated, then feel free to update everything what needs to be updated.
@Dionysos1988, you wrote, "As Wikidata is only a back-up project to support displaying data in Wikipedia, we did not care for the fact that a county is not a MSA."
That statement is highly problematic for two reasons.
In the first place, while Wikidata collects structured data to provide support to other Wikimedia projects, Wikidata is a project in its own right, and not simply some form of a back-up. Wikidata is used by multiple third parties, including cultural institutions and authority files, as well as via Wikidata property for authority control, with reciprocal use of Wikidata (Q24075706).
Secondly, by stating that you disregarded the fact that a county is not an MSA, you indicated that you added factually incorrect — false — claims to more than 200 Wikidata items. These edits negatively affect the integrity and reliability of Wikidata.
And that includes the item for New Haven County. At the time that you created the false claim that it was an instance of an MSA, it was actually a component of an MSA.
Additionally, these false claims could adversely affect other Wikimedia projects. If a Wikipedia Infobox or other template contains, presently or in the future, parameters with the name-value pairs for instance of (P31) and located in statistical territorial entity (P8138) and their respective incorrect values, the factually incorrect MSA-related information would be displayed in the particular Wikipedia(s). -- DCflyer* (talk) 21:49, 10 September 2023 (UTC)[reply]
@Dionysos1988, the edits in question that you made in 2022, to more than 200 Wikidata items, were unsourced, factually incorrect, and false claims at the time that the edits were made by you — unsupported, contradicted, and refuted by the 2020 bulletin (OMB Bulletin No. 20-01), which was in effect at the time of your edits. Referencing the 2023 bulletin (OMB Bulletin No. 23-01) in that regard is obfuscation, deflection, and deception.
Still looking for an explanation for one-county-MSA New Have-Milford, CT, containing only New Haven Cty., as linked above, if any cbsa cannot contain only one county (thought it couldn't for myself, but the whole issue is somewhat new for me). May I suggest to chill in regard to the deception part - I've experienced enthusiasm, but not that. Although I might have to admit there might have been certain issues in comprehension with some parties - WD is a monster in itself that has to be carefully learned, if you'll pardon my colourful language. Regards, (deWP) --G-41614 (talk) 21:50, 26 September 2023 (UTC)[reply]
@G-41614, irrespective of intent, which cannot be known (good faith is assumed and remains applicable here), the following statement — as an assertion — is deceptive: The new OMB Bulletin was released on July 21, 2023, and my contributions are more than a year older!
The claims that are the subject of the edits in question were false at the time that they were made, as a U.S. county (or equivalent) was never an instance of an MSA, period. (.html) (.pdf)
The reference to a subsequently published bulletin (on July 21, 2023) in conjunction with the reference to the time that the edits were made (more than a year older!) misleading implies that U.S. counties (or equivalents) were MSAs up until July 21, 2023. If this interpretation is incorrect, please inform me. -- DCflyer* (talk) 04:28, 27 September 2023 (UTC)[reply]
Have you already removed the false "county is a MSA"-claims in every item or has this still to be done? In the last case, is there a worklist or something? Stefan (talk) 12:30, 27 September 2023 (UTC)[reply]
Thank you, DcFlyer. No point splitting semantics (on my part, not yours) as english isn't my first language, which I'm sure is obvious, so I'm probably missing out on connotations. Suffice to say that your earlier statement, which I didn't question factually, read to me as if it might miss some agf. Much as I'd like to help with the issue at hand, WD ist a bit too much for me so far, so I'll leave it at that. Knowing that there is somebody at the WD-end working on these issues is good to know, although, of course, it might be frustrating for the User in question. Regards, --G-41614 (talk) 08:05, 28 September 2023 (UTC)[reply]
Hi Dcflyer, what are your further plans in the MSA issue? I recently saw you created some new items with inhabitant numbers included. Are you planning to create the last few missing items? I appears to me that you are by far quicker than me. I really appreciate your help. Stefan (talk) 22:44, 6 October 2023 (UTC)[reply]
Hi @Stefan, thank you for contacting me. Also, thank you for locating items for U.S. metropolitan areas that have site links to the es-wiki, but lack instances of MSA. I just located another 57 such items (most of the items that I recently created duplicate these items) and there are possible more. Additionally, thank you for adding sources, both for verifiability and to decrease the likelihood that a claim might be removed in the future by another possible editor.
After I merge all duplicate items and locate all preexisting items that are actually MSAs, I will create the missing items, if any remain. I will inform you of the status. After all of the items are accounted for, I will add inhabitant numbers to all items that lack them, and update as necessary the geographic components (both what the items contain and what other items are located in). Thanks again. -- DCflyer* (talk) 00:28, 7 October 2023 (UTC)[reply]
Thanks for the correction in Francisco Bernis Carrasco (Q24287626).
I screwed up when I put the dates of birth and death because I didn't realize that when I pasted them, without a space in the middle of the last name, WD swallowed the word whole.
Thanks a lot. MartinGala (talk) 22:43, 13 September 2023 (UTC)[reply]
Hello, I see that you recently edited Vatican City. I come here with a quick request: as I lack the privilege level, could you please update the "detail map" links to instead be File:Vatican City map EN.svg for the English version and File:Vatican City map IT.svg for the Italian version? I've been working with a user to create updated versions of said maps (French and German will come at a later time). I've already tried asking on that page's discussion page, but it's been 2 weeks and no one's done it. Thank you in advance. Vuccala (talk) 22:31, 17 September 2023 (UTC)[reply]
What do you see as the difference between Q43229 and Q106668099?
Yes, it is not a duplicate of organization. Organization is one type of corporate body. A space ship or a vessel is not an organization but it is a corporate body. A conference, festival, exhibition could arguable also not be considered an organization, but they are corporate bodies in RDA. An artist group of two artists is probably also not an organization. AdamSeattle (talk) 09:39, 9 December 2023 (UTC)[reply]
@Dcflyer, AdamSeattle: If that is the case, then the description of corporate body (Q106668099) is woefully incorrect. A "collective agent who is composed of persons who are organized for a common purpose or activity; includes associations, commercial enterprises, government agencies, institutions, or other organizations" describes organization (Q43229)exactly. "An artist group of two artists is probably also not an organization" – um, it certainly is one!! An organization is any social entity (more than one person) with a common goal. organization (Q43229), its labels, descriptions, and Wikipedia articles, say nothing about size or formality as part of the definition of the term. Also, how can an entity "composed of persons" include vehicles?! Unless it's the crews of those vehicles that are meant? In which case, again, I don't see the difference from organization (Q43229). Being "a concept of library science" also does not make corporate body (Q106668099) different in extent from organization (Q43229) – the same entity may carry different labels in different fields, but that doesn't make it a different entity. So what I'm asking you is: what exactly do you see as the membership criteria for "organization" and "corporate body", such that there are entities that are members of one but not the other? Swpb (talk) 17:22, 11 December 2023 (UTC)[reply]
These corporate bodies according to cataloging rules would not be organizations in my opinion: ACM International Conference on Digital Libraries; Africa Drought Symposium; African Colloquium on Micropalaeontology; FIFA Women's World Cup; World Series [of baseball]; Apollo 11 [the spacecraft]; Pacific Clipper [the airplane]; Deep Quest [the submarine]; HMS Beagle [the ship]. But these are all considered corporate bodies by cataloging rules because the rules say that they are capable of authorship (or of creating works). AdamSeattle (talk) 18:35, 11 December 2023 (UTC)[reply]
Ok, so then it sounds like corporate body (Q106668099) is supposed to be a superclass of organization (Q43229), that contains all organizations and certain social events, vehicles (bizarre, but sure) and possibly other things (but not, I assume, individual humans) that can be listed as authors. Do I have that right? Swpb (talk) 18:41, 11 December 2023 (UTC)[reply]
Besides that, P8138 is missing in the following items of principal cities of MSAs created after 2020, where we agreed to wait until next year for new population data. Nevertheless, P8138 can also be added right now: Covington (Q1014171), Helena (Q38733), Northampton (Q49186), Pinehurst (Q119542).
How shall we proceed? I suggest that I go through the big enumeration where P8138 is missing, seen above (first step). If you do not agree with any edits, feel free to contact me here or on my own discussion page. Regarding the special cases listed below, I hope to find a solution togehter with you.
Hi @Stefan, thank you for your magnanimous, thoughtful, and detailed message.
Regarding step 1, yes, by all means, please feel free to add located in statistical territorial entity (P8138) to principal city (Q16933701) and any other possibly relevant items that lack P8138. I will not undo, revert, or otherwise change any of your edits. If I need clarification regarding an edit, I will discuss it with you here, or on your talk page. Please do not hesitate to do the same with regards to any of my edits.
I have found that between roughly one-fourth and one-half of MSAs have a corresponding VIAF ID (P214). I will add the remaining VIAF IDs, while at the same time adding 2020 U.S. Census Bureau population counts for those and all other remaining MSAs lacking those counts. I will also address the items (and any other potential ones) from step 2. I think that all of the MSA items created before August 2023 can be fully completed and updated before the end of January 2024. New population counts (year 2023 estimation and demographic balance) should have their initial release in March 2024, and I will add those data to MSAs that were created (and significantly adjusted) in August 2023. Frohe Weihnachten und ein gutes neues Jahr 2024! Best, DCflyer* (talk) 22:35, 29 December 2023 (UTC)[reply]
Hi DCflyer*, than you for your reply. Every principal city item is linked with its corresponding MSA item now. As I went through the MSA items, I saw that the following 48 items - of MSAs delineated earlier than 2023 - do not have population data so far:
Hi @Stefan, thank you for linking every principal city item with its corresponding MSA. I greatly appreciate that you determined the items of MSAs delineated earlier than (and in) 2023 and took the additional time to enumerate and post them here. Adding census derived population counts to those 48 items will be my first priority when editing Wikidata in the new year.
Separately, when you have a chance, could you please advise what would be the most appropriate German language label for instances of micropolitan statistical area (Q3270419) (µSA). For the class itself, the label is currently Micropolitan Statistical Area.
Hi DCflyer*, I know there is need for action regarding the µSAs. The problem is, that there is no appropriate term available. Creating one would be very close to original research. Google has only ~1000 hits for "Mikropolregion", almost none of them relate to the US. On the other hand, just taking over the english term is also difficult, as it would be incompatible to the "Metropolregion" term in relation to the MSAs. This is a matter still to think of. Stefan (talk) 01:46, 1 January 2024 (UTC)[reply]
When the WorldCat Entities dataset was created, it did not include entities that were instances of the class (type) organization (Q43229), or most of its subclasses; however, many new identifiers were created and added to the dataset in 2024 for this class and its subclasses, so it is possible that one may be created for Ansambel Rudija Marondinija and added at a future update. -- DCflyer* (talk) 00:38, 17 June 2024 (UTC)[reply]
I'm just wondering if there is any purpose to changing the order of values like you did here. I don't think the order makes any impact ... ? And edits like this to a well-used property cause a lot of entries on my watchlist! — Martin (MSGJ · talk) 09:31, 17 September 2024 (UTC)[reply]
That's a great question, @Martin (MSGJ), but one that only ISNIplus can provide a definitive answer. On 9 September 2024, ISNIplus rearranged the values of P244's property constraints in three separate edits (here, here, and here). I simply restored the prior order, from what ISNIplus had changed it to being, and I performed it in a single edit.
However, ISNIplus' rearrangement did have a genuine effect on the order that the bot reports the constraint violations when it updates the database report page, including in the page's history, which is valuable for examining violation count changes across multiple reports. Just like how ISNIplus' removal of my comment (which was actually a direct reply to your initial comment), from their user talk page and their copying and pasting of it, along with my signature and date time stamp, to a property for deletion page that will be archived in the near future, makes that comment less visible or prominent, so does the rearrangement of property constraints for the two most affected constraint violations of single and unique (distinct) values.
Please compare the before ISNIplus' changes, after ISNIplus' changes, and current reports, as of this writing. Format violations were moved from the first section to the third, and of greater significance, single and unique violations were moved from the page's second and third sections, respectively, to the page's fifth and sixth sections, respectively, beneath the "Properties statistics" table.
Lastly, I primarily edit Wikidata on my mobile device in a browser, and the need for unnecessary extra page scrolling through these report pages and their histories created by ISNIplus' edits, makes the reversions and corrections of the ~ 6000 total single and unique constraint value violations which ISNIplus introduced (~ 4000 in a single batch run on 8 September 2024, and ~ 2000 in multiple batches in days prior) even more time and energy consuming. -- DCflyer* (talk) 19:25, 17 September 2024 (UTC)[reply]
