Wikidata

Wikidata talk:Notability/Archive 4

< Wikidata talk:Notability
Latest comment: 5 years ago by Izno in topic Category items
This page is an archive. Please do not modify it. Use the current page, even to continue an old discussion.

Pages that created by Newsletter extension (in Newsletter: namespace)

Latest comment: 6 years ago1 comment1 person in discussion
Tracked in Phabricator
Task T110645

Wondering if those pages are having benefit on linking em or not? --Liuxinyu970226 (talk) 06:16, 5 November 2017 (UTC)

Proposal to revise criteria regarding Commons categories

Latest comment: 6 years ago1 comment1 person in discussion

See Wikidata:Project_chat#Proposed_change_to_WD:N_regarding_Commons_categories. -- Jheald (talk) 18:13, 7 November 2017 (UTC)

Criteria on items for structural needs

Latest comment: 6 years ago12 comments6 people in discussion

The third criteria "It fulfills some structural need, for example: it is needed to make statements made in other items more useful" needs to be more precise to exclude arbitrary items. As a low barrier I'd start with:

  • these new items must be instance (instance of (P31)) or subclass (subclass of (P279)) of an established item
  • these new subclasses must have multiple established items as instances (instance of (P31))
  • both requirements are necessary but not sufficient condition for creation in any case

So it can be valid (not in every case) to create new abstract classes to better classify existing items and/or improve the existing classes only step by step. -- JakobVoss (talk) 11:13, 11 November 2017 (UTC)

  WikiProject Ontology has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead.

Looks sensible to me. − Pintoch (talk) 11:16, 11 November 2017 (UTC)
an item "wife of" would probably be no subclass but an instance of family relationships or alike --JakobVoss (talk) 12:19, 11 November 2017 (UTC)
Can you give an example of items which would be accepted with the current criteria and refused in your proposal? (an item about a wife has most probable instance of (P31) human (Q5) by the way, in addition to spouse (P26)). --Harmonia Amanda (talk) 12:50, 11 November 2017 (UTC)
Even for structural needs that are implied by instance of (P31) and subclass of (P279) I disagree with the criteria. We have many items with no instance of (P31) or subclass of (P279) claim. I think it's okay to create a superclass for an item to satisfy subclass of (P279). ChristianKl (✉) 13:55, 11 November 2017 (UTC)
No need is implied by constraints, it's the other way round: new item for structural needs (not justified by sitelinks or by reliable sources) should at least be instance of an established item or subclass of an established item and get its own instances. -- JakobVoss (talk) 15:51, 11 November 2017 (UTC)
Let's take one example of an item I created for a structural need: anatomical direction (Q25624674). It has a superclass and it has subclasses but it has no instances. I don't see how the absence of instances should be ground for it not existing.
In this case it's relatively easy to find direction (Q2151613) as a superclass but I don't think that it's always easy to create superclasses and creating superclasses means making more ontological commitments.
I think it's our current practice that if John Doe creates an item about himself we usually delete that item. If John Doe is however the wife of Jane we consider that link to make it more valuable to have the John Doe item because it allows the item of Jane to express more information. That's currently justified under the concept of "structural need". ChristianKl (✉) 16:21, 11 November 2017 (UTC)
I think we are talking about different things. Articles about people have other and additional criteria anyway. By the way your example of justifying the notability of a woman because she is wife of someone is problematic. As my proposal does not sound convincing, I'll try some analysis first. -- JakobVoss (talk) 19:50, 11 November 2017 (UTC)
Wikipedia has articles. Wikidata has no articles and therefore concerns about what kind of articles are notable aren't relevant. Wikidata has items (and an item implies a page).
In the linked data world we use items to express who someone wife happens to be instead of storing the name in a string. In all case where it would make sense to store the name in a string in a normal database we store it as items in Wikidata we want the ability to create an item for that purpose. ChristianKl (✉) 15:57, 12 November 2017 (UTC)
  • I think many good items created now under the "structural need" policy would fail this test. Isn't the structural requirement the justification to create items for works that are used as references for other statements? Similarly regarding items for authors of those works, as well as people created under the relationship cases mentioned above. Many positions ("mayor of XYZ" etc) would never have "instances" as we don't use P31 for people and their positions or occupations, and yet these specific positions are necessary for the wikidata data model to hold that information. So what do we really mean by the "structural need" notability requirement? I think (A) if there is a data modeling requirement for the item (the associated information is about an existing item but it cannot be fully modeled with properties on the item itself), or (B) the new item provides some kind of intermediate link between existing items (there is a statement on an existing item that would have this item as value, and this item should have a statement with another existing item as value - this is I think a generalization of your P31/P279 case above). Does that make sense as a more specific definition of structural need? Or is it still too general? ArthurPSmith (talk) 20:10, 11 November 2017 (UTC)
  • Recently I created DNA segment (Q43029561) as subclass for Numt (Q7069705). I think it's okay to create an item like that given that "nuclear mitochondrial DNA segment" is quite obviously a subclass of "DNA segment". I don't think there should be a requirement in a case like this to think about what the superclass of DNA segment happens to be. Yes, there's more that can be done to develop the new item and maybe search for other subclasses but that's not work that has to be done immediately. When someone else needs the item they can continue the work. ChristianKl (✉) 21:50, 13 November 2017 (UTC)

Main goal

Latest comment: 6 years ago26 comments7 people in discussion

Wikidata in its first phases has two main goals: to centralize interlanguage links across Wikimedia projects and to serve as a general knowledge base. What is "general knowledge base"? What is its target audience? Who are its consumers? On what page is all this written? --Fractaler (talk) 12:48, 12 November 2017 (UTC)

