About this board

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?"

Not all "contributing properties" are NRHP contributing properties

5
TimK MSI (talkcontribs)

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

Dcflyer (talkcontribs)

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.

Please see: https://www.wikidata.org/w/index.php?title=Special:WhatLinksHere/Q1129142&limit=500 and

https://www.wikidata.org/w/index.php?title=Special:WhatLinksHere/Q1129142&limit=500&from=7342713&back=0 and

https://www.wikidata.org/w/index.php?title=Special:WhatLinksHere/Q1129142&limit=500&from=62822444&back=7342713

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.

TimK MSI (talkcontribs)

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

Dcflyer (talkcontribs)

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.

TimK MSI (talkcontribs)

That makes sense, thank you!

Reply to "Not all "contributing properties" are NRHP contributing properties"

Structured Data - computer-aided tagging designs

1
MediaWiki message delivery (talkcontribs)
Reply to "Structured Data - computer-aided tagging designs"
MediaWiki message delivery (talkcontribs)
Reply to "Structured Data - modeling data"

Structured Data - blogs posted in Wikimedia Space

1
MediaWiki message delivery (talkcontribs)

There are two separate blog entries for Structured Data on Commons posted to Wikimedia Space that are of interest:

  • 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.
I hope these are informative and useful, comments and questions are welcome. All the blogs offer a comment feature, and you can log in with your Wikimedia account using oAuth. I look forward to seeing some posts over there. -- Keegan (WMF) (talk) 21:33, 23 September 2019 (UTC)
Reply to "Structured Data - blogs posted in Wikimedia Space"

Structured Data - computer-aided tagging

1
MediaWiki message delivery (talkcontribs)
The development team is starting work on one of the last planned features for SDC v1.0, a lightweight tool to suggest depicts tags for images. I've published a project page for it, please have a look. I plan to share this page with everyone on Commons much more broadly in the coming days. The tool has been carefully designed to try to not increase any workload on Commons volunteers; for starters, it will be opt-in for auto-confirmed users only and will not generate any sort of backlog here on Commons. Additionally, the tool is highly privacy-minded for the contributors and publicly-minded for the third party being used, in this case Google. The implementation and usage notes contain more information about these and other potential concerns as a starting place. It's really important that the tool is implemented properly from the start, so feedback is welcome. Questions, comments, concerns are welcome on the talk page and I will get answers as quickly as possible as things come up. On the talk page you can also sign up to make sure you're a part of the feedback for designs and prototype testing. -- Keegan (WMF) (talk) 17:57, 17 September 2019 (UTC)
Reply to "Structured Data - computer-aided tagging"
MediaWiki message delivery (talkcontribs)

RMaung (WMF) 17:38, 10 September 2019 (UTC)

Reply to "Community Insights Survey"

wbEntity config value to be dropped on July 24th

2
Lea Lacroix (WMDE) (talkcontribs)

Hello,

We are about to drop the mw.config.get( 'wbEntity') config value, that is deprecated for two years. Starting on Wednesday, July 24th, scripts that use this value may encounter issues.

I noticed that your script located on User:Dcflyer/common.js is still using this value. I suggest that you update it, for example by using the hook wikibase.entityPage.entityLoaded (see an example here).

If you have any questions or need help, feel free to leave a comment under the related task.

Thanks for your understanding!

Dcflyer (talkcontribs)

Hi Léa,

Thank you for informing me of the deprecated config value, as well as an update for it, along with an example. I updated my common.js, as a result.

Je vous remercie beaucoup de votre aide!

Reply to "wbEntity config value to be dropped on July 24th"

Structured Data - testing other statements

1
MediaWiki message delivery (talkcontribs)

You can now test using other statements for structured data on the file page on Test-Commons. Some datatypes are not yet available, such a coordinates, but further support will be extended soon. You can find more information about testing on the SDC talk page. The team looks forward to your feedback. -- Keegan (WMF) (talk) 16:41, 24 July 2019 (UTC)

Reply to "Structured Data - testing other statements"