Wikidata talk:WikiProject Taxonomy/Archive/2013/11

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.

Subgenus

Currently, some subgenera like Sericeocybe (Q1209991) have taxon name (P225) like "Cortinarius subgenus Sericeocybe". Also, the format constraints of P225 allow using "subgen." as part of the name. I would prefer to have P225 simply as "Sericeocybe", i.e. only the name of the subgenus itself. The taxobox can then create the appropriate format by using P225 from the parent genus. This would easily enable printing "Cortinarius subgenus Sericeocybe" (names in italics). The same rules would apply to other subdivisions of genera, e.g. Solanum sect. Pachyphylla (Q142230) ("Pachyphylla" instead of "Solanum sect. Pachyphylla"). Comments?  — Felix Reimann (talk) 18:46, 30 October 2013 (UTC)

ICZB has a strange rule that allows citing subgenera as „Genus (Subgenus) Species”... --Succu (talk) 19:21, 30 October 2013 (UTC)
I see your point, but the proposed solution makes me highly uncomfortable. Firstly, I always seem to be combatting the misconception that these parts of the name are the name (or "a name"). In this case, Cortinarius subgenus Sericeocybe is the scientific name of the taxon, while Sericeocybe by itself is nothing, and there are a lot of users who seem unaware or indifferent to this. I would be extremely reluctant to abandon taxon name (P225) for the full scientific name. This would make it much harder for new users to understand the structure here. Secondly, the proposed solution depends on the implementation of the Taxobox module, and thus is not only susceptible to errors in this module, but there is no reason why others (elsewhere) may not decide to build their own modules based on the data here. And who knows what errors they are going to make? Thirdly, the proposed solution depends on having all the other fields (taxon rank, parent taxon) filled in completely, and given how much work there is still to do, this sounds like an invitation to chaos? Fourthly, what applies to subdivisions of genera also applies to subdivisions of species, and to cultivars (and Groups and grexes and plant varieties).
        The practical thing to do would be to make a new property "final epithet" which can hold Sericeocybe. The Taxobox module can then test for the presence of this property and if this is present can start work on building from there (testing if taxon rank and parent taxon are there, etc); otherwise it can go to work with "taxon name". This looks quite workable to me, and would avoid a transitional phase, with a lot of entries in the process of being changed. - Brya (talk) 05:56, 31 October 2013 (UTC)
I think we should follow ICNafp Recommendation 5A which suggests standard abbreviations. You can then simply look if taxon name (P225) contains " subg. ", split the string and build a new one with '' to format the first and last part in italics. --Succu (talk) 14:36, 1 November 2013 (UTC)
Yes, but it should be possible to do it even more simply. The module can look at the rank, and then go into the subroutine for that rank. Something like "if rank is subgenus" and "Nomenclature Code is ICNafp" then take the last (third) word in the taxon name, put it in italics, put "subg." in front of that and put the parent taxon in italics in front of that? - Brya (talk) 17:28, 1 November 2013 (UTC)
PS: there are only two ranks for which the Code on nomenclature needs to be checked, namely subgenus and subspecies. Of course, it may help to also check it for ranks higher than genus, if it is desirable to offer the option to italicize names above the rank of genus, as in the ICNafp. - Brya (talk) 17:44, 1 November 2013 (UTC)
Today I added some subgenera of Acartia from nlwiki (e.g. Acanthacartia (Q15148509)). Same formating question for taxon name (P225) arises in these cases governed by ICZN. --Succu (talk) 19:00, 12 November 2013 (UTC)
Yes, subgenus and subspecies are the ranks where there are major differences in formatting. - Brya (talk) 12:14, 13 November 2013 (UTC)
See Tillandsia subg. Diaphoranthema (Q289418) and Putorius (Q30097). I decided for now to do it like this as both types of taxon names exist in the database.  — Felix Reimann (talk) 12:29, 13 November 2013 (UTC)
If you are OK with this, we are in agreement. - Brya (talk) 17:49, 13 November 2013 (UTC)
No, I currently implemented it not in this way. The problem is that both Codes, ICNafp and ICZN exactly disagree in this point: The first says, the name is "Tillandsia subg. Diaphoranthema", Diaphoranthema is only an epithet, not a name by itself, while ICZN states that "Putorius" is the full name of the subgenus in the genus "Mustela". Thus, we have 3 options:
  1. We create the taxobox exactly as to reflect both Codes, thus, P225 for a plant subgenus is "Tillandsia subg. Diaphoranthema" (with genus and "subg.") while P225 for an animal subgenus is "Putoris" (without parentheses and genus)
  2. We privilege ICNafp and use P225 to show the final format
  3. We privilege ICZN and add only the plain name of the subgenus/the epithet