Please consult Wikipedia for such general questions instead of asking them here. -- JakobVoss (talk) 13:10, 12 November 2017 (UTC)
I asked not only Wikipedia. And Wikipedia replied: "sorry, I do not know. Maybe, you know? --Fractaler (talk) 15:50, 12 November 2017 (UTC)
Start reading at knowledge base (Q593744). “General” means that there is no limitation to a particular topic. —MisterSynergy (talk) 16:20, 12 November 2017 (UTC)
Thanks, I know what is knowledge base (Q593744). no limitation to a particular topic: so, I can create a topic, for example, "10011101011010011100111011"?  – The preceding unsigned comment was added by Fractaler (talk • contribs) at 17:33, 12 November 2017‎ (UTC).
No. “No limitation to a particular topic” is totally not the same as “Anything is allowed”; you are familiar to the notability criteria which define boundaries we have agreed on. Please mind that knowledge refers to something which is widely accepted and thus typically verifiable in external sources. —MisterSynergy (talk) 16:57, 12 November 2017 (UTC)
I can change the statement of page to a more precise one: to serve as a knowledge base, which define boundaries we have agreed on? --Fractaler (talk) 17:11, 12 November 2017 (UTC)
Wikidata is a secondary database [1], that means only data which is already in external sources can be added to Wikidata. --Pasleim (talk) 17:23, 12 November 2017 (UTC)
Thanks. So, we have, Wikidata is: 1) secondary database, 2)knowledge base. What is true?--Fractaler (talk) 19:59, 12 November 2017 (UTC)
Where is the contradiction? --Succu (talk) 20:34, 12 November 2017 (UTC)
Where I claimed that there is a contradiction? I asked, what is true? You know? --Fractaler (talk) 07:59, 13 November 2017 (UTC)
For me it looks like you want to apply the principle of bivalence (Q2110857). Or not? --Succu (talk) 22:36, 13 November 2017 (UTC)
It does not matter what is true. Wikidata does not collect truth but referenced statements. -- JakobVoss (talk) 14:14, 14 November 2017 (UTC)
Wikidata at this point is effectively Wikipedia metadata. There projects for doing more, but outside of biographies there's little progress. I got pushback with UPC claiming "its too many items" (max 1 trillion). —Dispenser (talk) 20:11, 14 November 2017 (UTC)
For some users of ru-wikipedia, such questions looked, I think, as an encroachment on their property. I hope this is not perceived here. I just want to find now a clear definition of the terms used here and finally understand who/what it is intended for (the target audience) items of Wikidata. Wikidata does not collect truth but referenced statements: Wikidata is a just collector? Collector of a referenced statements? Collects for whom? Or for what? Just like that, with nothing better to do? Is there an ultimate goal, a consumer of items? Wikidata at this point is effectively Wikipedia metadata: so, this is all for Wikipedia, is it a consumer? --Fractaler (talk) 07:17, 15 November 2017 (UTC)
Wikidata is database which collects referenced statements with the goal that anybody in the world can consume open free data. Anybody in the world can also add new data to Wikidata. In case data of the same domain already exist in Wikidata, it can be added directly. In case it is a new domain, community consensus has first to be reached. --Pasleim (talk) 16:41, 15 November 2017 (UTC)
So, the Wikidata and Wikipedia have the same main goals? --Fractaler (talk) 09:23, 16 November 2017 (UTC)
Definitely, WD is just a database for the wikiverse, which consist mainly of wikipedias, but other projects as well. It's a collection of referenced data, it should be a collection of verified data, but unfortunately too many bots included too many rubbish and doublettes, so it's less useful now, but for the main purpose, to host interwikilinks, it's still useful in general (although LSbot is so keen on creating useless doublettes through his botpedias, that this goal is going a bit off now). Sänger (talk) 19:08, 18 November 2017 (UTC)
WD is just a database for the wikiverse: are the Wikidata's properties (P*) a "just a database for the wikiverse"? collection of referenced data: Wikipedia is also a "collection of referenced data". main purpose, to host interwikilinks: if this is the main goal, why did the Wikidata start linking data to each other? Why give own links, own images, own definitions, creates items that do not have a interwikilinks, etc.? The state in the state?
Try reading e.g. Wikidata: A Free Collaborative Knowledgebase (Q18507561), Fractaler. --Succu (talk) 22:46, 18 November 2017 (UTC)
Thanks, I tried. When I read the page I found on the link. It said: "We look forward to new and innovative applications due to Wikidata and its development as a knowledgebase": where "general knowledge base"? Just "knowledgebase"? "With Wikipedia's data becoming cleaned and integrated in a single location, opportunities arise for many new applications": are there only Wikipedia data in the Wikidata? Also, "Wikidata's goal is to allow data to be used both in Wikipedia and in external applications", "the community is as dynamic as Wikidata itself, based not on status or membership but on the common goal of turning Wikidata into the most accurate, useful, and informative resource possible", "There is no question this must include data that can be searched, analyzed, and reused": can I now find in the Wikidata, for example, "first cosmonaut"? Or, for example, what is the name of "one of seven equal parts of a whole" (Q42879824)? Allow the data of the Wikis to answer the question, for example, "Great Pyramid of Giza" is one of seven equal parts of "Seven Wonders of the Ancient World or not?" --Fractaler (talk) 07:30, 20 November 2017 (UTC)
Counting them is not enough, Fractaler? What do you want to express? A cardinality constraint? --Succu (talk) 22:52, 22 November 2017 (UTC)
Enough for what? Mathematically speaking, which graph (Q141488) should the knowledge base (Q593744) of Wikidata have (main goal?): tree (Q272735) or non-tree (Q272735)? If tree (Q272735), then we must have transitive relation (Q64861). For example: Great Pyramid of Giza (Q37200) (one of seven equal parts of Seven Wonders of the Ancient World)->Q42879824 (one of seven equal parts of a whole)->member of a group (Q36809769)->part (Q15989253)->entity (Q35120). If non-tree (Q272735), then of course, Counting them is enough and on this we can close this topic by writing down the relevant information in the rules. Fractaler (talk) 06:50, 23 November 2017 (UTC)
Are you talking about RDF Triples? Once again: What do you want to express? Great Pyramid of Giza (Q37200) part of (P361) Seven Wonders of the Ancient World (Q489772)? Is there. --Succu (talk) 22:15, 23 November 2017 (UTC)
I said about rdf-graph (is graph (Q141488)). This graph can be tree (Q272735) or non-tree (Q272735). So, what graph we need here (tree (Q272735) or non-tree (Q272735))? If tree (Q272735) (because transitive relation (Q64861)), then we also can said: Great Pyramid of Giza (Q37200) subclass of (P279) component (Q1310239) (component of Seven Wonders of the Ancient World (Q489772)). If non-tree (Q272735) (and only!!!), then of course, Great Pyramid of Giza (Q37200) part of (P361) Seven Wonders of the Ancient World (Q489772) (and only!!!, no other point of view). Fractaler (talk) 09:49, 24 November 2017 (UTC)
It's as well part of (P361) Giza pyramid complex (Q12508), and part of (P361) Giza Pyramids (Q13217298) and probably part of (P361) many more bigger groups. And probably never is "one umpteenth part of a whole" of any significance. it's just irrelevant blah to increase noise and to hide signal. Sänger (talk) 10:12, 24 November 2017 (UTC)
Where? Now on page Great Pyramid of Giza (Q37200) I see only part of (P361) Seven Wonders of the Ancient World (Q489772)! --Fractaler (talk) 12:56, 24 November 2017 (UTC)

