User talk:Dcflyer/Structured Discussions Archive 1

Not quite sure why on Wellington College (Q114306) you set located in the administrative territorial entity (P131) = Crowthorne (Q1833112) to deprecated rank (diff) ?

Crowthorne (Q1833112) is a civil parish (Q1115575), the lowest-level administrative territorial entity of England (Q171634), so would seem to be the appropriate value. -- Jheald (talk) 16:39, 20 March 2021 (UTC)

After examining the history of Wellington College (Q114306), I'm unsure why I deprecated Crowthorne (Q1833112), as well.

It's possible that I intended to deprecate Bracknell Forest (Q896725) instead, as Crowthorne (Q1833112) is located in the administrative territorial entity (P131) of the former. The usage instruction (en) for located in the administrative territorial entity (P131) is "You only need to add the most local admin territory, but check that item also has a P131, with the next level, and so on."

I returned Crowthorne (Q1833112) back to normal rank, for Wellington College (Q114306).

Thank you for taking the time to inquire/advise me of this and my apologies for the archiving of this talk page. An unexpected result of altering my user preferences.

		The Wikidata Barnstar
		Thank you for your excellent work on the Palais Montcalm items!

~~~~

Merci, @Fjjulien. Your acknowledgement is very much appreciated.

I had planned to update the en wiki article for Place D'Youville (Q3389778), to include the history of marché Montcalm; when I add the text for that history, I will create a new en wiki article for Palais Montcalm (Q3360900), based upon the fr wiki article. Also, Érudit (Q3591464) granted me full access to its collection, via Wikipedia:The Wikipedia Library (Q16463359), to improve coverage of Québec related topics on en wiki.

— Dcflyer

I'd like to draw your attention to a feature of the Wikidata Query Service about which you might not have known: the "psn:" prefix. This is used with a property (the way "wdt:" might be) to indicate a quantity which has been normalized to a common unit based on the unit which accompanies the quantity in the original statement. In the case of distances, any quantity with a distance unit gets normalized to meters automatically, so as this query of places in Illinois with heights AMSL shows, even measurements in feet can be compared with meter measurements automatically if desired. It is thus my contention that separate statements for feet and meter measurements for elevation above sea level (P2044), as you've added to places in Washington, D.C. and the states near it, are unnecessary if both statements are cited to the same source.

Hi Mahir256,

Thank you for confirming what I have long suspected myself, that I was unnecessarily adding duplicate data points, via two statements containing equivalent values.

The motivating factor was that the Commons infobox template does not calculate and display converted units of imperial to metric, and vice versa; however, most (or all) of the infobox templates for the fr wiki automatically convert imperial units to the metric system, and if equivalent imperial and metric unit values are added to Wikidata like I had been doing, duplicate values are displayed in the those aforementioned infoboxes.

Recently, I have begun to add only a single value for elevation to items from GeoNames (Q830106) (metric unit), opposed to adding the two equivalent values from Geographic Names Information System (Q136736), which receive no updates. Going forward, I will only add a single value from a source that may have equivalent one(s), and I will remove the duplicate ones that I previously added to items.

Thank you!

Dcflyer

Greetings,

I'm following up on a message from earlier in the year about the prototype development for Special:MediaSearch. Based on community feedback, the Structured Data team has developed some new features for Special:MediaSearch and are seeking another round of comments and discussions about the tool. Commons:Structured_data/Media_search is updated with details about the new features plus some other development information, and feedback is welcome on Commons talk:Structured_data/Media_search. Media Search works in any language, so the team would especially appreciate input around support for languages other than English. I look forward to reading about what you think. -- Keegan (WMF) (talk) 00:07, 24 September 2020 (UTC)

Greetings,

I'm following up on a message from earlier in the year about the prototype development for Special:MediaSearch. Based on community feedback, the Structured Data team has developed some new features for Special:MediaSearch and are seeking another round of comments and discussions about the tool. Commons:Structured_data/Media_search is updated with details about the new features plus some other development information, and feedback is welcome on Commons talk:Structured_data/Media_search. Media Search works in any language, so the team would especially appreciate input around support for languages other than English. I look forward to reading about what you think. -- Keegan (WMF) (talk) 20:05, 23 September 2020 (UTC)

