Wikidata

Wikidata:Properties for deletion/P10241

< Wikidata:Properties for deletion

individual of taxon (P10241) edit

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

There is no consensus to delete this property based on this discussion. However it is clear that a sizeable proportion of the Wikidata community feel that taxons are classes, and that these properties should be replaced by P31/P279. As this would be a major change and affects more than a single property, it would be best addressed in a request for comment (if anyone has the inclination to start such a discussion) — Martin (MSGJ · talk) 10:44, 24 May 2022 (UTC)[reply]

individual of taxon (P10241): (delete | history | links | entity usage | logs | discussion)

This property effectively replaces instance of (P31) for a narrow set of classes: taxons. It was discussed and proposed with fairly little activity, and only two support votes (including the proposer). Yet, Vojtěch Dostál is now using it to remove P31 statements at a large scale, leaving behind several items with no P31 statements at all, which of course results in many constraint violations (see K35 (Q72009266), permalink, for an example), as well as breaking queries (e.g. my moon trees map no longer has working colors/layers). I don’t think we have consensus for this migration yet, and furthermore I believe this property doesn’t make sense in the first place and should be deleted again.

My answers to the questions in the discussion and property proposal are, I think, fairly simple:

The property proposal doesn’t even explain how individual of taxon (P10241), once created, would be used to solve these issues, nor does it elaborate how this property is any different from instance of (P31) – in fact, one of the property’s aliases is “instance of taxon”.

Pinging discussion participants: Vojtěch Dostál, TiagoLubiana, ArthurPSmith, Jura1, UWashPrincipalCataloger, William Avery. (WikiProject Taxonomy is too large to ping, but I’ll leave a message on their talk page.) —Lucas Werkmeister (talk) 00:50, 13 January 2022 (UTC)[reply]

  Delete I agree that we should use instance of (P31). I don't think creating another subproperty is the solution to an issue caused by poor support for subproperties. I also don't think we should model non-human living things in a way which is the opposite of what we do with other data (a lot of the suggestions I've seen of what we should use for instance of (P31) instead of the species are things which would normally go in occupation (P106) or heritage designation (P1435)). - Nikki (talk) 01:44, 13 January 2022 (UTC)[reply]
  Delete, agree with Nikki. - PKM (talk) 02:50, 13 January 2022 (UTC)[reply]
  Delete It's clear that taxonomies can be classified just like everything else without requiring a special property. Lectrician1 (talk) 04:00, 13 January 2022 (UTC)[reply]
  Keep For the following reasons:
1) The property has >11000 uses. If replaced by P31, this will lead to 11000 constraint violations in property P31. @Lucas Werkmeister: is suggesting to circumvent this by adding subclass of (P279) to all taxa which are used as P31, which seems completely unsystematic to me. Why would you want some taxa with P279 and some without it?
2) I leave it to local taxonomists to consider if it would even make semantic sense to use P31:Taxon to indicate that an individual animal is classified as a given taxon. To me it doesn't. Same with P279:taxon in taxa items as discussed above. @Succu: with whom I discussed the P31/P279 logic just yesterday.
3) This problem was discussed just recently in Project chat and then you had the opportunity to discuss this in the property proposal. By deleting it again, you'd be saboteering our work. Why should someone create a new property ever again if there is a simple way for opponents to just wait a week after its creation, then nominate it for deletion - effectively demotivating everyone to propose large-scale changes... Vojtěch Dostál (talk) 08:21, 13 January 2022 (UTC)[reply]
Why wouldn't it make semantic sense? Taxon is a class of organisms and individual organism or animal is a specimen (instance) of some taxon after all.
To me it seems that considering the impact the property was created just too hastily. 2001:7D0:81DA:F780:D95:8B9D:98C7:D69C 12:48, 13 January 2022 (UTC)[reply]
@Vojtěch Dostál:
1) I think this is an overestimate: not all of the 11000 uses would have been a constraint violation in P31. For instance, you’ve edited some items I created, and I’m fairly confident those items’ P31 statements didn’t have constraint violations at the time. Furthermore, while I don’t think constraint violations should be the only criterion for the validity of this property, I’d like to reiterate that some of your edits introduced constraint violations, a point which AFAICT you haven’t yet responded to.
2) I don’t have much to say on this except that using P31 for taxons makes a lot of sense to me, and apparently to others too.
3) I’m sorry that the discussions turned out this way – I would also have preferred to object to this property before it was created – but sometimes it happens. Even if I had seen your project chat discussion (I don’t remember if I did or not), you never mentioned your property proposal there (you only wondered if a new property was warranted), so I probably wouldn’t have looked further into it. (The weekly summary where the property proposal was included happened to be the December 27 one – between the holidays and rC3 2021 (Q110157763), I did not spend much time looking at Wikidata then.) And while I sympathize with the demotivating effect of this deletion proposal (sorry), we can’t just let once-made decisions lock our data model forever in place, as you seem to suggest. (I also don’t really agree that this was proposed as a large-scale change – even the property proposal doesn’t mention that you intended to not only add statements of this property, but also remove thousands of existing P31 statements.) Lucas Werkmeister (talk) 01:03, 14 January 2022 (UTC)[reply]
@Lucas Werkmeister As for (1) I've made effort to add P31 to all items migrated to P10241. Some might have been accidentally left out but that's a simple thing to fix. I've added a correct instance to your example https://www.wikidata.org/w/index.php?title=Q72009266&type=revision&diff=1562092751&oldid=1559804057 Vojtěch Dostál (talk) 12:31, 14 January 2022 (UTC)[reply]
  Comment I also noticed these large scale changes to P31 values, and I find it a poor workaround to the problem that taxa items in the first place still don't make proper use of basic membership properties. Generally, taxa are classes, and so every taxa should have P279 statement, as other class items normally do. P279 value for taxa could be organism (Q7239), or something a little less generic. But ideally parent taxon (P171) could be phased out eventually and P279 could be used to model taxonomic hierarchy, so that it could be properly combined with other hierarchies (e.g. indicate that all species of a family are carnivore species by simply setting the parent taxon as a subclass of carnivore class). Not making proper use of P279 for taxa is a root of all sorts of deficiencies, e.g. see also comments here. 2001:7D0:81DA:F780:D95:8B9D:98C7:D69C 12:48, 13 January 2022 (UTC)[reply]
  Delete This is pretty clearly duplication of the semantic content of instance of (P31) → "some specific taxon, usually a species", which should itself eventually be subclass of organism (Q7239). P31/P279* is the absolutely standard and, IMO, logical membership idiom used for hundreds of millions of items. What is the actual need for this sub-property that cannot be achieved using that idiom?
