Property talk:P360/Archive 1

From Wikidata
Jump to navigation Jump to search
This page is an archive. Please do not modify it. Use the current page, even to continue an old discussion.

Label "list of"

Please avoid change the English label away from the initial proposal ("list of" or at least "this is a list of"). If needed, you might want to suggest a property. --  Docu  at 17:28, 28 March 2013 (UTC), edited 17:29, 28 March 2013 (UTC)

Apply only on "real" lists please

This property can be useful when applied on items that describe 'lists', not on disambiguation of names. Therefore, I hope someone will delete this property on all items where q11651459 (name disambiguation) is already present. User:Michiel1972

I oppose. Some disambigs contain only specific type of elements, so the property can be useful. --Infovarius (talk) 14:43, 1 July 2014 (UTC)

P360 in episode list items

Is is a list of (P360) an appropriate property for a program episode list, to link that item to its program series item? For example, would these be valid?

--Closeapple (talk) 02:17, 19 May 2014 (UTC)

As some kind of workaround probably valid. Maybe also see https://www.wikidata.org/wiki/Q462612 on this. THere someone used "series" as a qualifier to specify the series. But to be honest I think "series" property is not something that should be used us a qualifier. I like the solution at https://www.wikidata.org/wiki/Q784253 better. It uses "part of" to specify to what item/series that list belongs to. Though from the definition of "part of" that's also not the correct tagging. --Bthfan (talk) 13:45, 23 June 2014 (UTC)

list of engineers and list of women engineers

compare:

The top of w:de:Liste von Ingenieurinnen says:

Diese Liste von Ingenieurinnen umfasst Frauen, die sich im Ingenieurwesen ausgezeichnet haben. Die Liste dient dazu, das qualitative und quantitative Ungleichgewicht zwischen Artikeln zu berühmten Männern und Artikeln über berühmte Frauen in der Wikipedia auszugleichen.

google says that means:

This list of engineers includes women who have excelled in engineering. The list is used to compensate for the qualitative and quantitative imbalance between articles about famous men and articles about famous women in Wikipedia.

I originally thought the narrower list was a general list of engineers not limited to women. How to annotate the narrower list? it "is a list of" engineers. but with an extra qualifier limiting to female. ? --Jeremyb (talk) 19:10, 23 December 2014 (UTC)

I considered that but didn't know if that would mean members have to pass both criteria or if it was enough to be just a woman or an engineer but not both. --Jeremyb-phone (talk) 19:50, 23 December 2014 (UTC)
Another way: create item 'female engineer'. — Ivan A. Krestinin (talk) 20:56, 23 December 2014 (UTC)
For Q15832361: with "human" and qualifiers "occupation : engineer" and "sex or gender : female" reasonator outputs a list. --- Jura 14:12, 22 February 2015 (UTC)
I suppose that's not what you were looking for. Anyways, it's unlikely that engineers who don't have an article in Wikipedia would have a Wikidata item .. so reasonator can't output anything that would "rebalance" ;) --- Jura 14:16, 22 February 2015 (UTC)

P360 and categories

@Jura1:, about [2]: is a list of (P360) claims for categories will be false in many cases. Usually categories are not homogeneous. For example birth place category can contain list articles, another categories, articles about human groups and etc. Category is more complex entity than list. It is not very good fact, but it is real Wikipedia practice. — Ivan A. Krestinin (talk) 10:50, 28 February 2015 (UTC)