Why do we ban "special page"?

Latest comment: 6 years ago3 comments3 people in discussion

The total amount of special pages is quite limited so the amount of additional items wouldn't be significant. Pages like "Recent changes" exist in every Wiki. Why shouldn't they be interlinked? ChristianKl (✉) 13:15, 16 December 2017 (UTC)

I suspect that interwikis for special pages aren't controlled by Wikidata item sitelinks, so adding such items wouldn't do anything. If there are to be interwikis for special pages, it should be done at the software level directly. --Yair rand (talk) 07:48, 19 December 2017 (UTC)
@ChristianKl: Anyway, if you really want interwiki links to be shown on special pages, learn how Kolsch/Ripurian Wikipedia does it (though I also don't know what's their method to show all "language editons" on them, @Reedy: do you know that?). --Liuxinyu970226 (talk) 11:14, 23 January 2018 (UTC)

Notability of a statement consisting of one property-value pair

Latest comment: 6 years ago1 comment1 person in discussion

There is a lot of original research statements in the WD: 1, 2, etc. For items we have notability. What we have for "statement consisting of one property-value pair"? --Fractaler (talk) 09:58, 19 December 2017 (UTC)

RfC: Notability and Commons

Latest comment: 5 years ago29 comments13 people in discussion

Until today, WD:N gave the following guidance concerning items for Commons categories.

  • An item with only a sitelink to a category page in Wikimedia Commons is not allowed on main article items. However, it is allowed to link Wikimedia Commons categories with categories in other Wikimedia sites in items.

User:Camulogene77 tried to follow this advice and create category-items for two lighthouses that have categories on Commons. These two items were then nominated for deletion, as failing the point above.

To try to clarify things, User:Mahir256 and User:Jura1 have edited this page, changing the wording to now read

  • In addition, sitelinks on category items to category pages on Wikimedia Commons are allowed if and only if they are linked with category pages on other Wikimedia sites

This new text now specifically forbids the creation of new category-items with sitelinks only to Wikimedia Commons; but it now says nothing about general article-style items (ie items with a P31 that is not instance of (P31) = Wikimedia category (Q4167836)).

Given the ever-increasing importance of Wikidata to Commons, with more and more Commons templates (including now category infobox templates) drawing on Wikidata items, and of course the upcoming Structured Data on Commons programme, I believe it would be useful to go beyond this, and would therefore like to suggest the following, based on wording discussed at Project Chat in November:

  • An item may be site-linked to a Commons category, but such items should only be created if they relate to a distinct identifiable conceptual or material entity. Items should not be created for Commons categories that can be described as an intersection of existing entities. In addition, items should not be created for certain classes of Commons category listed at Wikidata:Notability/Exclusion criteria, unless they have individually achieved general notability.
A Commons category should sitelink to a category-type item on Wikidata if such a category item exists; but if such a category-type item does not already exist, it is then acceptable for a Commons category to be sitelinked to an article-type item.

This wording was written with the intention to exclude main items being created for Commons categories that correspond to "intersections" of entities. Compared to the text from November, I have also added the sentence beginning "In addition..." to give an option to exclude some particular identified classes of Commons categories that concerns were raised about -- for example, categories relating to particular aircraft airframes, or to individual Wikimedians, to which one might also add individual names of ships (as opposed to items for the ship's whole history).

This proposal in November seemed to be quite well received, but ultimately fell off the Project Chat page and into the archive, without any firm decision. I am therefore re-proposing this now as a formal RfC, to go forward to a proper close.

As I suggested in November, if the text above is adopted, I believe we should now also mark the earlier 2013 discussion on Commons links as {{Historical}}. It is not the path we have ultimately followed. Jheald (talk) 23:13, 5 March 2018 (UTC)

Pinging @MisterSynergy, C933103, Multichill, Billinghurst, Jarekt, Ghouston: @Donald Trung:, who all participated in the discussion in November. Jheald (talk) 23:28, 5 March 2018 (UTC)

Instead of a lengthy section on Commons, couldn't the same result be achieved by removing all mentions of Commons from the policy? The intention seems to be that the existence of a Commons category has no influence on whether a Wikidata item is notable. Ghouston (talk) 23:56, 5 March 2018 (UTC)
(ec) @Ghouston: So just leave it at
"It contains at least one valid sitelink to a page on Wikipedia, Wikivoyage, Wikisource, Wikiquote, Wikinews, Wikibooks, Wikidata, Wikispecies, Wikiversity, or Wikimedia Commons"
the clause that you added into the above?
The answer I think is because Commons has always been treated slightly differently from Wikipedias for notability -- particularly I think because of a fearfulness about creating Wikidata items for Commons "intersection" categories. That is why (I think) a Commons category, unlike a Wikipedia article, has historically not been considered sufficient in itself to justify a main Wikidata item.
What I would like to do with the above is to shift that, to a presumption that a Commons category typically should be considered sufficient justification for a 'main' article-type Wikidata item -- but with specific exclusions, (i) against intersection categories; and (ii) against a specific list of things, that might include otherwise-non-notable Wikimedians or (say) individual aircraft. Jheald (talk) 01:24, 6 March 2018 (UTC)
@Ghouston: Omitting Commons from the list will suggest that nothing from Commons is notable—not a particularly desirable outcome. We could move the existing Commons bullet point to the end and flesh it out as follows:
  • On Commons, a category's existence does not by itself confer any notability to an item under this criterion. Specifically,
    • Items for Commons categories about intersections of concepts or Commons categories falling under the exclusion criteria are not considered valid.
    • Other Commons categories should be linked to their category equivalents on other wikis if their category equivalents exist and to their mainspace equivalents if their category equivalents do not exist. If either of the other criteria apply to the item, an item with only a Commons category link is permissible.
This should clearly indicate that Commons sitelinks are the site-specific exceptions to point 1 of WD:N, presented similarly to the exceptions for Wikisource, Wikinews, Wikidata, and Wiktionary, and this should clearly define the situations where Commons category links are allowed or disallowed otherwise. Mahir256 (talk) 01:09, 6 March 2018 (UTC)
Yes, I was suggesting that Commons not be included in the list of projects in 1), first line. Since the notability polity is only about whether an "item is acceptable", I don't think it needs to discuss where Commons sitelinks should go. Ghouston (talk) 02:21, 6 March 2018 (UTC)
  Support "On Commons, a category's existence does not by itself confer any notability to an item under this criterion." How about gallery's existence? Visite fortuitement prolongée (talk) 16:34, 22 April 2018 (UTC)
  Support I agree that this needs urgent clarification. I see that @Jura1: has also nominated some similar items further down the list. My basic view is that we should be able to have Commons sitelinks for categories describing topics, whether that's directly in the main Wikidata item (preferable for performance reasons for accessing Wikidata info from Commons, but doesn't work where there is both a gallery and a category), or by having a category item with a single category's main topic (P301) where necessary (we can then use arbitary access to follow the P301 link through to the main topic item). (In practice, that should allow e.g. commons:Template:Wikidata Infobox to work through sitelinks in most cases of interest.) Intersection categories and other non-topic categories are less interesting, although it might help to be able to use Wikidata in those cases as well to access translations of the intersection topics. So @Jheald's proposed text looks good to me, except I'd clarify it to more explicitly permit the creation of Category items sitelinking only to a commons category where the Commons sitelink in the main topic item is occupied by a commons gallery. Thanks. Mike Peel (talk) 09:48, 6 March 2018 (UTC)
  • @Jheald: a question, is any Commons page or category "notable" on its own account? (Files excluded from this line of thinking) So the thinking could be follow that notability lives elsewhere and Commons pages/category pages become notable when those already items exist to which they can be linked; or category notability only exists where they exist xwiki as a collective, and have some relationship to a main subject. The criteria for link inclusion is a complex to represent in words as it has elements of jargon. We may wish to represent this visually. So (preferentially)
  1. Where WD item exists, then it can be linked with existing Commons gallery
  2. Where similar categories exist xwiki, then wikimedia categories can exist and be linked to a WD category item, this includes Commons categories
  3. Where item exists, and no gallery available AND where no WD category item exists, then and only then an item can take a Commons category link