1 would lead to an inconsistency which might be difficult to follow if you do not know both Codes by heart. Both, 2 and 3, do break the respectively other Code. From a database point of view, 3 is to prefer as it allows most flexibility: For example: as the combination "Tillandsia subg. Diaphoranthema" is created by the Taxobox itself, the formatting is always identical and we do not need to unitize "subg.", "subgen.", "subgenus". Also I found several cases where the ICNafp format is used for animals and the ICZN format is used for plants. All this could be avoided if the automate the formatting. Thus, I would prefer solution 3 or - if you are strictly against violating ICNafp in this case, solution 1 with the drawback of implementing a different use of P225 for ICNafp and ICZN. Please choose your option!  — Felix Reimann (talk) 22:03, 13 November 2013 (UTC)
The way I see it we probably agree on three points:
  1. The finalized taxobox should show a Code-compliant format (for the Code that applies to that taxon).
  2. No matter what we do some of the users will not quite understand it and will fill in some of the fields wrong.
  3. It will take a fairly complex piece of software to achieve the first of these points (a Code-compliant format).
About the second of these points, what we can do is make it as simple as possible for users to get it right, and we will do that by following the Code-that-applies-to-that-taxon. Users may come here from all over the world, from all kinds of backgrounds, speaking all kinds of languages, so we should keep things as unambiguous as possible. The taxon name is what the relevant Code says it is, and we will have the least confusion if we will just follow that. This does not require the users to "know both Codes by heart", but just requires them to be able to copy-and-paste accurately from the existing literature.
        The software needed to create a taxobox will not be simple no matter what we do, so, as I see it, we may just as well have the software solve the problems. This can be done by having the software read the taxon rank (P105) and the code of nomenclature (P944), and then go to the proper subroutine for that particular case. This is much safer than relying on having all fields filled in to a uniform standard (users will probably use "subg.", "subgen.", and "subgenus"). Also, for formatting purposes it will be necessary to read P944 anyway. - Brya (talk) 06:38, 14 November 2013 (UTC)
In short: You vote for option 1. :) More opinions?  — Felix Reimann (talk) 20:22, 15 November 2013 (UTC)
We are not at the voting stage (yet), but yes, I think taxon name (P225) should have the name of the taxon, not something else. - Brya (talk) 05:43, 16 November 2013 (UTC)
If you could implement option 1, this would be great. --Succu (talk) 08:17, 16 November 2013 (UTC)
I don't have much free time currently, therefore the slow progress. subg. is now printed according to ICNafp.  — Felix Reimann (talk) 08:23, 19 November 2013 (UTC)

Hybrid parents - How to add them?

Aloe barberae × vaombe ‘Goliath’ (Q15078286)} is an artifical hybrid between Aloe barberae (Q149345) and Aloe vaombe (Q148533). One possibility is: has part(s) (P527) = Aloe barberae (Q149345), Aloe vaombe (Q148533). But I dont like this. Any suggestions? --Succu (talk) 15:21, 5 November 2013 (UTC)