If there's a good technical/ontological need for this sub-property, that's a pretty huge discovery, because it must also apply to most other "instance" items and would represent an end-to-end shake-up of the basic structure of Wikidata. Not that that's necessarily a bad thing, but consistency is absolutely critical, and so if that's where taxa go, everything else should follow (notably, occupation (P106) is also a deviation and starts getting metaphysical when you wonder what the difference is between "being" a writer and "doing writing"). Buildings should have their instance of (P31) claims pointing to subclasses of building (Q41176) stripped out and replaced with a "is a building of type" property. And so on. Specifically, there should be a very clear path to transitioning to a new, more consistent, status quo than introducing a sub-property and changing only a small domain of items. There's enough fragmentation, inconsistency and fuzzy modelling about as it is. Inductiveload (talk) 14:00, 13 January 2022 (UTC)[reply]
  Comment I wasn't part of the original discussion of this (I was pinged but didn't participate - I don't really have strong opinions on taxon-related items or properties). However, can we fix the constraints on instance of (P31) so that the value can have a statement with either subclass of (P279) or *any subproperty* of P279? Lucas Werkmeister you have some familiarity with constraint logic, is this possible? That would eliminate the need for the workarounds mentioned above. ArthurPSmith (talk) 16:07, 13 January 2022 (UTC)[reply]
I don’t think that’s possible, no. Lucas Werkmeister (talk) 00:47, 14 January 2022 (UTC)[reply]
I'd rather say that subproperty support would be yet another workaround to the actual problem of taxon items lacking P279 statements. 2001:7D0:81DA:F780:449B:6048:408E:76D1 10:34, 14 January 2022 (UTC)[reply]
  Comment No strong feelings about it, but I do feel P31 suffices. The ontological modelling of taxa is weird, though: it is a mix of people seeing it as a class and people seem it as a term. taxon synonym (P1420) treats taxa like terms, like lexemes, for example. IMO, if we agree on   Delete we are also agreeing that taxa should be modeled as classes (what I support). TiagoLubiana (talk) 17:20, 13 January 2022 (UTC)[reply]