At no time would an WD item be created solely for the purpose linking to a page at Commons in main or category: namespace. [Linking for project: and template: namespaces should be handled by separate conversation and criteria]  — billinghurst sDrewth 10:28, 6 March 2018 (UTC)
@billinghurst: The counter to this, I think, is what I said above in the proposal -- that with opportunities like Commons infoboxes it is becoming increasingly valuable to write information about the subject of a Commons category to a Wikidata item; and, particularly to ease the way towards Structured Data, it would be good to encourage more and more of this -- having such information in the standardised, organised structure of Wikidata items, if we can, is going to be very very helpful. So I think this is a moment we should be reducing barriers to creating main-type items related to the subjects of Commons categories, not raising them. I do see that there may be specific types of thing that we want to exclude; but in general, if something exists and is concrete enough to have a Commons category, I don't see the value in creating additional hoops and hurdles to get past, before someone can create a Wikidata item to hold information about its subject. And I think guidance needs to give some reassurance to anyone who spends the time creating and populating such an item, eg to feed a Commons infobox, that their work will not be lightly deleted, and that they can have some confidence that it will still be there the next time they look at their new infobox.
Also, given the experience of User:Camulogene77, I think it is now way past time that we updated the advice we give on what we expect for sitelinking, and mark the old 2013 discussion as 'historic'. I do think there is now pretty much consensus on what we do want, but it should be written down, and made clear that this is the agreed community view. Jheald (talk) 12:08, 6 March 2018 (UTC)
@Jheald: It is a circular argument to say we have an infobox therefore the categories become notable.

I don't see that what I argued is contrary to what you are saying. There are clearly numbers of categories at Commons that are not notable, and creating items for them will have them like a shag on a rock. For the infobox to be present and beneficial the category where the template exists is supported by these other factors, so if that is seen as impediment it is one that is about having sufficient data to populate the infobox. If you have specific examples, then please present those in preference to arguing about unnamed things that have been deleted where the argument becomes rhetorical, not substantial.  — billinghurst sDrewth 12:28, 6 March 2018 (UTC)

Not entirely, since way that Structured Data on Commons is being implemented means that the Wikidata item would be useful to Commons even if it has nothing more than a description, since it can be used to provide multilingual topics (the structured replacement for categories). However, I've been assuming that changing the Wikidata notability policy to treat Commons like other projects would be a lost cause. Ghouston (talk) 22:51, 6 March 2018 (UTC)
If the notability policy was going to be relaxed that far, there's really no point in requiring somebody to go to the effort of making a Commons category (perhaps in future, if Structured Data is successful, then categories won't normally be created anyway). You'd just need to be able to show that the concept actually exists, so for example, given a link to a photo with a person named as the photographer, you could create an item for that person. I don't know how you'd filter out fake data with such a loose system. Ghouston (talk) 23:07, 6 March 2018 (UTC)
  • I fully   Support Jheald's propositions, personally I would go further and allow the creation of Wikifata items for all Wikimedia Commons categories, I understand how tedious it would be but for Structured Data it would be a major improvement, the current policies simply don't allow for that. -- 徵國單  (討論 🀄) (方孔錢 💴) 02:43, 7 March 2018 (UTC)
    Also note that every Wiktionary entry generates an instance and there are plenty of words that are very obscure and confounded only to extremely local sociolects. Excluding Wikimedia Commons may have made sense when the project when younger but now there's actually a need to correctly structure Wikimedia Commons and excluding categories seems counterproductive to that goal. -- 徵國單  (討論 🀄) (方孔錢 💴) 04:35, 7 March 2018 (UTC)
  • With the recent changes, it seems that there's no longer a restriction against creating main items that link only to Commons categories. I'm assuming that a category is a type of "page" for the purposes of clause 1. Now there's basically a restriction on creating new category items for Commons categories. Items with sitelinks only to a Commons gallery have always been permitted as far as I know. Ghouston (talk) 05:31, 7 March 2018 (UTC)