This is somewhat mysterious. There is a Portugese wikipedia entry which lists five www-references and none of these holds this plant. Talking about careless! Best guess is that this is Aloe barberae × Aloe vaombe ‘Goliath’, that is a cross between Aloe barberae and Aloe vaombe ‘Goliath’, and thus is not itself a cultivar. This can be handled by putting the hybrid formula (Aloe barberae × Aloe vaombe ‘Goliath’) in "taxon name", with (likely) Aloe as the parent taxon. - Brya (talk) 17:31, 5 November 2013 (UTC)
This was only an example. The source of the pt-article is this web article. Aloe ‘Goliath’ (and a lot of other aloe cultivars) was created by the Australian hybridizer David Cumming. I think it is uncommon to use the full hybrid formula in taxon name (P225). --Succu (talk) 18:49, 5 November 2013 (UTC)
That source is singularly uninformative. But, if, as you say, Aloe ‘Goliath’ is a hybrid (or derived from a hybrid) between Aloe barberae and Aloe vaombe, then the current "taxon name" is wrong, and should be Aloe ‘Goliath’. By the way, I don't think it is wrong or undesirable to use a hybrid formula in "taxon name", as these are often very clear (see Rec. H.10B), but this does not apply here, as there is a real taxon name.
        That leaves the question of what to do with the parent taxa. I suppose the safest thing would be to create a new property for these, as otherwise there is a risk of confusing Wikidata's "parent taxon" with the hybrid's parent taxa? - Brya (talk) 06:31, 6 November 2013 (UTC)

Problems with different combinations (Genus + species)

My problem with Magnolia floriibunda/Michelia floribunda from the #Authority discussion would not be solved by the Basionym property. cs:Rmen rakouský cannot be seen from de:Österreichische Hundskamille and vice versa, just because the two wikipedias follow different taxonomic opinions concerning the genus assignment – the specific epithet (i.e. the species) is the same, yet the Wikipedia links are split up into two Wikidata items. -- Olaf Studt (talk) 11:22, 16 November 2013 (UTC)

Yes, this is more or less an unsolvable issue. From the data-perspective it makes sense to have two separate items, but for the interwiki's it is handier to have all the iw's in one item. This is not a black and white issue (it is also possible for two pages with the same name to refer to quite different taxa). What helps anyway is to use the "Also known as" fields, but when there are just a few iw's on a Wikipedia page, I would tend to put them in the other item. But again, there is no perfect solution. - Brya (talk) 14:06, 16 November 2013 (UTC)
Hi Olaf, you find a somewhat lengthly answer at my german discussion page. --Succu (talk) 23:11, 16 November 2013 (UTC)

duplicate penguins ?

Are Sphenisciformes (Q15041954) and https://www.wikidata.org/w/index.php?title=Q9147&curid=10503&diff=87310241&oldid=86132092 duplicates ? TomT0m (talk) 19:29, 17 November 2013 (UTC)

No, Sphenisciformes (Q15041954) is an order, the other a family. - Brya (talk) 05:17, 18 November 2013 (UTC)

Bot generated taxons

Wikidata:Project chat#Bot generated taxons might be of interest to you. Multichill (talk) 17:46, 21 November 2013 (UTC)

main food source (P1034)