As I understand it, despite using the work "synonym", the property taxon synonym (P1420) is referring to a synonym (Q1040689), aka taxonomic synonym, which isn't a linguistic/lexical concept, but rather a specific statement that someone somewhere has said that two taxa are referring to the same organisms (taxonomy being a complete mess, historically, this happened quite a lot!). It's more like a special case of said to be the same as (P460) with very specific semantics (completely unlike P460).
But taxa are very odd, since they have an entirely separate membership hierarchy to all other items. Inductiveload (talk) 18:06, 13 January 2022 (UTC)[reply]
Exactly this. “…weird, though: it is a mix of people seeing it as a class and people seem it as a term”. Taxa and nomina could be modeled separately. (Or maybe there is a more elegant solution to handle both taxonomic concepts and naming?) For example, the Pacific oyster has been classified as Crassostrea gigas (Q20857) or Magallana gigas (Q61695262). It's still the same species concept, the circumscription hasn't changed. But we don't have a single item for the concept of “pacific oyster”. What has changed is the concept of the genus it belongs to: Crassostrea in the broader sense (sensu lato) includes Crassostrea sensu stricto and Magallana (Q47463935). Those two senses of Crassostrea are distinct sets having different membership. But because they have the same name “Crassostrea”, we only have one item Crassostrea (Q542708). Stepping up above the genus level, pacific oysters are still a type of oyster; Crassostrea s.l., Crassostrea s.s., and Magallana are all sub-taxa of family Ostreidae (Q21154). This example isn't some weird edge case: lumping and splitting parent taxa is just one of the many ways that names can change, and happens in taxonomy and nomenclature (two separate but related disciplines) all the time. (In some ways, the distinction between taxa and nomina is akin to our separation of items and lexemes apple (Q89) / apple (L3257).) ⁓ Pelagic ( messages ) 20:00, 10 February 2022 (UTC)[reply]
  Comment Is Marius (Q15979689) a named individual of the species reticulated giraffe (Q27497311) and/or the subspecies Giraffa camelopardalis reticulata (Q656059)? From a nomenclatural perspective the names Giraffa reticulata and Giraffa camelopardalis reticulata refer to the same thing, because they have the same type (Q3707858). Adding different values of subclass of (P279) to them (Giraffa/Giraffa camelopardalis) would make no sense. From a taxonomic perspective both belong to the (sometimes monotypic monotypic taxon (Q310890)) genus Giraffa (Q862089). Giraffa is a name which refers to different taxon concepts (!=taxon (Q16521)) up to 4 recognized species (eg. Whole-genome analysis of giraffe supports four distinct species (Q110263251), First insights into past biodiversity of giraffes based on mitochondrial sequences from museum specimens (Q104624724), Multi-locus Analyses Reveal Four Giraffe Species Instead of One (Q26857906), Ungulate Taxonomy (Q110414936)). subclass of (P279) is not a replacment for parent taxon (P171) as suggested in the past and here again. We do not model taxa. We do model taxon name (P225) according to the different nomenclature code (Q2673092) and their relationship. --Succu (talk) 18:12, 13 January 2022 (UTC)[reply]
@Lucas Werkmeister: All of your above mentions examples have more than one issue. E.g. Sunny (Q14744025) is a dog breed (Q39367) in the taxonomy of Fédération Cynologique Internationale Groups (Q2150520). --Succu (talk) 19:13, 13 January 2022 (UTC)[reply]
Methuselah (Q590039) should be better somehow related to solitary plant (Q476164).--Succu (talk) 20:21, 13 January 2022 (UTC)[reply]
Moja (Q12038481) is/was a Gorillas in Zoo Praha (Q21167458) modeled as captive mammal (Q57812611)... --Succu (talk) 21:00, 13 January 2022 (UTC)[reply]
This view that we model taxon names, not taxa, does not reflect reality really. In general, current taxon items are explicitly set as instances of taxon (Q16521), while taxon name (P225) is given as merely an attribute to a taxon, taxon (not its name) has parent taxon (P171) etc. Some dissonance to that also exist in some items, but then this just needs to be cleared up eventually, keeping in mind that Wikidata is an ontological database. Any taxon as class warrants some P279 statement as well. If you want to model taxon names in particular, then you should probably set up this project in Lexeme namespace (see Wikidata:Lexicographical data).
It isn't clear what are you trying to polemize about with this giraffe example. What you say applies to P171 as much as it applies to P279, and a class with one subclass in itself shouldn't be a problem. You also say that "examples have more than one issue", but your subsequent response doesn't explain in any way what the issues are, as far as I can see. Contrary to your claims, Sunny the dog in particular isn't a dog breed, one's an instance of some breed which in turn is of some taxon (its subclass), and Moja the gorilla is an individual organism (as well as a true instance of some taxon) not a Wikimedia list article nor a group of organisms (if that's what you thought Q21167458 was). 2001:7D0:81DA:F780:449B:6048:408E:76D1 10:34, 14 January 2022 (UTC)[reply]
I do not discuss this with you Tamawashi. --Succu (talk) 19:48, 14 January 2022 (UTC)[reply]
I'm fairly sure you can't provide any behavioural evidence to this baseless claim. 2001:7D0:81DA:F780:A513:C337:6EC7:3D2F 08:25, 15 January 2022 (UTC)[reply]
Not randomly, all taxons items, just like any other class items, are expected to have P279 statement (see above). 2001:7D0:81DA:F780:A513:C337:6EC7:3D2F 08:25, 15 January 2022 (UTC)[reply]
Plus @Succu: it seems that Wikidata doesn't allow Fair Use, so I doubt if this property can be legally kept. Liuxinyu970226 (talk) 02:25, 26 April 2022 (UTC)[reply]
  Keep Solution using instance of (P31) is quite poor - hard to query and creating constraint violations. --Jklamo (talk) 01:59, 14 January 2022 (UTC)[reply]
  •   Comment Anyway, in case the decision to migrate back to P31 prevails, I would prefer if the current usage of taxa in P31 is cleaned up before migration, because most of them have nothing to do with individual organisms. See https://w.wiki/4gUi for items which currently include taxa among their P31 statements. Please don't create chaos where measures to introduce order were taken, even if you don't agree with the way it's been done.--Vojtěch Dostál (talk) 12:26, 14 January 2022 (UTC)[reply]