Discussion highlighted on Commons at c:Commons:Village_pump#Commons_categories_and_Wikidata_notability Jheald (talk) 23:46, 8 March 2018 (UTC)
  Support the deletionism comes to wikidata is ugly. should not be editing notability criteria without a clear consensus, to justify a deletion nomination. if a Q item is useful for organizing commons items then it should be notable per "3. It fulfills some structural need, for example: it is needed to make statements made in other items more useful" (unless they would care to delete that criteria, since they are repeatedly ignoring it.) Slowking4 (talk) 04:00, 9 March 2018 (UTC)
  Support - PKM (talk) 00:33, 13 March 2018 (UTC)
I'm a tiny bit torn on this issue. On one hand, it seems a good idea to create items for Commons categories (where it makes sense). But on the other hand I sometimes worry that it might be abused by SEO people, marketing people or people trying to promote themselves. Once it gets known that all you have to do is upload a couple of freely licensed photos of you/your product/the thing you're paid to promote and you get a Wikidata item where you can claim whatever you want (because such stuff rarely if ever gets factchecked) and sooner or later that "information" will spread to Google and other sites/services.
I've seen quite a few cases that went like his: new user creates a Wikipedia article about themselves that consists of blatant self-promotion. Additionally, they upload several promotional photos of themselves to Commons. And sooner or later, their article is deleted due to a complete lack of reliable sources/notability. Which - without any aditional external IDs or references - would mean that the item no longer meets our criteria for inclusion and could be deleted. But the photos are freely licensed, so they aren't deleted on Commons. And if they uploaded more than one photo of themselves, there's a good chance that a Commons user comes along and creates a category for this person. Which then means that even without any sources whatsoever, their item can continue to exist. --Kam Solusar (talk) 02:05, 13 March 2018 (UTC)
  •   Oppose Q50347426 was created with only a link to a category and a link to Ploumanac'h lighthouse (Q2084981). The Commons link was moved to Ploumanac'h lighthouse (Q2084981) and Q50347426 deleted. Problem solved. No need to change policy here. We would end up with thousands and thousands of redundant category items (basically for every concept where we have a Wikipedia article and a Commons category). The second criterion on WD:N covers all the cases where an item gets created which only has a sitelink to a Commons category. Multichill (talk) 19:31, 15 March 2018 (UTC)
    @Multichill: You might want to re-read this. The motivation was to avoid situations like that happening in the future... In particular, the last bit: "A Commons category should sitelink to a category-type item on Wikidata if such a category item exists; but if such a category-type item does not already exist, it is then acceptable for a Commons category to be sitelinked to an article-type item." Thanks. Mike Peel (talk) 21:46, 15 March 2018 (UTC)
    @Mike Peel: you think Q50347426 shouldn't have been deleted? This is about notability, so if an item should exist or not, not a manual page on what should be linked with what. Multichill (talk) 22:15, 15 March 2018 (UTC)
    @Multichill: My !vote was to merge, I assume that was done before it was deleted. However, the user that created that entry apparently did so after being confused by this page, which means that this page needs to be clearer in saying that it is allowed to sitelink to Commons categories from topic item pages, and that you don't need to create a separate category item in that situation. As I said, I think you've misread this, and I hope you re-read it. Thanks. Mike Peel (talk) 22:23, 15 March 2018 (UTC)
    @Multichill: You write that No need to change policy here. We would end up with thousands and thousands of redundant category items (basically for every concept where we have a Wikipedia article and a Commons category). I agree with you that I believe that not wanting those redundant items is indeed where the community is now at. As of today there are 680,000 sitelinks from article-items to Commons categories (latest stats on different types of links), and I do think the community is fine with them.
However, the trouble is that that is not what the written policy currently states. As of today, this page still references Wikidata:Requests_for_comment/Commons_links (Sept 2013), with its decision of "Articles only with galleries, categories with categories". That's why for me an important element of this RfC is to formally close the book on that old policy, and mark its page as {{Historical}}.
Whilst some might see this only as a formality, I believe it matters. For one thing, it appears that it confused User:Camulogene77 as to what was currently recommended practice. Lack of definitive clarity regarding Wikidata's position on this was also raised as a point in opposition to the Commons RfC on migrating old-format interwiki links to sitelinks. Plus, per those latest stats again, there are potentially another 600,000 article-items that could be sitelinked to Commons categories -- something that User:Mike Peel has an expressed an interest in addressing (thread at Talk:P373, and which (IMO) would be very useful to add, (i) for templates at Commons, (ii) to be able to use SQL to identify unmatched Commons cats -- the more we can match, IMO, the more that could help Structured Data there, and our ontology here.
So for all of these reasons I think it would be helpful, to finally formally settle this question of how links should work, and write it down in black and white as a properly adopted decision.
On the question of whether WD:N(2) is enough already to allow the creation of all Wikidata (article-type) items for Commons categories that ought to be created; or whether there are cases where either a greater presumption in favour of creation and/or more guidance is needed -- on that question I'm more relaxed, and different people have expressed different views above.
But on the issue of now firmly deprecating the old Sept 2013 RfC on linking, I do think that is something that would be helpful to do, and that I hope whoever closes this RfC will do. I don't think I see anyone advocating above for the old position, so I hope that deprecation will be possible, and the footnotes here at WD:N rewritten accordingly. Jheald (talk) 18:57, 24 March 2018 (UTC)
I support removing the link to the 2013 RFC. The outcome wasn't even clear (with "addenda" added to the close that ignored the voting), and a follow-up RFC in 2015-2016 was closed with no consensus. Ghouston (talk) 22:55, 24 March 2018 (UTC)

  Oppose your proposal wich is mainly about "can-be-sitelinked" which is out of scope in Wikidata:Notability. Visite fortuitement prolongée (talk) 16:34, 22 April 2018 (UTC)

  • Several comments:
    • It isn't entirely clear to me what concrete proposal is being "supported" or "opposed". I'd really like to see a clear statement of the proposed policy, juxtaposed against current policy.
    • I'm completely confused by the proposal above to "permit the creation of Category items sitelinking only to a commons category where the Commons sitelink in the main topic item is occupied by a commons gallery." Can someone put this in different words?
    • Commons is in several important ways "a different beast" than a Wikipedia. Most importantly here, most "leaf" Commons categories (and some non-leaf Commons categoreis) serve a function more analogous to Wikipedia articles than Wikipedia categories. Unless it's for purely technical reasons, I think it's going to be rare when we need an item just for a Commons category per se, but common that we need an item for the topic of a Commons category, even if there is no corresponding article in any Wikipedia.
    • Let me give a few examples of categories in Commons that I think merit would merit a category for their topic, even though no Wikipedia article currently exists:
- Jmabel (talk) 04:24, 18 May 2018 (UTC)

Template

Latest comment: 5 years ago1 comment1 person in discussion

What kind of template is mentioned in "If a link is a template, the item must contain at least two such sitelinks"? Wikipedia templates? J 1982 (talk) 16:08, 12 May 2018 (UTC)

Category items

Latest comment: 5 years ago29 comments10 people in discussion

I know there's a discussion about Commons above, although I'm not sure where it's going. Following a discussion on the project chat at Wikidata:Project_chat#Commons_gallery_vs_category_sitelinks I'd like to propose changing the following condition:

In addition, sitelinks on category items to category pages on Wikimedia Commons are allowed if and only if they are linked with category pages on other Wikimedia sites. [with a footnote]

to:

Category items are only valid if they either a) have at least two sitelinks, or b) have one sitelink and are linked via topic's main category (P910) and category's main topic (P301) with an item which is notable in its own right.

The idea is that it's pointless to create category items unless they serve some purpose. The two possible purposes are a) connecting categories on two projects to provide sitelinks b) linking a category to a main item, to potentially provide additional sitelinks and to allow templates on the category to extract data from the main item. Commons categories are often sitelinked to the main item directly, but this can't be done in some cases because a gallery is already sitelinked. The new wording doesn't mention Commons specifically, or include the footnote referring to an old RFC. Ghouston (talk) 06:04, 10 June 2018 (UTC)

I agree with not discriminating against Commons and applying any inclusion/exclusion criteria to all wikis, but I don't think we should restrict category items like that. It would make things unnecessarily complicated and create more maintenance work keeping track of and deleting categories which are no longer notable, re-adding statements when a category becomes notable again, etc. I personally think we should allow more or less all categories. If there are specific types of things we want to exclude, they should be added to Wikidata:Notability/Exclusion criteria (e.g. category redirects are already listed there). - Nikki (talk) 14:18, 27 June 2018 (UTC)
It wouldn't bother me if all category items could be created. There's also an argument from Commons that allowing items to be created for intersection categories (Commons has millions) would be useful, since infoboxes on such categories can display which main items the category is an intersection of. Such linking may also be useful for future structured data on Commons purposes. Admittedly the current wording already permits the creation of category items for categories from all projects except Commons, so the wording I suggested would loosen the requirement on Commons but restrict it on every other project. The question is whether anyone (still) has an objection to creating items for intersection categories from Commons. Ghouston (talk) 01:20, 29 June 2018 (UTC)
Category:Fox Glacier / Te Moeka o Tuawe (Q55246571) is an example of an item which violates the current policy, and which in principle could be nominated for deletion, but which is needed for the Commons category sitelink and the infobox on the Commons category. Ghouston (talk) 02:01, 29 June 2018 (UTC)
I undo the edit about Point 1 because this is probably the most important page on Wikidata and if you want change this you must ask a Wikidata:Requests_for_comment. It isn't sufficient a simply topic in this page. The consensus is insufficient. --ValterVB (talk) 11:12, 1 July 2018 (UTC)
@ValterVB: Considering RfCs here seem to last a year each, I'm not sure that's a useful way forward. I guess this could be raised at project chat (again!), if need be... Thanks. Mike Peel (talk) 11:56, 1 July 2018 (UTC)
Personally I haven't a stron g opinion about thsi topic, but surely to change rules on notability is necessary a strong consensus. And we can't have it without a preventive discussion. If it is necessary a lot of time isn't a problem, when we reach consensus we can all work together to apply it --ValterVB (talk) 12:10, 1 July 2018 (UTC)
  • It might be easier to store these things directly on Commons. The countless discussions of the topic haven't convinced people that there is much benefit from these things at Wikidata, especially from the point of view of frequent users of Commons. Given that Commons is changing anyways, I don't think Wikidata is a suitable place for its temporary construction equipment. Maybe it's simply time to archive sitelinks to Commons galleries now. If we add 4 million items only to delete or let them linger afterwards, the strained Wikidata infrastructure is burdened for no common long term benefit.
    --- Jura 12:14, 1 July 2018 (UTC)
  • All items that have a Commons categories should have as site link the link to the Commons category, and if a gallery exist then it should be listed as a property. That will solve all the issues, included all the issues relative to potential info-boxes, and also all potential issues of notability here in Wikidata. Christian Ferrer (talk) 12:19, 1 July 2018 (UTC)
    • It's not needed for infoboxes to work there. Notability at Wikidata currently excludes these sitelinks. To clean up Commons, importing the defects here isn't really helpful for Wikidata.
      --- Jura 12:27, 1 July 2018 (UTC)
      • @Jura1: The infoboxes work easiest using the sitelinks, but it's true that you can set manual qids and they'll still work. However, that means messing around with figuring out with qid numbers, rather than text, and that creates an unnecessary barrier for editors creating the links between the two. Also, it means a lot more manual work, as they can't be bot-added without the sitelinks. Plus, maintenance in the longer term is a pain, as you then have to maintain the qid matches on commons, rather than on wikidata - and I suspect that categories won't be going away any time soon... Thanks. Mike Peel (talk) 20:21, 1 July 2018 (UTC)
Even if not needed, of what I say is not false, every Wikidata items enough notable to exist should have as site link to Wikimedia Commons, when they exist, the Commons categories (which is the norm in the meaning that all files are categorized but not all are in galleries). Christian Ferrer (talk) 12:32, 1 July 2018 (UTC)
If what I just said was in effect then nobody will search to create Wikimedia Category items especially/only for Commons Categories, this is, from my point of view, obviously a fact. Christian Ferrer (talk) 12:58, 1 July 2018 (UTC)

There are a number of points I would like to make here:

  • Firstly, a fundamental part of what Wikidata is for is to serve the structured data needs of the whole Wikimedia ecosystem. To be sure, Wikidata is here for a lot more than that as well. But if a Wiki project has a structural need for structured data, we are not at liberty to ignore that. It's part of what the WMF pays to keep the lights on for.
 
  • Secondly, the existing clause needs to come out. At the moment it serves only to mislead and confuse. To start with, it claims justification by a citation to an RfC (reference 7 this version) that has since been rejected in every particular. Any reference to that RfC from a current policy page is therefore downright confusing. But more fundamentally, the purpose of policy pages is to document current practice. The limitation that this clause sets out (no item that only sitelinks to a Commons category) is not current practice, and hasn't been for years.