I tried around with main food source (P1034). Does this (https://www.wikidata.org/w/index.php?title=Q156954&diff=89318367&oldid=87529960) look good? The level of detail won't be as precise in all parts of the tree, but it will enable us to construct food chains. --Tobias1984 (talk) 09:10, 25 November 2013 (UTC)

If you understand the cited source right, the single correct value should be main food source (P1034)=Solanaceae (Q134172), or? According to Help:Sources, you should also add title, author, and publication date of the source.  — Felix Reimann (talk) 09:58, 25 November 2013 (UTC)
Sounds good. I made the changes. I hope the queries will be versatile enough to answer somebody who is asking Wikidata "Who is eating my potatoes?". --Tobias1984 (talk) 10:33, 25 November 2013 (UTC)

List of properties

Can I replace the list of properties with a transclusion of Talk:Q16521/class. Having the list of properties in a single separate page should make it easier to update and to re-use. --Zolo (talk) 08:54, 24 November 2013 (UTC)

I don't see that this would offer any advantage. - Brya (talk) 12:25, 24 November 2013 (UTC)
Always nice to get friendly and constructive comments... Keeping strandardized lists of useful properties for a specific type of item has potentially lots of uses. The most immediate is to create easy to easy to read documentation. There has been quiet a few requestq for simple guidelines on what properties we should use. If we keep separate lists, it is much simpler to create the doc than if it is buried in a task force Wikitext. More speculative use would be feeding machines with them so that can can get error reports, tools for suggesting properties etc. --Zolo (talk) 14:21, 24 November 2013 (UTC)
I still don't see that this would offer any advantage. It would be a good idea to have "easy to read documentation" but this probably would not be all that hard to write and the proposed template would not make this easier to write (probably harder). - Brya (talk) 16:45, 24 November 2013 (UTC)
Well, this is a wider problem than just this project documenation pages, we still don't manage correctly the list of properties, cf. Wikidata talk:List of properties last topic. Zolo's templates are a good proposition to manage in a more organised way those list. A (just a little) more difficult writing for these (and this still needs to be demonstrated, there is pages templates creation mechanisms in Mediawiki which make possible to take the user by the hand to make somethinh good and prewritten easily used for a decade) is a small price to pay. TomT0m (talk) 17:57, 24 November 2013 (UTC)
As TomTOm told, this feature could be useful to manage properties non only for task forces, but also for manage the whole list of properties (with the technical prescription noted by TomTOm. --Paperoastro (talk) 21:23, 24 November 2013 (UTC)
It seems to me that we should build out a set of help pages, instead of scattering the class information to the high winds on talk pages. Example: Help:Taxonomy items would have that information and more besides. If you really want to have transclusion, I would even consider having an actual template, like at Template:Taxon properties table (side note: see what Ivan A. Krestinin has been doing with Template:Authority control properties and a few others besides). --Izno (talk) 22:34, 24 November 2013 (UTC)
I would say that the most important point is that we have a way to easily identify all pages that consist in a class description. I have no strong opinoin on the namespace we should use but the nice thing with using item talk pages is that we can directly identify the item to which it relates and that it is not "hard-tied" to a particular task force. All class-documentation pages are categorized in Category:Class documentation so they are easy to find. Of course, that does not prevent from grouping/linking/transcluding them in nice templates. --Zolo (talk) 08:52, 25 November 2013 (UTC)
I don't think it's a good idea to replace our list of properties with a less accurate transclusion of Talk:Q16521/class. Sure: all these properies belong to our domain. But I think to model this domain with a single class taxon (Q16521) is erroneous. --Succu (talk) 16:13, 25 November 2013 (UTC)
I am not sure of what you mean. As far as I understand, the current list of properties is supposed to be a list of properties that can be/should used with instances taxon (Q16521), and that is what talk:16521/class is trying to do. If the task force page also provides guidelines for items that are not instances of taxon (or guidelines for just some subclasses of taxon), they should be clearly separated from the general list of properties for taxa, so that we know to what sort of item the property applies. talk:16521/class is supposed to be simply a copy of the properties provided in Wikidata:Taxonomy task force. If there are mismatches, that's my mistake and they can be corrected. I do not see how the proposed system would make things less accurate.
I think you understand it wrongly. - Brya (talk) 18:28, 25 November 2013 (UTC)
Brya, it would be great if you could make comments a bit more explicit than "that's bad/wrong". --Zolo (talk) 18:49, 25 November 2013 (UTC)
There is a clear difference between recommandation (should have) and requirement (must have). --Succu (talk) 18:36, 25 November 2013 (UTC)
Yes, I have simply written "required" for properties that were documented as "should have" on Wikidata:Taxonomy task force and as "not required" for properties that were documented as optional. I agree that the wording will need to be refined. --Zolo (talk) 18:49, 25 November 2013 (UTC)
We have a lot details awaiting refinement in our domain. But first of all (my opinion) we have to pin down all (unknown) items whitch might be taxa. --Succu (talk) 19:14, 25 November 2013 (UTC)

Marking non taxon items

There are a lot of items, which hold a taxobox in a Wikipedia chapter but for an item of another article. Some examples:

I propose to have in these cases always only one single item in Wikidata which has the corresponding P225 set (i.e., constraint violations in this case are correct and should be fixed). The other item should be marked as not representing a taxon by setting P225='no value' (Wikidata's means of defining infeasibility). If possible, it could get a corresponding value for instance of (P31) (for example, fruit (Q3314483) or fruit (Q1364)). This, bots must respect and not add taxon-specific properties.  — Felix Reimann (talk) 15:03, 25 November 2013 (UTC)

I support this proposal. Some weeks ago I compiled an overview witch items are used for instance of (P31) to fix some errors. Maybe I can updated this list tomorrow and publish it here. --Succu (talk) 15:51, 25 November 2013 (UTC)
I still don't understand. The problem is now defined differently (and contrary to before?). The issue now addressed is of Wikipedia pages that erroneously have a taxobox? This indeed happens more often than one would think.
        I am not at all sure I see that this is any sort of solution, and certainly it is counterintuitive. To indicate that something is not a taxon you use "taxon name", while a taxon name can only exist if there is a taxon (but it is not a taxon). This is a way to indicate that a Wikipedia page is wrong, and for that you make the Wikidata page wrong in a different way. Hoping that two wrongs make a right? Surely it should be possible to have a simpler and easier to explain solution than this? - Brya (talk) 18:46, 25 November 2013 (UTC)
How about something like "instance of non-taxon" or "instance of not-a-taxon"? - Brya (talk) 19:22, 25 November 2013 (UTC)
Are you kidding us? Rocks are a "instance of non-taxon"... --Succu (talk) 19:32, 25 November 2013 (UTC)
Actually, that was part of my objection against "P225='no value'"; why not include that for rocks or whatever (anything that does not have a taxon name). The heading is "Marking non taxon items", so the question is how to mark items that are not taxa, but that are falsely indicated on some Wikipedia as a taxon and "instance of not-a-taxon" will do just that. OK, it looks a little weird, but anybody encountering this will go look it up, and then find the explanation. This as opposed to "P225='no value'" which looks a lot weird and really looks like an an inadvertent error, something to be corrected.
        But if you don't like it, perhaps "instance of falsely-presented-as-a-taxon", or something? - Brya (talk) 19:48, 25 November 2013 (UTC)
Brya, think twice. Empire State Building (Q9188) is a... Succu (talk) 20:15, 25 November 2013 (UTC)
Well, "Empire State Building (Q9188) is a case of "P225='no value'" and "Empire State Building (Q9188) is an instance of not-a-taxon" are both silly and nobody has proposed either. - Brya (talk) 05:41, 26 November 2013 (UTC)
I do not propose to add P225:'no value' to each and every non-taxon item. However, there are items which have Wikipedia pages which have taxoboxes and or ITIS links and so on. We have to possibilities: Whenever a bot again finds such articles, the bot add again P225:Salmo trutta. You or me fix the constraint violation popping up 1 day later, and everything starts again. Forever. Noone in this loop makes something wrong: There are many cases where it makes sense that more than one Wikipedia article have a taxobox about the same taxon, the bot does not do something wrong as it correctly finds P225 missing, and you do nothing wrong with removing the constraint violation. Have fun now. OR: Possiblity 2: We mark this special "nearly a taxon, but we have another item which models the taxon"-item as: NO, this is not a taxon, and now can tell all bot users that we do not want all the properties we have here added if the item is marked as not having a taxon name as these properties are only for taxa.  — Felix Reimann (talk) 23:03, 25 November 2013 (UTC)
Yes, I understood that it was not the intent to add P225:'no value' everywhere, just as I did not propose to add "instance of not-a-taxon" everywhere. The intent is to put it only where there is a reason to expect that a bot or a user might put in "instance of a taxon" and all that comes with it, especially where some Wikipedia has a taxobox where it does not belong.
        My problems are several:
  • using P225:'no value' is quite counter-intuitive, it uses "taxon name" to indicate that there is no "taxon name", which is a contradiction in terms.
  • It is unexplained and whoever comes here to work on an item has no opportunity to find out what it means.
  • It is not a logical part of the item; from the data perspective there is no reason for its inclusion: it is there because of what is elsewhere (in some Wikipedia).
        These problems would be a lot less with "instance of not-a-taxon". There already is "instance of taxon", so that this creates a nice symmetry. Secondly we can have an item "not-a-taxon" with a description and a Talk page which explains this to the user, and which can be reached from wherever "instance of not-a-taxon" is used. Of course bot users have to be told about it, but that does not look insurmountable to me. - Brya (talk) 05:41, 26 November 2013 (UTC)
I agree that the most natural place for this sort of things is instance of (P31), but we do not need "instance of non-taxon". If scientific name only makes sense for taxa, then nothing that is not an instance of taxon should have this property. That is at least as intuitive than saying "something that is an instance of non-taxon should not have a scientific name. The Wikidataquery tool can do the list of items that do not respect the rule in less than a minute, taking into account items that are instances of subclasses of taxon. Of course, that requires adding "instance of taxon" on all relevant items first, but this is needed in any case. Yes, it is related to my above proposal and to user:TomT0m's suggestion that we should think at the class level rather than the property level. --Zolo (talk) 07:56, 26 November 2013 (UTC)
@Zolo I do not argument against P31. However: Are your sure that your proposal helps? If a bot imports P31=taxon for an item, which is not a taxon but something else, then I remove this claim. If the bot runs again (e.g., importing claims from another Wikipedia), it will again add P31=taxon - again requiring manual repair (in several thousand cases) -> :-( -> ideas? As I understood, the "novalue" snaktype means exactly: "must not be set" which fits quite good to our usecase, or?
@Brya Yes, your proposal "P31:not-a-taxon" would work. But in my feeling (-> yes, this means no arguments), I like it even less than P225=novalue. :(  — Felix Reimann (talk) 11:43, 26 November 2013 (UTC)
Please see meta:Wikidata/Data_model#PropertyNoValueSnak  — Felix Reimann (talk) 11:45, 26 November 2013 (UTC)
We are searching here for the least-offensive solution. And P225:'no value' may have the advantage that it is built into the software of Wikidata, but it has the disadvantage that it looks terrible and it is non-linkable so the reader is left entirely in the dark. Is there a third solution, like a new property? - Brya (talk) 12:00, 26 November 2013 (UTC)
@FelixReimann. It works if instead of removing the p31 = taxon, you replace it with something else. This way, bot should not add "instance of taxon". Or if a badly behaved bot does it, at least there will be another value for p31, so we can detect inconsistencies. --Zolo (talk) 12:24, 26 November 2013 (UTC)
Nelumbo nucifera (Q16528) is a taxon and (arguable) instanceof=vegetable (Q11004). May the bot add P31=taxon and taxon properties (P225, P171, P105, ...) or not? In this case: Yes, for the apple above: no. There are currently 361 more cases, where taxa are ordered in other classes.  — Felix Reimann (talk) 13:01, 26 November 2013 (UTC)
@Brya Perhaps a property similar to category's main topic (P301)? Is it correct to add apple (Q89) part of Malus pumila (Q158657)? Of course, having "part of" set is also not a clear statement that something is not a taxon, e.g., mountain anoa (Q769957).  — Felix Reimann (talk) 13:28, 26 November 2013 (UTC)
There are indeed cases where that may be tricky. I would guess that rice or apple cannot be taxa because seeds and fruits alone cannot be taxa. For many items that are subclasses of organisms, it seems that folk taxonomy (Q10751930) can be used ? For items like "apple" and "rice" they are subclasses of fruits and seeds, and as such, not subclasses but part of (P361) of organisms ? So could that work to say: an item can be a taxon only if it is a subclass or organism and not an instance folk taxonomy (Q10751930) ? It seems that it covers most items at risk. --Zolo (talk) 13:54, 26 November 2013 (UTC)
Taxa can have both taxon name (P225) and common name (Q502895) (I think thats better than using folk taxonomy (Q10751930)). --Succu (talk) 14:14, 26 November 2013 (UTC)
Yes, common name (Q502895) is to prefer. I checked several cases - Zolo's proposal could work. Try it at the "novalues" from Wikidata:Database_reports/Constraint_violations/P225#.22Format.22_violations. The only problem is that you have to always find a correct value for P31 while fixing P225 constraint violations: To which class does Kombu (Q11261547) belong? Sometimes this is not easy to answer...  — Felix Reimann (talk) 14:21, 26 November 2013 (UTC)
@Succu: If an item is instanceof taxon, then it must have a scientific name and has probably a vernacular name as well as it has all the other taxon properties. If, however, an item is instanceof vernacular name, it must not have a scientific name. I think we can explain this to the users. What do you think?  — Felix Reimann (talk) 14:26, 26 November 2013 (UTC)
An alternative solution may be: an instance can be neither an instance of folk taxonomy (Q10751930), nor part of (P361) of an instance of taxon nor part of (P361) of an instance of folk taxonomy (Q10751930). That would also avoid lengthy (and potentially faulty) recursions. --Zolo (talk) 14:29, 26 November 2013 (UTC)
Referring to "Folk taxonomy" here confuses me; I don't see how that is involved here, and I cannot imagine how it could make for a simple solution. In the case of kombu, I would put in "instance of vegetable" and "instance of Laminariaceae" (or whatever taxonomic situation applies). I would not use "part of". - Brya (talk) 17:29, 26 November 2013 (UTC)
Folk taxonomy=Nom vernaculaire (French). I used folk taxonomy (Q10751930) accidentally and meant common name (Q502895). Just replace all occurences here with Q502895.  — Felix Reimann (talk) 17:40, 26 November 2013 (UTC)
Well in my book, folk taxonomy and common names are quite different things. Common names can be quite regulated and scientific. Vernacular names are something else. A taxon can easily have an approved scientific name, an approved common name and a few dozen vernacular names. - Brya (talk) 17:47, 26 November 2013 (UTC)
Hmpf - then choose a name you like. I dont care. For me these are more or less homonyms, enough to distinct taxa I care off from other things. Whatever.  — Felix Reimann (talk) 18:42, 26 November 2013 (UTC)
Well, the discussion was confusing to start with, and it seems to be getting more confusing as it goes on ... - Brya (talk) 18:51, 26 November 2013 (UTC)
Sure, a group of organisms cannot be an instance of folk taxonomy, as it isn't a taxonomy. What I mean is that folk taxonomy (Q10751930) was apparently used in some items to mean "group of organisms grouped togther by common language but not by science". If we can have an item for that, then kombu seems to fit there. --Zolo (talk) 19:43, 26 November 2013 (UTC)
Oh, sure, but not rice, or apples. - Brya (talk) 19:52, 26 November 2013 (UTC)
They are something like fruits of (& co) with P256 (P256) <fruits> and so on. TomT0m (talk) 19:57, 26 November 2013 (UTC)
Brya, I have already said that rice and apples are not fruits because they are part of an instance of taxon.... --Zolo (talk) 20:43, 26 November 2013 (UTC)
? Apples are fruit and so (more or less) is rice. - Brya (talk) 05:38, 27 November 2013 (UTC)
Yes, apple is part of malus and rice is part of oriza sativa (or whatever) just like human leg is part of human, see Help:Basic membership properties. We may want to use more specific properties but the idea would be the same. --Zolo (talk) 08:05, 27 November 2013 (UTC)
For apple (Q89), the fruit of the apple tree, I added instance of (P31): pome (Q41274) (a type of fruits, subclass of follicetum (Q145167)). To link the fruit to the taxon, I used part of (P361) Malus pumila (Q158657), as suggested by Zolo. I think this makes sense. Of course, we do not suggest to put instance of (P31): common name (Q502895) to fruits. However, many constraint violations are of a type where adding this might work.  — Felix Reimann (talk) 08:13, 27 November 2013 (UTC)

Again

  1. We could have a property like "produced by / yielded by / a product of", and this would help for a lot of cases, probably most of them. But not all of them.
  2. We could also use both "P225 novalue" and "instance of not-a-taxon". This would look terrible, but at least it covers the claims that a bot might want to fill up, and it would allow a clickable "instance of not-a-taxon" with an explanation of this weird structure. As it concerns probably only a few hundred items this may be tolerable. - Brya (talk) 05:38, 27 November 2013 (UTC)
Regarding 1.: The only similar property I found is manufacturer (P176). We can (a) ask there if we may broaden its application, (b) we use part of (P361), or (3) propose a new property.
I would vote against (c).  — Felix Reimann (talk) 08:13, 27 November 2013 (UTC)
Regarding 2.: We collected 3 possibilities for cases where we want to say that this item is not a taxon:
  1. Use P31:not-a-taxon
  2. Use P225:novalue
  3. As Zolo suggested, we could set P31 to whatever fits (for example: fruit, vernacular/trivial name, ...). Bots then must not add taxon properties to any item which has instance of (P31) set to anything except taxon (Q16521) or monotypic taxon (Q310890).
I vote for (3).  — Felix Reimann (talk) 08:13, 27 November 2013 (UTC)
OK. (3) is what I have been doing all along and it was what you objected to. But I am still fine with it. - Brya (talk) 11:33, 27 November 2013 (UTC)
 Comment, if we do it this way, we need to add "instance of taxon" to a massive amount of item. Is it ok to make a request for adding it to everything that currently uses taxon name (P225) now and check for errors afterwards ? --Zolo (talk) 13:38, 27 November 2013 (UTC)
This was discussed multiple times: The latest discussion you will find there. --Succu (talk) 15:42, 27 November 2013 (UTC)
The problem only exists for items that do not have and should not have taxon name (P225). Doing something with/to items that do have taxon name (P225) makes no difference. - Brya (talk) 17:23, 27 November 2013 (UTC)
The proposal is to prevent bots from editing items that are not marked as "instance of taxon", so obviously it makes a difference... I don't understand the objection to a bot adding "instance of taxon". Is the data quality so low that there are tons of items that have a taxon name (P225) but are not taxa ? If not, I really don't see how adding "instance of taxon" can deteriorate Wikidata's quality. Apparently, one concern is that we should not add "taxon" when "monophyletic taxon" could be used., but if a taxon is not monophyletic, it should be marked as "instance of paraphyletic taxon" or something like that, otherwise the problem can never be fully solved.--Zolo (talk) 17:45, 27 November 2013 (UTC)
Think it through (maybe use a piece of paper to write it out?) - Brya (talk) 18:43, 27 November 2013 (UTC)
 Comment Another approach maybe : use the disjoint with (create it maybe) constraint to state that instances of a class are not instances of the other one. We might have a class organisms parts which is disjoint with taxons or something like that (this would imply that a subclass of both cannot be instanciated, so is not consistent). TomT0m (talk) 15:05, 27 November 2013 (UTC)

IW conflict?

Cellularia (Q10444691) seems to be an IW conflict.

As an aside, only la.wp has it as the parent taxon of Demospongiae (Q248530), and I couldn't find evidence that it's the parent taxon just skimming the en.wp article.

Can someone poke at this, for what is probably an easy problem to solve? :) --Izno (talk) 15:13, 27 November 2013 (UTC)

Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata_talk:WikiProject_Taxonomy/Archive/2013/11&oldid=104244344"