Good call reverting me on Property:P3797 – I was being too literal about first-party vs. third-party. Mea culpa!

Please do not remove highway signs from state-detail highway items. The distinct values constraint does not apply here because they are in fact the same highway, just different scales of it. There are also instances where the same shield is used for completely separate highways (for example, Interstate 84).

According to who/where? There is a long list of exceptions to P14.

Those appear to all be Japanese routes. There are too many exceptions to list in the US alone. Most states use the standard national shields for U.S. Highways and Interstates, the ones used on the national route summary item, and adding separate duplicate files to Commons for each state will certainly not stand over there.

I am in total agreement. I never understood why P14 has a distinct values constraint. An editor raised this issue on the property's discussion page back in January, but there were no responses: Property_talk:P14#Cancel_distinct_values_constraint_(Q21502410)_or_not?

I'll go ahead and add the highway shield back to all of the multiple state portions of U.S. 301.

I removed that link because it's for a page on a wiki based around a purported children's cartoon that's supposed to air on Nickelodeon. However, there's no press from the network about this, so it seems to be all puffery from the creators. I just don't see what the link adds to the Wikidata item. ~~~~

It’s an external identifier, and much could be the same about the quality and utility of a significant amount of Fandom articles. Instead of removing a property it’s customary to deprecate it and add a qualifier indicating the reason, e.g., Q22979588, Q25895909, Q35779580. This also helps to prevent it from being re-added at a later time.

Greetings,

The Structured Data team is working on an alternative, image-focused prototype for media search on Commons. The prototype uses categories, structured data as well as wikitext from Commons, and Wikidata to find its results. The development team would like your feedback on the prototype, as they are looking to work to further enhance the search experience on Commons. If you have a moment, please look over the project page set up on Commons to find a link to the prototype and leave your feedback on the talk page. Thanks for your time, I'll be posting message similar to this one to other pages on Commons. The team is looking forward to reading what you think. Keegan (WMF) (talk) 20:47, 28 May 2020 (UTC)

Hello Dcflyer. Why did you delete part of (P361) claims from entities for streets (such as Akron, Garfield, Linnaean)? Explanation would be appreciated. Thanks. -- M2545 (talk) 11:36, 30 April 2020 (UTC)

Thank you for contacting me. Please correct me if I'm wrong, but it does not fall within the scope of WikiProject Roads, as well as Wikidata's overall data model, to make a road (Q34442), or any of its subclasses, part of (P361) an instance of Massachusetts House of Representatives electoral district (Q91638539) which is a subclass of a constituency (Q192611). And because Massachusetts House of Representatives electoral district (Q91638539) is part of Massachusetts House of Representatives (Q1494460), which in turn is part of Massachusetts General Court (Q1453540), these hundreds of Cambridge road items — subclasses of transport infrastructure (Q376799), thoroughfare (Q83620), and architectural structure (Q811979) — became part of Massachusetts House of Representatives (Q1494460) and Massachusetts General Court (Q1453540), as well. Additionally problematic, is that you have made a class, Massachusetts House of Representatives electoral district (Q91638539), part of an object, Massachusetts House of Representatives (Q1494460) : Please see Basic membership properties, if you haven't already done so.

Other than the hundreds of Massachusetts road items in question, I was unable to locate any other road item that utilizes P361, except for the recommended usage to link a road item to its route system or to the full length of a highway that it may be part of (the whole). Lastly, making a road item part of s borough/city/county/parish/province has similar issues as the aforementioned ones, with a host of others, including that it would most likely have a statement that it's located in that very same administrative territorial entity, and if applied across the board, large admin territorial entities' items would require hundreds to thousands of statements for the inverse has part (P527). And for roads that traverse multiple neighborhoods/hamlets/etc., there is no current Wikidata property or qualifier (or without creating constraint violations), to my knowledge, that would allow for the capture of road length data specific to each traversed neighborhood, if that data even would be widely, openly available across geographic jurisdictions.

— DCflyer

Thanks. -- M2545 (talk) 11:51, 2 May 2020 (UTC)