The image on the right shows what has been accepted for at least two years. In the simple case when only a Commons category exists, it can sitelink directly to a main article here (as indeed 1.35 million currently do) (not shown). But in the case when eg a Commons gallery exists, then the agreed convention is that the Commons gallery should have the sitelink to the main item (since there can only be one), and in such cases the Commons category should be linked to an auxiliary category-type item here, with that and the main item tied together by reciprocal category's main topic (P301) and topic's main category (P910) statements. This has been aired many times over the last few months (eg most recently at Project Chat just a couple of weeks ago); it documents overwhelming current practice; and there is clear consensus for it -- a consensus already embodied in the existence of thousands of such items, even before the new items created this week.
  • A third thing to recognise is that needs evolve. Above, I said that a fundamental (though never exclusive) part of Wikidata is for is to support the needs of other wikis. In the beginning, those needs were simple, restricted to simple interwiki-ing. WD:N takes account of that need, by saying that if there are two pages that could/should be joined by an interwiki link, then we must permit an item here to support it.
But needs evolve. Wikis become able to use Wikidata content in more sophisticated ways, which is also a legitimate need. In particular, Commons now has a range of standard templates, such as c:Template:Wikidata infobox, c:Template:Interwiki from wikidata, and c:Template:Taxonavigation, with usage counts going into the millions, that draw on Wikidata, and expect either a direct link or link using the above mechanism via an auxiliary category-type item. As an example like c:Category:Grade I listed churches in Bedfordshire shows (infobox template on the right), even a simple category combines topics (P971) statement here is already enough to support a description of the categories that -- for the first time -- is immediately understandable in all the languages Wikidata can translate its labels into. This is exactly what Wikidata was invented for. It is a huge step forward for Commons; as well of course as being a very powerful engine for improving Wikidata, as people seek to extend or correct data, and perhaps above all to fill in missing translations into their own languages. It makes no sense to be unambitious here.
  • Fourth, we need to have an eye to the future, and make sure we are doing what we can to help the work people are trying to do. Getting as many sitelinks as possible for Commons categories is now a critical priority for the Structured Data initiative, because it is through file categorisation, and specifically from wikidata items linked to those categories, that realistically the first structured data will be drawn. Currently there are about 1.9 million Commons categories matched to Wikidata items; but about 4.8 million that so far aren't.
A crucial step towards that is putting in all the sitelinks for categories we can match to Wikidata items, (i) so that those relationships are accessible for querying at scale, and (ii) to clear them out of the way for database queries trying to identify what's left. It also means we can put in infoboxes for those categories at the same time, very worth having in their own right, as already noted; but also getting them out of the way of a drive to get Commons editors to add and improve infoboxes (effectively a grass-roots drive to add data to Wikidata items to make them more complete, and get more of them matched to Commons categories, so those links and that data are then there and ready to use for the Structured Data project to call on).
  • I am happy to discuss refining what the exact terms of the new text should be.
But the old text needs to come out, straight away, which is why I am going to pull it again now, because it is a lie, that is actively misleading people. Citation 7 is wholly inappropriate, being as the RfC it links to has since been rejected in every aspect; and it is highly misleading and simply not true to pretend that items for Commons categories with just that sitelink are not permitted. We've got thousands of them, have had for years, and it is fatuous to pretend we are going to cripple the Commons templates that are now making such good use of them, still less to encourage people to do that. The old clause is dead, and it's starting to smell. The time to cut it out is now.
I'd also note that there's no practical problem anyone has yet claimed these items are causing, nor anyone identified any practical alternative to what is being done. Jheald (talk) 22:30, 1 July 2018 (UTC)
It's a very enticing vision.
But, myself, I am dubious that the new search will ever kill off categories and the category hierarchy they sit in, no matter how good and slick the search interface becomes, and how many very nice new features and alternate options to view and order or segment and filter the results that it offers.  :::Nor do I think the community would allow them to ever be completely replaced, because for all the wonders of search, there is something very transient and impermanent about the results. I think there will continue to be a demand from people to be able to create and curate views of parts of the collection with more of a sense of concreteness and solidity, which they can work on as a finite focus project to improve, annotate with relevant additional information and links, and which are there as a specific landing page for people coming to Commons from a particular wiki article. There's a lot of curation and personal engagement from Commons editors that has gone into categories, and I don't think that will be given up lightly, nor the hierarchical structure that makes these views navigable -- and which provides useful pre-curated, pre-computed ways to drill down through the collection.
Eventually I expect the two systems will find ways to continue to persist side by side -- and enhance each other. If Structured Data on Commons does take off (by no means a given at this stage), it should make it possible to add a lot of machine-support to categorisation, making it much more robust and complete; and I think it's also likely some of the additional view options (eg show in order of quality; in order of date created; in order of date depicted; etc) would also be ported to categories, making the category-viewing experience richer.
In the other direction, one shouldn't underestimate the sheer amount of work it's going to take to get the Structured Data search to anywhere near the level of the current category system. Even the search mechanics are decidedly non-trivial. Consider a search such as eg: "Portrait of a man in a hat". First the user needs to translate that (presumably via the faceted menu system) into depicts (P180) human (Q5), qualifier sex or gender (P21) male (Q6581097), plus depicts (P180) hat (Q80151), but then to satisfy that the system needs to retrieve results from search over all men and all hats, because a picture like Portrait of Doge Leonardo Loredan (Q1759759) will not be tagged depicts (P180) human (Q5) + depicts (P180) hat (Q80151), but rather depicts (P180) Leonardo Loredan (Q250210) shown with features (P1354) Doge's hat (Q1134210).
And of course the data returned from the Structured Data search will only be as good as the tagging -- for example, Bellini's doge doesn't currently have a shown with features (P1354) Doge's hat (Q1134210) qualifier, so wouldn't be returned. 40 million images to comprehensively describe with tags is going to be a mammoth undertaking, and mammoth to maintain. In my view the initial wave of tags are going to have to come from the categorisation, because there is nowhere else to realistically get the information from, a form that is mapped (or even readily mappable) to the vocabulary of Wikidata. That's why, to make a success of structured data, in my view we need to be getting category combines topics (P971) descriptions in for categories like "Interior of Church <X> in Place <Y>", because often that intersection category is the only categorisation information on the image. If we can systematically record what categories like that represent, then we will be able to immediately tag for Structured Data that the image is of Church <X>, specifically the interior. But without having translated the category, we're not going to be able to do that. So that's why I think it's so critical to map the meaning of categories, including intersection categories, to the Wikidata vocabulary now, so that that is already done by the time the depicts (P180) property for images starts becoming available this October/November. In my view, it's going to be absolutely essential for the first wave of tagging. But your question was directed at the longer term, and longer term too I think categories are going to continue to be relevant, because I think they give a structure for curation that we are going to continue to need. We're going to need to go on adding tags to images to improve search, even after the first wave. And I suspect that category refinement, using existing tools like Cat-a-lot, is going to continue to be one of the most efficient and inviting ways to do that. We may well develop similar tools to refine a search result by adding tags, but I am not sure they will have the same appeal, of having completed a work of curatorship that one knows is then in the structure, and that one can point to or link to as the work one has done. My expectation is that I don't think Commons will let that go lightly. Jheald (talk) 11:32, 3 July 2018 (UTC)
In fact I commented here because someone put a message on my talk page after I nominated items (created by me) for deletion. But the truth is that I'm not competent at all, and that I'm not here in one of my main subject of interest. Therefore no need to ping me or to come talking about that in my talk page, thanks you, and sorry again if I disturbed someone. Regards, Christian Ferrer (talk) 11:46, 3 July 2018 (UTC)

