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).
Jump to navigation Jump to search
Reply to "P14 constraint"
Reply to "Capital Beltway"
Reply to "Commons - Media Search"
Reply to "P361 deletions"
Reply to "Q55611923 conflating of fort building and national fort park entities"
Reply to "Facts don't cascade?"
Reply to "Not all "contributing properties" are NRHP contributing properties"
Reply to "Structured Data - computer-aided tagging designs"
Reply to "Structured Data - modeling data"
Reply to "Structured Data - blogs posted in Wikimedia Space"
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.
Commons - Media Search
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.
Q55611923 conflating of fort building and national fort park entities
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. ~~~~
Facts don't cascade?
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?
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.
You can see the hierarchy with Resonator:
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?
I see that Resonantor displays hierarchically nested properties, but I don't see how inheritance works when querying Wikidata.
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)"
Okay, I'm following you so far. So how would I need to construct a query for all cities in Georgia that wouldn't leave Warm Springs out? So far I've been looking for "instance of" "cities of the United States" "located in the administrative territory of" "Georgia".
Is there some element I'm leaving out of the query that I should add so that it captures all cities that are located in Georgia counties that aren't explicitly tagged as being in Georgia?
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!
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?
I found this Help page on modelling hierarchy of classes, which seems to suggest that "subclass of" should work... so yeah, I'm not sure where I'm making the mistake. As a test I also tried "part of" instead of "subclass of" but it still won't pull in those two Los Angeles County museums.
Hi @Dcflyer, thanks again for your help on this! I've continued the question over at Property_talk:P131#Inheritance/Hierarchy_not_working_during_queries? hoping to get some extra help. Keeping you in the loop! @Clifflandis
Not all "contributing properties" are NRHP contributing properties
Sorry to come into conflict with you over this! The articles on "contributing property" at the en/de/es Wikipedias all make clear that there are local and state designations of "contributing property" outside of NRHP. That's why I moved their links to a more "neutral" Wikidata item, with NRHP contributing properties as a subclass. A Wikidata item with the label "NRHP contributing property" that conflates both NRHP and non-NRHP contributing properties is trying to cover too much, and over time will have the effect of erroneously conferring NRHP status on non-NRHP properties within databases that draw from Wikidata. The problem will only get worse in the years ahead if the two concepts aren't separated here. Thanks-- ~~~~
I agree with you fully on the substance; however, there are 1,026 Wikidata items which are NRHP contributing properties that utilize Q1129142 in that role.
Do you plan to manually update those 1,026 items with your recently created item of Q76321820? Or, do you have a bot to perform that task?
It is customary, before engaging in such a significant change/disruption on that large of a scale, to discuss the proposed change on the original item's discussion page, which was not done: Talk:Q1129142
And, yes, I fully concur with "The problem will only get worse in the years ahead if the two concepts aren't separated here." The question remains how to implement that minus an automated process (bot) to handle the pre-existing 1,026 item linkages.
Sorry for not discussing on the talk page beforehand. It is sometimes difficult to assess what might be disruptive and I'll be more careful in the future. Regarding your most recent reversions, I think that making the current NRHP contributing property a subclass of the new contributing property item should have no impact on the 1,026 NRHP items linking to "NRHP contributing property," while allowing local "contributing property" designations to be recorded going forward. I also think it makes more sense to link the generic "Contributing property" Wikipedia articles to the generic "contributing property" item than the "NRHP contributing property" item, and that treating the Category:Historic district contributing properties as combining the topics "NRHP contributing property" and "contributing property" (and as the main category for each) accurately characterizes the category's place on the Wikipedias (situated within both the NRHP tree and the generic historic districts tree). Thanks-- ~~~~
No problem at all. And I apologize for my second set of reverts, without having had thoroughly examined your subsequent edits which I erroneously thought were a restoration of the initial ones. So, I went ahead and restored your edits by reverting my reverts.
The one exception was the Wikidata Category:Historic district contributing properties. This was/is due to its Commons Category:Historic district contributing properties. I randomly checked a couple dozen of its 53 subcategories' child categories, and every single one had an NRHP connection, either through the use of the NRHP template or its Infobox heritage designation parameter.
Multiple Wikidata items lack full concordance with their linked wikis and Commons cat, and this appears to be the case, as well as conflation, e.g., en wiki Portal:National Register of Historic Places's (#6) Subcategories for National Register of Historic Places contains the subcategory of Historic district contributing properties and the en wiki Template:National Register of Historic Places contains articles amongst its Topics for Contributing property and Historic districts in the United States (labeled as Historic district). Also, the en wiki NRHP template Template:CP color links to Contributing property.
A category's main topic has a single value constraint, so both of the items cannot be main topics. It appears that a new Commons cat will likely need to be created, after raising the issue on the existing cat's Talk page and/or at the en NRHP Portal.
That makes sense, thank you!
Structured Data - computer-aided tagging designs
I've published a design consultation for the computer-aided tagging tool. Please look over the page and participate on the talk page. If you haven't read over the project page, it might be helpful to do so first. The tool will hopefully be ready by the end of this month (October 2019), so timely feedback is important. -- Keegan (WMF) (talk) 18:09, 9 October 2019 (UTC)
Structured Data - modeling data
As you may have seen, there are community discussions underway on how to best model structured data on Commons.
Direct links to pages created so far:
- Date (talk)
- Source (talk)
- Author (talk)
- Copyright (talk)
- Licensing (talk)
- Location (talk)
- Quality (talk)
Structured Data - blogs posted in Wikimedia Space
- Working with Structured Data on Commons: A Status Report, by Lucas Werkmeister, discusses some ways that editors can work with structured data. Topics include tools that have been written or modified for structured data, in addition to future plans for tools and querying services.
- Structured Data on Commons - A Blog Series, written by me, is a five-part posting that covers the basics of the software and features that were built to make structured data happen. The series is meant to be friendly to those who may have some knowledge of Commons, but may not know much about the structured data project.