|
|
|
improve EntitySchemas
|
make constraint violations queryable (phab:T204024)
|
increase the visibility of WikiProjects (phab:T329284)
|
best practices, showcase Items and other documentation improvements incl. making existing documentation more discoverable
|
introduce automated list generation (phab:T67626)
|
increase the visibility and adoption of sitelinks to redirects
|
make suggestions from the Property Suggester more visible
|
introduce a separate section in the UI for ontology-related Properties incl. linking to documentation about implications of changing them (phab:T295275)
|
make it easier to see the bigger picture of the ontology when making very local edits
|
make it easier to split an Item
|
comment
|
| initially identified types of ontology issues
|
conceptual ambiguity
|
more widespread checking and finding of Items that violate EntitySchemas due to conflation of concepts
|
more easily find Items that violate a constraint due to conflation of concepts
|
|
better documentation and examples for notorious cases of conflated concepts can help people understand how to do it correctly
|
integrating query results more in the other Wikimedia projects will lead to more cleanup of important conflated Items
|
this should decrease the conflation caused by overlapping concepts within one Wikipedia article
|
|
|
|
this should lead to less effort when untangling a conflated Item
|
|
| inconsistent modeling
|
EntitySchemas should become a place for discussion and agreement on modeling and then serve as a tool for checking existing data against those agreements
|
more easily find Items that violate a constraint due to wrong use of a Property
|
make it easier to find good examples and modeling recommendations for a particular area of interest
|
better documentation and examples can help people model Items more according to agreed upon or lived standards
|
integrating query results more in the other Wikimedia projects will force more consistent modeling
|
|
makes it easier to do the right thing by picking what the suggester recommends based on common usage in other similar Items
|
|
|
|
|
| conflicting real-world models
|
|
|
|
document better for reusers how to deal with conflicting models expressed in the data
|
|
|
|
|
|
|
We consider it a strength of Wikidata that it is able to deal with different models of the world so we should focus on making it easier to deal with it.
|
| unclassified Items
|
|
some of the involved Items will trigger constraint violations due to missing "instance of" and subclass of" statements which will then be easier to find and fix
|
|
|
missing Items in query results will lead to people searching for them and classifying them so they show up in query results on Wikipedia
|
|
lead editors to at least add a classifying statement to an Item
|
makes the importance of adding a classifying statement clearer
|
|
|
|
| messy upper ontology
|
|
|
|
|
|
|
|
|
|
|
|
| mix-up of meta levels
|
more agreed upon and automatically tested EntitySchemas will help find deviations
|
some of the Items involved in this will trigger constraint violations which should then be easier to find and clean up
|
|
|
integrating query results more in the other Wikimedia projects will lead to more cleanup
|
|
|
|
let people see how the Item they are looking at fits into the bigger picture
|
|
|
| semantic drift
|
more agreed upon and automatically tested EntitySchemas will help find deviations
|
some of the Items involved in this will trigger constraint violations which should then be easier to find and clean up
|
|
|
integrating query results more in the other Wikimedia projects will lead to more cleanup
|
splitting up of Items can help delineate the concepts they represent more clearly and thereby lead to less semantic drift
|
|
|
let people see how the Item they are looking at fits into the bigger picture
|
it'll make it easier to untangle the conflation of aspects of an Item that cause semantic drift
|
|
| exchanged sub-/superclasses
|
more agreed upon and automatically tested EntitySchemas will help find deviations
|
some of the Items involved in this will trigger constraint violations which should then be easier to find and clean up
|
|
|
integrating query results more in the other Wikimedia projects will lead to more cleanup
|
|
|
|
let people see how the Item they are looking at fits into the bigger picture
|
|
|
| overgeneralisation
|
|
|
|
|
integrating query results more in the other Wikimedia projects will lead to more cleanup
|
|
|
|
let people see how the Item they are looking at fits into the bigger picture
|
|
|
| redundant classification
|
more agreed upon and automatically tested EntitySchemas will help find deviations
|
some of the Items involved in this will trigger constraint violations which should then be easier to find and clean up
|
|
|
integrating query results more in the other Wikimedia projects will lead to more cleanup
|
|
|
|
let people see how the Item they are looking at fits into the bigger picture
|
|
|
| redundant generalisation
|
more agreed upon and automatically tested EntitySchemas will help find deviations
|
some of the Items involved in this will trigger constraint violations which should then be easier to find and clean up
|
|
|
integrating query results more in the other Wikimedia projects will lead to more cleanup
|
|
|
|
let people see how the Item they are looking at fits into the bigger picture
|
|
|
| "subclass of" cycles
|
|
|
|
|
integrating query results more in the other Wikimedia projects will lead to more cleanup
|
|
|
|
let people see how the Item they are looking at fits into the bigger picture
|
|
|
| newly identified types of ontology issues
|
duplicate Items for the same entity
|
|
duplicate Items should trigger constraint violations and making them easier to find will lead to more of them being fixed and the Items merged
|
|
|
duplicate Items showing up in query results in articles will be noticed more often and then merged to fix the duplication in the query result
|
|
encourage people to add more identifier statements, which would then lead to more constraint violations being triggered for duplicate Items
|
|
|
|
|
| mix-up of "instance of" and "subclass of"
|
some of the mixups will violate EntitySchema definitions
|
some of the mixups will trigger constraint violations which should then be easier to find and clean up
|
|
help people understand the meaning of these Properties and when to use which with more examples and more accessible documentation
|
wrong use of "instance of" and "subclass of" will lead to queries not returning expected results and triggering cleanups
|
|
|
help people understand the meaning of these Properties and when to use which
|
let people see how the Item they are looking at fits into the bigger picture
|
|
|
| other issues that were brought up but are not strictly ontology issue types
|
close/related Wikipedia articles are matching different Wikidata Items or a Wikipedia article is matching several Wikidata Items
|
|
|
|
documentation about how to handle these cases can be improved and made more accessible
|
|
more use of sitelinks to redirects can help untangle some of the cases
|
|
|
|
|
|
| the right Properties to use are difficult to identify without domain expertise or examples to copy from
|
|
|
makes it easier to find people who have domain expertise and can help clarify modeling questions
|
better and more examples to copy from helps people do the right thing even without deep domain expertise
|
|
|
more visible suggestions can nudge people towards making the right modeling choice when they are unsure
|
|
|
|
This is one of the underlying reasons for inconsistent modeling
|
| the ontology is not stable
|
more agreed upon and automatically tested EntitySchemas will help find deviations
|
|
|
raising awareness about where and when stability in the ontology is desired and why can help people make more conscious choices about their changes to the ontology
|
force more stability through reuse on Wikipedia
|
|
|
let people more easily understand the larger consequences of their local edits and then maybe reconsider the change
|
let people more easily see the larger consequences of their local edits and then maybe reconsider the change
|
|
We will not reach the point where Wikidata's ontology is entirely static and don't consider this a desirable endstate. Instead we focus on making unnecessary instability less likely.
|