I see the need to adapt our policies, however I have some concerns:

  1. There are around 4.1M category items right now in Wikidata, so this proposal roughly aims to double that number. However, even rather simple queries involving category items are at the edge of timing out already right now. We should make sure that Wikidata's infrastructure is capable of dealing with the extra items as well.
  2. The notability criteria at Commons sometimes seem even less restrictive than ours, and my feeling is that a policy change as proposed would offer an easy path to put purely promotional content to Wikidata via a Commons category that nobody contests. How does the Commons community try to avoid such behavior?
  3. Many Commons categories are technical intersection categories combining two or more distinctive properties of the members. Their purpuse is to provide ways of access that the category system otherwise lacks (dynamical intersection), but they are there in substantial numbers. I can't spontaneously image any scenario where intersection categories need a Wikidata item, as long as there are no other interwiki links than to Commons. Can we somehow exclude intersection categories from being connected to Wikidata?

--MisterSynergy (talk) 20:20, 4 July 2018 (UTC)

@MisterSynergy: On your last point, it is useful to have Wikidata items for intersection categories, and (as per this proposed text) I would specifically not exclude them, for at least two reasons: (a) because the Wikidata infobox template is actually very useful on such categories, translating the meaning of them for non-English speakers (see for instance the example of c:Category:Grade I listed churches in Bedfordshire noted above); and (b) because such categories may nevertheless contain images -- indeed many terminal categories (ie categories with no subcategories) are in fact intersection categories, or can be thought of as such, eg "interior of church X" -- and so we're going to need the meaning of the category translated into Wikidata items, in order to be able to suggest Structured Data topics for images in the category. Jheald (talk) 21:00, 4 July 2018 (UTC)
I'm not really up to date about Commons structured data progress (unfortunately), but I always thought that the initiative will make the intersection category monster superfluous once more (better) structure is available. Am I wrong here, and they are going to be retained?! That would be a huge mistake to my opinion. --MisterSynergy (talk) 21:18, 4 July 2018 (UTC)
@MisterSynergy: See my answer to Christian Ferrer, a few paragraphs above. But a few points: (i) Many of intersection categories are actually right at the bottom of the hierarchy, so they would be what one would directly to read topic information from; (ii) per Mike Peel's study of 1000 yet-to-be-matched categories mentioned above, perhaps less than half of the remaining categories are intersection categories; (iii) faceted search will give people a powerful different way to drill down to Commons content. But as I wrote to Christian Ferrer, I think categories will continue to have their uses in parallel with it; and those categories will continue to need to be linked hierarchically, to fit them into an organised comprehendable structure. That naturally leads to the intersection categories. It's possible that there won't be so many people creating new ones; but I don't think the old ones are likely to go away; and in any case I suspect (iv) there will continue to be some value in having pre-curated ways to facet the collection, in parallel to what may be possible with the new search. Jheald (talk) 21:56, 4 July 2018 (UTC)
Thanks, although I really don't like this perspective (to be honest: I can observe something similar at dewiki. A considerable amount of editors have invested their entire Wikipedia career into the categorization tree, and they are now unable to let go in favor of a superior technology).
Actually, my observation is that intersection categories are almost always somehow incomplete and badly maintained, very often very inconsistent by not really inheriting the properties of the supercategories, and furthermore much less stable in the sense that they may be subject to large-scale deletion procedures much more than regular non-intersection categories (I am the one who takes most of the workload to remove the residual empty items from Wikidata these days). Since Commons uses them much more than any other project, I see a considerable amount of extra work arising particularly from intersection categories for our community as well. --MisterSynergy (talk) 22:07, 4 July 2018 (UTC)
@MisterSynergy: The completeness is something I think may get a big help from better integration with Wikidata, making it easier for bots or machine-assisted editors to discover what ought to be in the category, and compare it to what actually is these. As to whether there's a lot of deletion, I'm a bit dubious. It's not something I had particularly noticed at Commons. Jheald (talk) 22:35, 4 July 2018 (UTC)
I'm also a bit surprised with the focus on categories, because as MisterSynergy said they could be replaced with superior technology. As I see it, a category could be replaced by a (cached) query. We still don't have the means to do that, but that doesn't mean that it is not possible. Instead of including manually the category or intersecting category on each file, it is better to add the relevant information that will make the file show up in all relevant queries. It should be possible to have a hierarchy of queries too, in fact I find it better to have subqueries than to have subcategories. I don't understand why this option is not being considered to offer an alternative to categories. Is it because people are too invested in categorization? Or because they cannot envision something different? I would understand the second because it doesn't exist yet, but I feel it is important to explain that other options are possible and that categories (in the classic sense) are not the only way to do things.--Micru (talk) 11:52, 5 July 2018 (UTC)
  • I would support this for one simple reason besides all the others: We could delete P373. We should manage those connections via our data item connections, not by hard-coding the name of a category into an item. --Izno (talk) 18:02, 8 July 2018 (UTC)
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata_talk:Notability/Archive_4&oldid=725886769"
Return to the project page "Notability/Archive 4".