It's answered in the original post and in subsequent posts. The change that we currently face is/was to replace P31, not the other way around. Taxons are classes and the classification of classes on Wikidata normally relies on P279, so why wouldn't we add P279 statements to every taxon? In fact, this issue probably would have been fixed ages ago, if a few users (or maybe one user) weren't determined to remove P279 statements from taxons, like this, for unclear reason. 2001:7D0:81DA:F780:7D84:5196:57E3:FA94 13:45, 16 January 2022 (UTC)[reply]
As you know this problem was „fixed ages ago“ via parent taxon (P171). --Succu (talk) 18:57, 17 January 2022 (UTC)[reply]
„This edit“ becomes to that. What is a taxonomic subclass of Fraxinus excelsior (Q156907)? Anything equal or below plant (Q756)? Or taxonomic - according to a source - related? --Succu (talk) 22:28, 17 January 2022 (UTC)[reply]
Well, in this example you could have removed only P31 misuse, but for an unclear reason you also removed valid P279 statement, which is the problem here. Given P31 misuse in taxon item is irrelevant here. Also, I don't know what "problem" exactly you have in mind that was fixed via P171, but it definitely wasn't the one we are facing here. Regardless of P171, taxons as classes, in general Wikidata item classification scheme, still warrant P279 statements as well.
What is a (taxonomic) subclass of Q156907? I don't quite understand why you ask and what this have got to to do with previous discussion. 2001:7D0:81DA:F780:3D6D:39C0:BEF:717D 10:32, 18 January 2022 (UTC)[reply]
  •   Comment As Lucas noted, P31 wasn't working as he didn't notice before that "Methuselah (Q590039) isn't linked to Pinus longaeva (Q1116374) at all as far as I can see."
The property actually fixes items in a field that was poorly modeled with instance of (P31).
This is similar to the way we do it with sex or gender (P21), occupation (P106) and other aspects.
In general, if need to be a expert in a field to determine the correct P31, than it's probably not good modeling (IMHO). --- Jura 11:12, 18 January 2022 (UTC)[reply]
  •   Keep Yes the change was very poorly communicated. I understood about it after some people started complaining to me about broken queries and missing data. That said I support the new property. Adapting my broken queries to the change actually made them simpler and faster. I think that, given the universal character (and scale) of the Wikidata Knowledge Graph it makes sense to unload instance of (P31) as much as possible from specifics about a given field. Similar to human (Q5), I approve the prospect of being able to rely on something like individual organism (Q110224119) and a dedicated property instead of having to filter out which of the types I am looking for. --Nikola Tulechki (talk) 08:43, 19 January 2022 (UTC)[reply]
  •   Delete. Taxons are classes, we don't need a subproperty of instance of (P31) just for taxons. P31 should accept P171 as equivalent to its superproperty. --Yair rand (talk) 23:07, 8 February 2022 (UTC)[reply]
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Properties_for_deletion/P10241&oldid=1645913911"