About this board

Mahir256 (talkcontribs)

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.

Dcflyer (talkcontribs)

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

Reply to "Multiple equivalent elevations"

Commons - Media Sarch, new feedback round

1
MediaWiki message delivery (talkcontribs)

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)

Reply to "Commons - Media Sarch, new feedback round"

Commons - Media Sarch, new feedback round

1
MediaWiki message delivery (talkcontribs)

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)

Reply to "Commons - Media Sarch, new feedback round"
IagoQnsi (talkcontribs)

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

Reply to "Thanks on ASN revert"
Happy5214 (talkcontribs)

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).

Dcflyer (talkcontribs)

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

Happy5214 (talkcontribs)

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.

Dcflyer (talkcontribs)

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.

Reply to "P14 constraint"
Imzadi1979 (talkcontribs)

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. ~~~~

Dcflyer (talkcontribs)

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.

Reply to "Capital Beltway"
MediaWiki message delivery (talkcontribs)

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)

Reply to "Commons - Media Search"
M2545 (talkcontribs)
Dcflyer (talkcontribs)

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

M2545 (talkcontribs)

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

Reply to "P361 deletions"

Q55611923 conflating of fort building and national fort park entities

1
Wolfgang8741 (talkcontribs)

Hi @Dcflyer,

I'm thinking there needs to be some modeling considered here to pull out the building and the conflated park/fort area. I've noticed that in many cases the way Wikipedia articles evolve start to distort a singular Wikidata object which is originally modeled ie as the fort building being part of the park with a common name. There is most likely an abstraction from the wikipedia article that is needed to preserve a wikidata item about the fort entity and park entity and a third Q referencing the model for fort and park in the conflated wikipedia article. If that is if I am accurately interpreting what is being the focus of the edits to Q55611923. It would keep from losing a modeled object and having cascading effect on the linked data. ~~~~

Reply to "Q55611923 conflating of fort building and national fort park entities"
Clifflandis (talkcontribs)

Hi @Dcflyer,

I must be confused. When you reverted my edit to Warm Springs, Georgia, you said "Redundant claim: it inherits Georgia from Q501151)".

It's my understanding that "Warms Spring is located in Meriwether County" and "Warms Springs is located in the state of Georgia" are separate facts both supported by P131 (i.e. "is in the state of" and "is in the county of" are both aliases).

But when I search for all the cities in the state of Georgia, Warm Springs will no longer show up after your edit.

So from my perspective it looks like those two facts don't cascade/inherit. Can you explain to me what I'm missing?

Thanks! @Clifflandis

Dcflyer (talkcontribs)

1. You actually reverted my edit, referencing the removal of a sourced claim. The only source attached was a reference to an import from the English language Wikipedia; however, Wikipedia is not a valid source.

2. Warm Springs inherits its location in the state of Georgia from having the claim of being located in Meriwether County which has the statement/claim of being located in that administrative territorial entity, just as it inherits being located in North America from having the statement/claim of country as United States.

Dcflyer (talkcontribs)
Clifflandis (talkcontribs)

Hi @Dcflyer,

Thanks for your response. Unfortunately, I'm still having difficulty understanding. Can you show me an example of how the inheriting works, perhaps using the query service or pointing me to some documentation that explains it?

Thanks! @Clifflandis

Clifflandis (talkcontribs)

I see that Resonantor displays hierarchically nested properties, but I don't see how inheritance works when querying Wikidata.

Dcflyer (talkcontribs)

You’re welcome. Not a problem at all.

If you take a look at Property:P131, you can see that one of its instances is hierarchy (Q188619), and Property:P131's Wikidata usage instruction states, "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. (English)"

Clifflandis (talkcontribs)
Dcflyer (talkcontribs)

After having examined some of your query results, what stands out is that every entity/locality has the state of Georgia, in addition to its county, as a claim/statement for its administrative territorial entity. I've never seen this type of usage for any other locality, both U.S. and non-U.S. I'm suspecting that this might be due the fact that the Wikidata entities have two instances: city of the United States (Q1093829) and municipality of Georgia (Q76514543), with the latter one possibly triggering the need have the state of Georgia explicitly stated/claimed as an administrative territorial entity.

I'll add back Georgia as an administrative territorial entity for Warm Springs.

I will investigate this further and will let you know what I may be able to find out. I appreciate you bringing the impact of my edit to my attention and apologize for the inconvenience. Thanks!

Dcflyer (talkcontribs)
Clifflandis (talkcontribs)

Okay, thanks for looking into it!

I've been doing a lot of editing on Georgia, so if I need to change how I'm describing things let me know. I created the municipality of Georgia (Q76514543) modeling after municipality of New Jersey (Q54115138). I don't mind going back and cleaning things up if I've made mistakes that don't follow Wikidata's best practices for the schema/ontology.

I'm still not able to find a query that cascades/inherits, though. For example, I did a query of museums in Los Angeles County, expecting to see the that the two museums from Los Angeles County would also show up in the query of museums in California, but no luck. When I did a query of museums in California, where I used "Located in the administrative territory entity", or any "subclass of" "California", I expected to see those two Los Angeles County museums show up, but they didn't. I double-checked and Los Angeles County has the correct P131 of California. Is "subclass of" the wrong thing to use during queries to make sure that the inheritance works?


Clifflandis (talkcontribs)
Clifflandis (talkcontribs)
Reply to "Facts don't cascade?"