There is already a discussion about this at Wikidata:Project_chat#.22is_a_list_of.22_on_categories and at least two other places. Maybe it's better to join there. --- Jura 06:28, 1 March 2015 (UTC)
English, Russian or Chinese chart is good place to talk, but can not be used for decisions like property domains extending. — Ivan A. Krestinin (talk) 07:13, 1 March 2015 (UTC)
If a category contains a mixture of things, it is straightforward to specify more than one P360 criteria for inclusion in it. Specific anomalous items can be marked by category's main topic (P301) and the properties "List related to category" and "Category auxiliary item" currently proposed at WD:PP/GEN. Very diffuse categories can also be modelled using P360 by specifying a very general P31 for items to be instances of subclasses of + more specific qualifying properties. Jheald (talk) 11:13, 1 March 2015 (UTC)
Its are not anomaly items, its are normal for Wikipedia. Categories usually uses "related to" inclusion criteria. Some users are try to use more strong criteria (like "instance of") for some categories, but without global success. Also the most categories contains at least two item classes: articles and subcategories, sometimes files and templates. What will P360 mean for these categories? Will we add <P360> Wikimedia category (Q4167836) to every category? Multiple P360 approach is not good idea, for example: will we add claims <P360> "human", "human group", "fictional hero", "cat", "dog", "category" to every birth place category? Or we will monitor all these categories in all Wikipedias and add these claims at the moment then at least one item appears? I think we need to use less strict claims for categories. Its will better describe real Wikipedia situation. — Ivan A. Krestinin (talk) 16:47, 1 March 2015 (UTC)
Your friendly administrator here. I don't like edit wars so I protected this item for a week so you have time to discus this. I hope you reach a consensus. Multichill (talk) 17:30, 1 March 2015 (UTC)
@Ivan A. Krestinin: So it's not going to be perfect. But it still can be useful, even if it is not perfect. There's barely a property on Wikidata that doesn't produce constraint violations, usually including a fair number of WON'T_FIXes. But we don't shut Wikidata down, because even with the constraint violations and the WON'T_FIXes, the property is still useful.
This property does a pretty good job of describing categories, in a way that is incredibly useful for data extraction -- which is why User:GerardM has already applied it to 2,000 of them, and shows no sign of slowing down. If he can capture the essence of the category, that's already really useful for him -- eg the point going down the category tree when the category stops being a narrower and narrower collection of a group of painters, and starts being a category about the works of one painter. P360 expresses what the essence of the category is about, in a way that is very machine readable, and easy for him to use to identify properties that ought to be added to items that are members of the category. The kind of exceptions at the key P31 level that you've raised don't bother him, because it is enough that he can simply skip over them and not process them. On the other hand, by having this machine-readable characterisation of the category, for the overwhelming majority of members of the category that do conform, he can do something useful. That is something worth having.
Moving on to your "birth place" example, one way to deal with this would be to identify the top level P31 criterion as P31 => entity (Q35120), with qualifying criterion place of birth (P19) -> $1. But it's probably more useful to go with instance of (P31) => human (Q5) and accept that there will be some things on the constraint violation report, because the more specific P31 would allow things of a quite different nature that might be in the category (eg "Society of people born in $1") to be excluded. A third option would be to define a new item that was a superclass of human, fictional human, animal and human group; and give as top level criterion that items would be members of that, subject to the remaining properties specified in the P360 qualifiers. The key design goal built into Wikidata is to make possible experimentation and flexibility: so that users do not have to sit on their hands and do nothing because they cannot think of a perfect solution; instead the ethos is to experiment, even if the experiment is not perfect, to "discover by doing" -- because something does not have to be perfect to be useful, and because it is by putting something into practice that one can really get to see and understand what is the nature and extent of what is imperfect; and then consider from that actual experience what make it one step less imperfect or one step even more useful. Using P360 on categories is already useful; and it is by using it that we will best learn how to make it better or use it better. And if there are some categories where P360 doesn't get used at all, that's fine too.
So it doesn't matter (IMO) if it is not perfect; it matters that it is useful, and gives us something that can be used and experimented with and learned from. So I'd be quite happy, at least to start with, for P360 to focus only on the articles that a category contained. (Though I don't see any objection to a P360 specifying that P31 => Wikimedia template (Q11266439)). Files shouldn't have items on Wikidata, so the issue doesn't arise. Sub-categories are slightly different. Any category may contain subcategories; and their nature can be rather different to the parent category (eg a category of painters giving way to a category of works by a particular painter). So for subcategories the first important thing seems to me to be able to retrieve what are the subcategories -- which could be done through a new property parent category at WP:PP/GEN -- and to be able to specify what might be in the subcategories, which would be done through their own P360s. So I don't see any benefit in including subcategories in parent category's P360.
Finally, we should flip this around, and ask "what is it that is gained by restricting P360 to lists?" I don't see that there is anything that I have suggested that would make P360 work any less well for lists. So what is to be lost by extending it? Jheald (talk) 23:49, 1 March 2015 (UTC)
A list is more complicated than a category because in a list there are often references to all kinds of everything that should not be included. Categories are simpler. When an item fits the bill, they really fit. It is best NOT to descend as a rule into subcategories for automated harvesting. GerardM (talk) 04:19, 2 March 2015 (UTC)
Creating automation based on invalid data model is very dangerous think. Now many botmasters made same error: they try to use category or template as datasource without data filtration/validation. As the result every week somebody are trying to add human-related property to human group using some automation. It is not easy task to revert these changes and clarify the error to every new botmaster or automation user. Adding strong P360 claim to categories will force this process. — Ivan A. Krestinin (talk) 07:40, 2 March 2015 (UTC)
@Ivan A. Krestinin: People are going to try to harvest data from categories anyway, whatever we do or don't do. Adding an indicative property to better describe the category and show what the category should contain (thereby allowing a constraint violation list to be made of items to be careful about) is a step towards more filtration and validation -- as well as a step to help us better understand and describe our own structures. Jheald (talk) 08:42, 2 March 2015 (UTC)
Wikipedia does not use term "should contain" for the most categories. Wikipedia usually uses more soft criteria: "article is related to". So modeling in terms "should contain" will not affect to real life. This will produce additional misunderstandings and additional errors. It is better to use models that better describes real situation, this allows to avoid errors. — Ivan A. Krestinin (talk) 09:02, 2 March 2015 (UTC)
@Ivan A. Krestinin:: We're not trying to tell Wikipedias what to do. We're trying to describe what they have done -- in a way that is machine-readable and machine-interpretable. The description won't be perfect -- there will still be a constraint violation list. But the P360 description can capture an awful lot of what is going on, in a way that is already useful and being used by eg User:GerardM. Furthermore, the exception list generated is exactly the data needed to discuss how to model such a category better, on the basis of its actual concrete contents rather than theoretical speculation.
If you have a proposal for summarising a catetegory's contents that you think would be more useful than P360 for users like User:GerardM and would be able to give machines a better actionable idea than P360 of what's in the category then let's hear it. Otherwise don't let the best be the enemy of the good. Jheald (talk) 10:55, 2 March 2015 (UTC)
I reviewed many P360 claims created by GerardM. The most claims are false. Its can be useful, can be used by automation, but this not make its true. Better model can be based on existing properties like category combines topics (P971), category's main topic (P301) or use another new property like "many articles from this category are instance of" or "this category is related to theme(s)". — Ivan A. Krestinin (talk) 19:25, 2 March 2015 (UTC)
@Ivan A. Krestinin: "Most claims by User:GerardM are false". Can you give some examples? Also, can you claify what you mean by false. Are you asserting that the P360 does not accurately characterise the majority of items in the category? I would find that surprising. And even if true, probably fixable. Or, are you asserting that there would be at least one item in the category that would find itself on a list of constraint violations of the P360 ? That would not surprise me; and furthermore I would not be troubled by it. I don't regard the aim of a category P360 as being to give a perfect description of the category; rather, to give a good (and useful) description, true for most items, while some exceptions that can be identifed.
category's main topic (P301), category combines topics (P971) etc do not give an adequate substitute. In particular, P971 fails to specify the relationship between its attached topics -- does the category contain items for paintings that are of London, or paintings that are in London? P971 doesn't give a specification that is sufficiently detailed to know -- and so cannot be used operationally to say "yes, this is a category in which it is appropriate to place this item". P301 can be useful, if such a related item exists -- but it is hard to translate from that item to how properties will typically be specified for members of the category: eg knowing that category's main topic (P301) -> comedy horror (Q224700) doesn't indicate that a typical member of the category with have instance of (P31) -> film (Q11424) and genre (P136) -> horror film (Q200092) / subclass and genre (P136) -> comedy film (Q157443) / subclass. So it doesn't give an operational test that this is a category such a film probably fits well in; nor a test that the current properties of an item don't appear to match the general membership of the category -- ie what is directly specified by the P360 syntax. So they do not adequately convey the same information. Jheald (talk) 20:35, 2 March 2015 (UTC)
For example: Category:Photographers (Q6473572), it contains many non-human (Q5) items in ruwiki: Category:Fictional photographers (Q7692510), Q9555858, list of photographers (Q1091260), photographer (Q33231) and other. Another categories can be clean from non-Q5 items at this moment, but non-Q5 items are acceptable and valid for its. — Ivan A. Krestinin (talk) 20:55, 2 March 2015 (UTC)
@Ivan A. Krestinin: So: photographer (Q33231) would be marked as an exceptional inclusion by the property category's main topic (P301).
list of photographers (Q1091260) would be marked as an exceptional inclusion by the proposed new property List related to category.
The categories Category:Fictional photographers (Q7692510) and Q9555858 would be exceptional inclusions simply by being subcategories (which are unpredictable enough that they should always be treated sui generis).
Probably there would be some other violations of the P360. But (i) it is capturing logic that can accurately summarise the inclusion of most members of the category (and could be used to suggest other items that might be included in the category, if they do not already fall into one of its subcategories); (ii) it is identifying a set of exceptional items, which eg one might want to exclude from specific processing or harvesting being done on the regular items; (iii) by being able to create an easily examined list of the exceptional items, it provides the user with just what is needed to suggest a more accurate characterisation of the category -- eg perhaps a more precise criterion at the P31 level would be a class that includes both human (Q5) and fictional human (Q15632617) as subclasses.
Will a provided P360 usually provide a perfect characterisation of a category? Probably not. Will it provide a characterisation that is useful? IMO usually yes. Will it provide a characterisation that can be improved, and through its own shortcomings reveal what it is about itself that might be improved? IMO again yes. Is it therefore useful to include on a category item? My answer has to be: yes. Jheald (talk) 22:21, 2 March 2015 (UTC)
Note added: Essentially this proposal was previously made a year ago, with User:Filceolaire and User:Magnus Manske both registering support, and it seems no opponents. Jheald (talk) 23:36, 2 March 2015 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘

section break 3 March

Hi all, is a list of (P360) should be definitely be used on categories in my opinion. Points (i), (ii) and (iii) are clearly all very good reasons. The discussion linked to just above I think gets to the route of the issue. There is no fundamental difference between a list and a category - they are both just a group of "things" matching a specific criteria. Whether you include related information or not is just a simple choice you could equally apply to a list or a category, so should not really come into the discussion.

In any case, if P360 was currently in widespread use for categories, I can say for sure that Histropedia would already be making use of it. It actually would have made a huge impact on the amount of data we were able to extract during our recent import of the English Wikipedia category system - we had to resort to zero subcategory depth in the end to avoid having thousands of off topic events appearing on timelines. One final point I'd like to mention - the value given for P360 also contains the information needed to create a query for describing the category, which is an immensely valuable bit of information in itself. NavinoEvans (talk) 02:54, 3 March 2015 (UTC)

I don't care if this property is used for categories but I think you will never reach a sufficient high quality if you extract data based on this property. Take as an example Category:Deaths in Switzerland (Q6334741). Most linked categories do indeed list people died in Switzerland but the English category lists other stuff. On Category:American composers (Q6288115) the English category contains 12 exceptions out of 27 pages. And there are also is a list of (P360) claims which are completely wrong and would cause thousands of errors if someone would start harvesting from it, e.g. [3], [4]. --Pasleim (talk) 16:29, 3 March 2015 (UTC)
@Pasleim: I think the way to view P360 is as identifying a sufficient criterion for inclusion, rather than a necessary criterion -- so that if an item has these properties, it would be appropriate for it to be in the category or one of its subcategories -- but not a necessary criterion because all sorts of other stuff gets tipped into categories. (Though one could hope to mark the nature of some of that stuff with category's main topic (P301), or the proposed List related to category, or the proposed Category auxiliary item.
Category:Deaths in Switzerland (Q6334741) is interesting, because en-wiki has the more narrower category Category:Death in Switzerland (Q8366631). Does this mean there's a language muddle in the sitelink? One really needs to look at how the parent cats correspond across the different languages, as would be facilitated by the proposed Parent category property, to see whether the en-wiki category reasonably does relate to the rest of the hierarchy in the same way as the versions of Category:Deaths in Switzerland (Q6334741) in most other language wikis. I suspect it probably does, so the sitelinking is reasonable. Having a subcategory with the same P360 would indicate that on a wiki that did have the subcategory, one could expect to find no items matching the regular criteria, only 'related' items. That's not something that would give me any great concern; though it might be a useful signal just to check the interwiki sitelink structure is appropriate.
What does actually concern me much more is the way P360 is currently being used on a number of list articles -- eg list of castles in Scotland (Q11810), where at the moment we just have is a list of (P360) -> castle (Q23413), with no mention of Scotland. It seems to me that this really does not capture the nature of the list, because just instance of (P31) -> castle (Q23413) is not a sufficient criterion in itself for any of them to be on it. So this is something that I think does need attention.
Finally, as to the question of fully automated harvesting using P360, this is a topic under discussion elsewhere, in this thread at Project Chat. The view of User:GerardM is that he thinks automated harvesting is possible, provided the P31 matches correctly. Follow-ups on this question maybe to that thread. What I think P360 certainly can do is to indicate what categories need to be considered in a hierarchical extraction, and which can be ruled out, even if the actual harvesting may still need to have a human sanity-check. Jheald (talk) 17:39, 3 March 2015 (UTC)
The error at [5] was bad. (Though the kind of thing that an exceptions report, highlighting what items were in the category that didn't appear to match the criteria, sould be very useful to help catch.) I am not sure I see the problem with [6]. Now I see it: University of Texas System (Q2140391) != University of Texas at Austin (Q49213). But is this not the kind of mistake that any mass upload can be vulnerable to? I'm not sure requiring AWB-style human confirmation would have made any difference. Anyone can make a mistake, which why thankfully there are tools to rollback a selected block of a user's edits. But maybe procedures can be improved. Jheald (talk) 17:46, 3 March 2015 (UTC)
I know that the automatic harvesting conversation is proceeding elsewhere, but I feel it's relevant to add here that there will never be any system that 100% reliably extracts data from the current form of the Wikipedia categories. Their structure and general use is so inconsistent that the best you can hope for is simply be getting as much useful data as you can, whilst minimising the incorrect stuff that creeps in. In this respect is a list of (P360) data does a great job, allowing us to at least exclude a batch of items that we know can't be a valid result for the search that's being carried out. This lets you delve a bit deeper into the the sub-category tree and gain a some extra results while still remaining more or less on topic.
On the main topic of this thread though, there doesn't seem to be much objection to actually using is a list of (P360) on categories - is there anyone who still feels it shouldn't be used in this way? NavinoEvans (talk) 00:13, 4 March 2015 (UTC)
I've changed sitelinks between Category:Deaths in Switzerland (Q6334741) and Category:Death in Switzerland (Q8366631) to more appropriate. --Infovarius (talk) 19:45, 9 March 2015 (UTC)

section break 4 March

Lets try to find decision acceptable for all. I think new property can resolve the most discussed issues. Something like property "the most articles from this category are instances of this class". Points:

  • it can be used same way as GerardM uses P360 currently, the only change is property ID in algorithm;
  • name/description says that the property is related to articles only, not to all another items listed in category (subcategories, files, templates and etc.);
  • name/description warns botmasters about exceptions, and requires additional filtration for automation algorithms;
  • it better describes real Wikipedia practice;
  • better job controlling, it does not cross with lists processing jobs.

Negatives:

  • +1 week for property creation.

Other:

  • Responsibility for errors are moved from Wikipedia authors to Wikidata botmasters.

— Ivan A. Krestinin (talk) 20:32, 4 March 2015 (UTC)

@Ivan A. Krestinin: Why do you think it should be a different property to the equivalent statement for lists? (Which eg Reasonator already knows how to process) Wouldn't it be more useful to be able to read across between the same property on a list item and a related category item, to identify anomalies between the two descriptions?
If we agree that "sufficient condition for inclusion in category" is of value, why not make it "sufficient condition for inclusion in category/list ?" Jheald (talk) 00:21, 5 March 2015 (UTC)
Category is a list of articles, subcategories, files, templates and etc. Your condition is related to articles only, not to all category elements. And it do not not cover all articles, only to many on these. So this property has another meaning, not "is a list of" or "sufficient condition for inclusion in category". — Ivan A. Krestinin (talk) 05:15, 5 March 2015 (UTC)
@Ivan A. Krestinin: But if you think about what "sufficient condition" implies (see articles on necessity and sufficiency (Q875267)), it means that such a set of properties is sufficient for an item to be included, not that every item included will necessarily have the indicated properties. So I submit that "sufficient condition for inclusion in category" is indeed the property I want, (and the single property that best characterises a category or list), regardless of whether or not that only explains most items and there may be some further edge cases. I also submit that in those cases where P360 is currently not giving a sufficent condition for inclusion, eg list of castles in Scotland (Q11810) => <P360> => castle (Q23413) with no qualifier, that is not a good use of P360, and is not giving a good characterisation of the list. Jheald (talk) 07:23, 5 March 2015 (UTC)
I am not about qualifiers and sufficient conditions. I am about instance of (P31) property of category items. E. g.:
Case 1: "list of castles in Scotland (Q11810) <P360> castle (Q23413)" is true statement because
"Balmoral Castle (Q42049) <P31> castle (Q23413)" is true and
"Braemar Castle (Q897169) <P31> castle (Q23413)" is true and
....
Case 2: "Category:Photographers (Q6473572) <P360> human (Q5)" is false statement because
"list of photographers (Q1091260) <P31> human (Q5)" is false and
"photographer (Q33231) <P31> human (Q5)" is false and
"Elena Mrozovskaya (Q15263131) <P31> human (Q5)" is true and
"Category:Fictional photographers (Q7692510) <P31> human (Q5)" is false and
"Q9555858 <P31> human (Q5)" is false and
....
So P360 has another meaning in case 2, not the same as in case 1. — Ivan A. Krestinin (talk) 21:31, 5 March 2015 (UTC)
@Ivan A. Krestinin: With respect, Ivan, I don't see the value of the property as you would wish to construct it. The point of having a list of castles in Scotland is that they are castles in Scotland. If the P360 doesn't tell you that, what is the point of it? Without the "in Scotland", i.e, without giving at leasr a sufficent condition for inclusion, it is not characterising the list. Jheald (talk) 23:04, 5 March 2015 (UTC)
P360 is used to specify all list items type. You want specify type of part list/category items and ignore another. This is another task. I do not think that mixing two different tasks in single property is good idea. — Ivan A. Krestinin (talk) 20:10, 6 March 2015 (UTC)
Don't forget that we can still easily generate a list of all uses of P360 on either categories or lists using the respective P31 for each.
e.g. here is all items using P360 with a qualifier of birth location, and here is the same query but with ONLY list articles. I personally see no problem with using the P360 for both, it's even more useful like that for all of my use cases. If a user is interested in finding a list of people who were born in London for example, they don't really care whether the Wikimedia ecosystem calls it a list or a category, they just want to find any resource that tells them the information they require. Whether it's classed as a list or category is covered by P360 P31 for anyone who needs to distinguish between them. NavinoEvans (talk) 18:54, 7 March 2015 (UTC)
How to find non-persons included to persons-only lists by mistake? How to query item types allowed for this list? — Ivan A. Krestinin (talk) 19:19, 7 March 2015 (UTC)
Finding persons included in non person list articles is not easy, because the actual things on the list are often not links to Wikipedia articles so can't be tied to Wikidata items (although a bot could easily flag up a list of all of the incorrect additions that it can find). With a category though this is very easy - for example this query shows all of the people who are in the category People from London but do not have both instance of (P31) human (Q5) AND place of birth (P19) London (Q84) (or anywhere within in the Administrative Territory of London). This can very easily be automated by creating a function that takes the value of P360 and automatically runs the appropriate query & category combination.
Similar to the above query, we can see a list of 'allowed values' with this query, which can also be auto-generated from P360 values. NavinoEvans (talk) 12:41, 8 March 2015 (UTC)
The task can not be resolved in principal because cases like Category:Photographers (Q6473572) present now. E. g. statement <P360> human (Q5) is used both for person-only lists/categories and for person related categories. In the first case "<P360> human (Q5)" mean that category must contain only Q5 items. In the second case non-Q5 items are allowed too. Both statement types are mixed in the same P360 property and can not be separated. — Ivan A. Krestinin (talk) 17:56, 8 March 2015 (UTC)
I don't think that P360 should be used to specify 'person related' categories. Simply 'a list of humans' is anyway not a sufficient description, it should always be more specific (e.g. Q5 with occupation photographer in the category page you've linked to). There can be more than one P360 statement to outline the exact types of content that are being included, which can then be used to analyse just how inconsistent the Wikipedia categories are. I think I've understand your point, but please fire back with more info if I've missed something :) NavinoEvans (talk) 15:13, 10 March 2015 (UTC)
@Ivan A. Krestinin: For what it's worth, lists can contain exceptions as well. For example, William Smith (Q226863) has is a list of (P360) => person (Q215627). But it also includes a couple of entries for non-people, at en:William_Smith#Non-persons, namely a painting and a college. So I don't see that is so different. Jheald (talk) 19:38, 14 March 2015 (UTC)
Our data is not ideal, fixed. — Ivan A. Krestinin (talk) 19:41, 14 March 2015 (UTC)
@Ivan A. Krestinin: No. You haven't fixed it by removing the P360 -- what you've done is removed valuable information. That page was overwhelmingly made up of people, with two exceptions. The P360 as it was was entirely appropriate, giving a good indication of what the page was about. That was worth keeping, not throwing away. Jheald (talk) 23:26, 14 March 2015 (UTC)
Removing P360 was not optimal way maybe. P360 for disambigs is not so simple question as for categories. Anyway this case has a little correspondence to original question. — Ivan A. Krestinin (talk) 20:39, 15 March 2015 (UTC)

Qualifier position held (P39)

Hi,

I just discovered a P360 claim with the qualifier position held (P39). This is quite used. Most of the time, when there was no qualifier and the value person (Q215627), I was just replacing the value by the function itself like here. What is the best practice ?

Louperivois (talk) 18:55, 13 May 2015 (UTC)

@Louperivois: Use instance of (P31) with position held (P39) as qualifier, this way Reasonator makes a list of people who meet those criteria. Sjoerd de Bruin (talk) 07:30, 22 June 2015 (UTC)
Sample: https://tools.wmflabs.org/reasonator/?q=Q1583726&lang=en --- Jura 08:01, 22 June 2015 (UTC)

Inverse constraint

@Sjoerddebruin:. "Inverse constraint" is probably a mistake.

In most cases, a list that is characterised by eg is a list of (P360) = human (Q5), qualified by position held (P39) = President of the French Republic (Q191954), will not have an inverse statement on human (Q5). Jheald (talk) 17:23, 7 October 2017 (UTC)

Oh right, I forgot how confusing this property is working mostly with the clear structure we use for categories now. Reverting. Sjoerd de Bruin (talk) 17:30, 7 October 2017 (UTC)

I don't understand. How can I make an actual list of e.g. "List of lighthouses in France" Q3253141

I saw 'list of women engineers (Q15832361)' for instance but is hasn't helped. Does it mean I have to find every item (e.g. French lighthouses) and there add another property to each? But even if I do that, I still don't know how to group the items, i.e. is there a real list where every item can be listed?

list (Q12139612) says "ordered". Why?

49.145.128.113 04:51, 24 January 2018 (UTC)


person → human

Most if not all lists of persons seem to be lists of humans. I added an Autofix to update this.
--- Jura 09:57, 13 April 2018 (UTC)

Retrieved from "https://www.wikidata.org/w/index.php?title=Property_talk:P360/Archive_1&oldid=824660658"