Wikidata talk:WikiProject Taxonomy/Archive/2018/10

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

Location survey

How should we add information about the presence of specific taxons found at some place? These may be present there indigenously, imported, or just omnipresent as at most other places.

Imagine someone writes a study describing taxa ABCDEF as present in place Z. Or someone else tries to do an inventory plants of place Y, etc. Ideally we should be able to add to Wikidata that "taxon A is present in Z" referencing the study.

If we just add a (new) "taxa found"-property to a location, this can work if there are just a dozen or even hundred, but might get out of hand if these gets into the thousands. For these, it may be worth doing a "biology of Y" .. item and add statements there.

How should we structure this? How could we label the property? --- Jura 13:06, 8 October 2018 (UTC)

The risk of this getting out of hand is very real. There exists a humongous amount of data out there (I don't know how much of it is rights free): for some taxa it may well run into the thousands of data points, of not tens of thousands, or more. - Brya (talk) 16:45, 8 October 2018 (UTC)

Yes, which is why I'd try an approach with separate items. They could look like the ones we get for pubmed items: somewhat bulky, but easy to query. I'd thought of an approach per location, but it might work per taxon too. However, in the later case, one might just end up with a bunch of coordinates. --- Jura 17:18, 8 October 2018 (UTC)

An approach per location may work better, but numbers will get pretty high very easily. For example, there are between forty and fifty thousand species of fungi that have been found in the Netherlands. - Brya (talk) 17:46, 8 October 2018 (UTC)

I hope locations would be more specific than just the country. --- Jura 09:55, 9 October 2018 (UTC)

Please note my comment at Wikidata:Property_proposal/iNaturalist_observation_ID. --Succu (talk) 17:56, 9 October 2018 (UTC)

Thanks. Peculiar property .. Looks like the property creator used it in correctly. Anyways, this and the site you mention there work slightly differently. Although the later does include literature or sampling events as sources. Maybe we should include a limit of the number of locations or species we want per source. --- Jura 20:06, 9 October 2018 (UTC)

What we really need is a property to model the geographic limits of a particular taxon's distribution (range). There were some discussions in the past about that, but without a solution. --Succu (talk) 20:20, 9 October 2018 (UTC)

taxonomy wars

I noticed a taxonomy problem, some warring about the name a species has. I have been combing through the works of Joseph Dalton Hooker in the Antarctica, so I have been tending to defer to New Zealand for my questions about the species.

Q5175878 Cotula plumosa. Missouri calls it Cotula plumosa. All of the wikipedia and all of the references cited call it Leptinella plumosa.

I made Q56879705 for all of the references that call it Leptinella plumosa and added the one reference for Cotula plumosa there. http://www.tropicos.org/Name/2717384 Called them both synonyms of each other and to the best of my understanding, kept wikidata out of any taxonomy war.

How can I prevent Leptinella plumosa from being (perhaps wrongly) merged with Cotula plumosa? --RaboKarbakian (talk) 20:40, 7 October 2018 (UTC)

@RaboKarbakian: WARs? I created Cotula plumosa (Q57051873). I'm not entirely sure how this is related to Leptinella plumosa (Q5175878). --Succu (talk) 21:17, 7 October 2018 (UTC)

I am not sure how the taxonomist determine their classification; I leave that to them. The way the leaf attaches to the stalk, the shape of the petal -- I enjoy following the naming, throughout history, and currently as well. When I was writing articles for a pedia, and categorizing images at commons, it became apparent pretty early on that there were several versions of "the" Tree of Life. Not being an expert in plant anatomy has this one advantage, in that, I don't really care.

Leptinella plumosa most certainly has its own history separate from Cotula plumosa. Cited by other scientific journals both historically and currently. Cotula plumosa brings its history with it. I understand the need for one name only (perhaps with a redirect from the other name) on the wikipedia's and even on the commons, where having all images of the plant in one location is the most useful thing.

But here, it is different. That need does not exist and it can be managed impartially. But not if they automatically are merged, perhaps a legacy behavior from the 'pedias, perhaps not.--RaboKarbakian (talk) 21:36, 7 October 2018 (UTC)

Your basic instinct seems alright. There are a lot of different Trees-of-Life. There are a lot of different taxonomic viewpoints. Wikidata can (mostly) have items only about names.

• It is correct to make an item Cotula plumosa, and Succu made it at Q57051873. Put all references on Cotula plumosa in that item.
• It is correct to have an item Leptinella plumosa, and it exists at Q5175878. Put all references on Leptinella plumosa in that item.

Then add "taxon synonym" statements in where appropriate, preferably referenced. Also "instance of : synonym" with a qualifier "of : ..." (also preferably referenced). These items should not be merged. - Brya (talk) 05:25, 8 October 2018 (UTC)

Thanks for this. It all made sense to me and that little goal, where I wanted to link my plant articles to the lists of references at a wikimedia project are that much closer to "being".

The taxonomy people might take a look at the book peoples work before making assumptive changes to books that contain taxonomy articles. Wikidata:WikiProject Books A book is quite a bit like a genus or tribe, even....--RaboKarbakian (talk) 16:48, 9 October 2018 (UTC)

OK, that's good. I see you have changed "subject has role" from "basionym" to "synonym". That is not right. A basionym represents a nomenclatural relationship, and no matter what happens the basionym of a name does not change. A synonym represents a taxonomic relationship, and it depends on a taxonomic viewpoint. It is pretty much subject to change without notice. Something is either an "instance of: taxon" or "instance of: synonym"; mutually exclusive.

        I will see if I can find time to look at Wikidata:WikiProject Books, although I tend to be shy about the topic. It seems that styles of referring to books are continuously changing, and it seems not worthwhile trying to catch up. - Brya (talk) 17:20, 9 October 2018 (UTC)

I was following what the bot operator did. The fine detail between the variety of synonym is something that I can leave for those who understand it. I was actually happy to leave the synonym pointers at each other, as I did before what I did was merged.

Let me know when you have a book version that needs to be datafied here. It is cranky.--RaboKarbakian (talk) 18:16, 9 October 2018 (UTC)

The bot operator is fully aware of what he does. BTW: I added references to Cotula plumosa (Q57051873) and Leptinella plumosa (Q5175878). --Succu (talk) 19:29, 9 October 2018 (UTC)

Flora Antarctica (Q6435950)

Is it wrong minded of me that I expect that wrong changes made to a publication here be reverted by the expert that made them?--RaboKarbakian (talk) 18:26, 9 October 2018 (UTC)

This is not right as it is. It confuses the whole work with the first part of the work. There are three volumes, each in two parts. - Brya (talk) 11:00, 10 October 2018 (UTC)

Scientific illustrations

I have started a dialog with the Visual arts project for how to handle scientific illustrations. Wikidata:WikiProject_Visual_arts/Questions#Scientific_illustrations. If you are interested and/or understand the needs, feel free to drop in.--RaboKarbakian (talk) 22:05, 10 October 2018 (UTC)

TaxonWorks

Maybe TaxonWorks: A Use Case in Documenting Complex Biological Relationships it's worth a closer look how things are done elsewhere. --Succu (talk) 19:00, 12 October 2018 (UTC)

Taxonomy: concept centric vs name centric

Hello. A discussion with the above title is taking place at the general Wikidata chat page, but @Brya: has said that it should be here. There have been various previous attempts at discussing this question, without much progress, but I think it is tremendously important. Can I copy it here? Strobilomyces (talk) 15:27, 15 October 2018 (UTC)

No; copying it here would fork the discussion. Leave it where it is, so that the wider community can be involved. A pointer to it, from here, is sufficient. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:34, 15 October 2018 (UTC)

A discussion about an issue concerning this project on the wikidata mailing list

Hi, in a thread about the use of wikidata datas for commons metadata and information research, the case of the use of datas about life on Wikidata : https://lists.wikimedia.org/pipermail/wikidata/2018-October/012564.html . In short, the relevance of using a class hierarchy (built with « subclass of ») as a base for information search is discussed, and what it means / how to deal with the fact that this project is name centric and not classes centric. Afer all, tagging animals or plants and so on is an important usecase of Commons. author  TomT0m / talk page 11:33, 19 October 2018 (UTC)

Doesn't parent taxon (P171) give sufficient possibilities to be treated "subclass" like? Or is the problem how to fit in some "classes" defined by venacular names? Lymantria (talk) 12:09, 19 October 2018 (UTC)

There is a mix of problems, some conceptual some practical. Conceptually, as Markus note, if this project is concerned with how things are named it might be a good candidate for the lexicographical part of Wikidata. If it’s concerned with things themselves (organism classification), « subclass of » fits, and it’s enough not to tag « vernacular taxon » as « instance of : taxon » to easily ignore them. As the rest of Wikidata has been organized around it would be simpler to use it as a backbone and not to be forced to hardcode special case for « parent taxon », for the data reuser like commons. There is room for « in between » solutions, like « facetting » but historically it’s been hard to set up for different reason : ignoring the name information when you’re interested in organism classification, for example and ignoring classification informations when you’re interested in scientific names and their history, but it’s a bit unsatisfactory as there might be both « subclass of » and « parent taxon » mostly redundant. Using « subproperty of », but it’s technically not so easy : for example in sparql a way to find all instances of some class, for example assuming we have a « mammal » class, which have subclasses, is to use a so called « property path » : « ?animal P31/P279* mammal » (which search for all items which has an « instance of » statement to another item, that item itself being either « mammal » or an item which is a subclass of mammal or a subclass of a subclass of mammal or « a subclass of a subclass … of mammal and so on, and the exact same construction if you want to find all instances of ships if you have a « ship » class that is subclassed : « ?ship P31/P279* ship ». Nice and clean. However if subclass of (P279) has subproperties however it become messier as it’s not possible to use a property path anymore, unless you assume you know all the subproperties in advance : it’s not possible to substitute the P279 in « P31/P279* » to something that says « any subproperty of P279 ». It’s however possible to write « instance of or parent taxon » : « ?ship P31/(P279|P171)* ship » would work, but if another project comes with its own property we have to modifies all the queries for them to work in all cases as far as subclassing is involved. (I have at least one other reason to be against, it’s standard in ontology to have only one property for subclassing, but i’ll just tease it). This means the technical implications of having such an edgecase like this are not null, and we should think twice on why we would want to have it. author  TomT0m / talk page 13:18, 19 October 2018 (UTC)

I think I'm getting quite confused when the conceptual problem is mentioned. To me it seems as if the problem suggests taxonomy and taxon items would deal with names, rather than with classification of organisms. Talking about the lexicographical part of Wikidata in connection with taxonomy sounds offensive in my ears. So I will probably misunderstand the problem at hand. Of course naming is part of "taxonomy", and the naming is regulated. But it also depends on authors who may disagree upon each other. While insights evolve quickly. Taxa may be considered synonym by authors, and not by others. This is where I see many users experience conceptual problems: taxon synonymy is not the same as linguistic synonymy.

For the practical part: I wonder if it would be helpful to duplicate statements P171 and P279 in all taxon items. IMHO it destroys the idea of subproperties. The idea of the ordering of the set of organisms would be lost if P171 was replaced by P279, where not the next higher rank (P3730) would be required. It is to be noted that the P171-ladder is used in quite some projects to create the Template:Automatic taxobox (Q6705326). It would be quite some practical problem if that ordering by P171 was lost.

Perhaps others have som input. Lymantria (talk) 14:58, 19 October 2018 (UTC)

« Talking about the lexicographical part of Wikidata in connection with taxonomy sounds offensive in my ears. » I wonder why ??

« But it also depends on authors who may disagree upon each other. » Yep, but this is in no way different than different point of views in other fields.

There is no problem in keeping the rank whatsoever, for example taxon name (P225) also has a constraint that an item with this statement should have a taxon rank (P105) property. (It’s also possible to do with a {{Complex constraint}}. It thought it could be doable with another constraint that an item with instance of (P31) taxon or one of its subclass should have this property, but I failed to see such examples) @Lucas Werkmeister: can you confirm it’s impossible to do this, create an « other property » constraint on a property only in a statement with a specific value (here a class or its subclass) value ?author  TomT0m / talk page 13:12, 20 October 2018 (UTC)

1. „it’s standard in ontology to have only one property for subclassing“: No. In Semantic Web for the Working Ontologist you find lots of usage examples of this.
2. As I earlier mentioned: Only a taxon authority can model as their (preferred) monohierarchical taxonomy with this restriction. WD can not.

--Succu (talk) 18:41, 19 October 2018 (UTC)

1) I’m surprised at first glance, I found a copy of a newer edition and it seems that RDF and OWL are used, that typically use « rdf:type » relation to model class hierarchies and inference to infer such relation without explicitly stating the relation beetween the class entities. Can you point me to some examples in the book you’re thinking of ?

Only a taxon authority can model as their (preferred) monohierarchical taxonomy with this restriction. WD can not. I truly don’t understand what you mean, sorry. author  TomT0m / talk page 12:57, 20 October 2018 (UTC)

It seems to be the key insight from this field for IT people and others making slides about Wikidata. Maybe this WikiProject could come up with 2 simple alternative ways of reading the data: one for these IT people, another one for people looking for a list of birds. --- Jura 13:05, 20 October 2018 (UTC)

I’m pretty sure all parts can come to an agreement with a little of mutual understanding, but the key issue here as far as I’m concerned is that I don’t undersand to which « restriction » Succu refers nor, under reasonable hypothesis, how this could be a stopper to do things a little bit differently. author  TomT0m / talk page 13:21, 20 October 2018 (UTC)

As far as I'm aware a monohierarchical classification (a single subclass statement) is a design principle of good ontologies. An example is the NCBITaxon ontology. The fun fact hereby is NCBI is not an taxon authority itself. („Disclaimer: The NCBI taxonomy database is not an authoritative source for nomenclature or classification - please consult the relevant scientific literature for the most reliable information.)“ In the case of birds we have several taxon authorities e.g. International Ornithologists' Union (Q1325616), BirdLife International (Q210108), eBird (Q5322614), The Clements Checklist of Birds of the World (Q3845359) or Avibase (Q20749148) They often disagree about the taxon rank (P105) should be applied to a taxon (e.g. species vs. subspecies), what name (=taxon name (P225)) should be applied to the taxon or which genus concept (=parent taxon (P171)) is to be preferred. --Succu (talk) 19:34, 20 October 2018 (UTC)

@Succu : To be clear, you imply that Wikidata can not use subclass of (P279) is not possible in Wikidata because it would not be a good ontology practice because it would imply a non mono hierarchical classification ? I have answers to this but I want to be sure I understand your point before giving it a try. author  TomT0m / talk page 09:37, 23 October 2018 (UTC)

This is one argument. WD depends on citable references. You will hardly find a lot for subclasses. And if I remember right you advocated the deletion of parent taxon (P171) (and taxon rank (P105)) in the past. But they a part of the everyday life out there. --Succu (talk) 18:31, 24 October 2018 (UTC)

• References are definitely not a problem, if we decide that taxon are classes as Brya said below, then a source is equally valid for « parent taxon » and for the analog « subclass of » statement, this is just a problem of terms, definitely not a conceptual problem. It’s just a different way of saying the same thing. So no reference problem.
• I don’t really care about « taxon rank », but it’s true that if you consider a rank as a special kind of taxon, say « species » is a subclass of « taxon » (so any species or genera become a taxon), you can very well model a species taxon such as
  ⟨ Vulpes vulpes ⟩ instance of (P31) ⟨ species ⟩
  stating both the rank and the fact it is a taxon in only one statement. Ranks can be ordered thanks to metasubclass of (P2445) leading to
  ⟨ species ⟩ metasubclass of (P2445) ⟨ genera ⟩
  reflecting the fact that genera ranked taxon are always higher in the taxon hierarchy than species, a fact that is not reflected in Wikidata currently if I’m not wrong (same for all ranks of course). All these is possible thanks to the use of the « metaclass » notion. Still doable I guess if you’re not too attached to the rank item are modelled right now (they seem pretty messy at first sight)
• Monohierarchy : Wikidata lives with non-monohierarchy without a lot of problems, and in the taxonomy field it’s not a problem (at least no more a problem than to leave with a « parent taxon » not being a monohierarchy sometimes). Especially, if you restrict the queries to work only with taxon instances, you can work with « parent taxon » just the way you are working with « parent taxon ».

All this seems really no big changes in the ontology to me (but a lot of changes in the data, and minor changes in the infoboxes, sure :) That’s why I’m aware it’s unlikely to happen at that point, it would have been a lot easier in the early steps ), and allows to use taxon in the commons metadata just as any other class to tag pictures, for example. But really it would be just a matter of expressing exactly the same informations in less statement - instead of « instance of : taxon and rank : species and parent taxon : [the genus] » just state « instance of : species » and « subclass of : [the genus] ». Changes in the taxobox : recover the rank thanks to « instance of » instead of « taxon rank » and the genus thanks to « subclass of », just checking amongst the different possible values those who are actual genuses (instance of genuses or another taxon) Benefits for Wikidata : same notions of class everywhere, it’s natural to state that an animal item is an instance of its scientific taxon. For commons, you use the same way of tagging a church instance on a picture than a kangaroo, and benefit of the scientific class hierarchy at easily for metadatas. author  TomT0m / talk page 19:37, 24 October 2018 (UTC)

Commons Kumara includes now three species. The whole genus was regarded as a synonym of Aloe until recently. So how does this knowledge helps here? --Succu (talk) 21:12, 24 October 2018 (UTC)

@TomT0m: yes, that’s not possible, constraints are always defined for an entire property, independent of its value. --Lucas Werkmeister (talk) 12:25, 21 October 2018 (UTC)

By definition a taxon is a set, a class. Anything marked as "instance of: taxon" is a class (or should be, there are a number of homonyms, etc which have not been separated out yet, and which are just names). Taxonomy items are peculiar in that any one item may deal with an indefinite number of classes (more or less variations of one class) and that in some cases it may deal with the same class as another item. - Brya (talk) 16:46, 19 October 2018 (UTC)

(or should be, there are a number of homonyms, etc which have not been separated out yet, and which are just names) Wikidata can only mirror current scientific knowledge, with an inherent lag in the update, so that distinction does not seem to be relevant. Anyway, older deprecated taxon can be considered a class of organisms easily, and all it takes to remove them from the « taxon » class in Wikidata is to deprecate the « 

⟨ subject ⟩ instance of (P31) ⟨ taxon ⟩

 » statement. For the name themselves, what do you think of the idea to handle them with the lexicographical part of Wikidata ? this provides a way to easily deal with homonym (Q902085)    for example, different senses.

For the rest, that does not sound really peculiar to taxonomy actually :) author  TomT0m / talk page 12:49, 20 October 2018 (UTC)

„Wikidata can only mirror current scientific knowledge“. I think the slogan was that WD is the sum of all knowledge. --Succu (talk) 19:47, 20 October 2018 (UTC)

You very well know that Wikidata is secondary and should not invent datas that is not backed up by external sources, and that does not contradict the fact that Wikidata aims to be the sum of all knowledge, this is orthogonal. The best we can do is to reduce the lag of the mirroring to tend to zéro if we’re so good that the publishers of those external reliable sources pushes themselves the data on Wikidata as soon as they publish them themselves. But that diverts a little bit to the topic. author  TomT0m / talk page 10:05, 23 October 2018 (UTC)

Even without the spoken text Markus Krötzschs Ontological Modelling in Wikidata (2018) is interesting. --Succu (talk) 18:20, 19 October 2018 (UTC)

Sure inference rules would be a welcome fresh air input ! I’m happy to see there might be an opening that Wikidata will take that path after the commns metadata and lexicographical data turn, unfortunately this is a big challenge that might not be achieved soon … But sure I’d welcome a « ?A parent_taxon ?B -> ?A subclass of ?B ». author  TomT0m / talk page 12:17, 20 October 2018 (UTC)

Revealing is the comment here: „Me and other admins are unfortunately aware of this and this is exactly what I was referring to in my previous e-mail. I do agree with you the situation there is frankly unbearable, and IMHO it will likely be ended also through "removals" of some users who think they should be the only one in charge of deciding what's good and what's not.“. --Succu (talk) 18:20, 19 October 2018 (UTC)

Edit notice for taxon name (P225)

There a few points mentioned in the lengthy discussion on project chat that could be solved with existing mediawiki features, e.g. one mentioned by @MPF: suggesting to locking the value P225. Instead of doing that, one could merely display an edit notice when someone attempts to change its value. If my non-specialist understanding is correct, the value shouldn't be changed unless it's a minor misspelling or caps are used incorrectly. Users may attempt to change it because the taxon described by the item is now a synonym of name that doesn't have an item yet. In that case, the approach seems to be to create a new item for the new name. I think the edit notice could simple state that. --- Jura 13:23, 20 October 2018 (UTC)

If this is possible it should be done. --Succu (talk) 18:58, 20 October 2018 (UTC)

An edit notice sounds like a very good idea. - Brya (talk) 03:02, 21 October 2018 (UTC)

==Taxon name - "how to"==

Please bear in mind that the value for taxon name (P225) associated with this item shouldn't be changed to another one. This unless you merely attempt to correct a typo.

If the name became a synonym of another one, create a new item for the name (if needed) and a statement with taxon synonym (P1420) to that item.

How about the text above? Don't hesitate to edit it. It could be triggered by an edit that attempts to change an existing name and displayed. The user could then still proceed. @Matěj_Suchánek: would you kindly add it with something like:

'/* wbsetclaim-update:2||1 */ [[Property:P225]]' in summary

Thanks. --- Jura 03:11, 21 October 2018 (UTC)

First thought:

==Taxon name - "how to"==

The value for taxon name (P225) in any item shouldn't be changed (except for spelling corrections).

If a taxonomic paper or book introduces a name change, create a new item for the new name (if needed) and add a statement with taxon synonym (P1420) to that item.

- Brya (talk) 03:45, 21 October 2018 (UTC)

• Sounds good. I'd formulate specifically to edit that triggers it ("this" instead of "any"). --- Jura 03:54, 21 October 2018 (UTC)

==Taxon name - "how to"==

The value for taxon name (P225) in this (or any) item shouldn't be changed (except for spelling corrections).

If a taxonomic paper or book introduces a name change, create a new item for the new name (if needed) and add a statement with taxon synonym (P1420) to that item.

- Brya (talk) 04:19, 21 October 2018 (UTC)

 Comment The format should be as simple as MediaWiki:Abusefilter-warning-badge. Matěj Suchánek (talk) 09:48, 21 October 2018 (UTC)

@Matěj Suchánek: Feel free to drop the section header or otherwise tweak the layout/wording. --- Jura 11:17, 21 October 2018 (UTC)

• @Matěj Suchánek: could you add it? --- Jura 03:13, 25 October 2018 (UTC)

   Done Special:AbuseFilter/112 is ready. Sorry for not responding. From these days, you may get faster responses on the noticeboards rather than from me. Matěj Suchánek (talk) 15:09, 25 October 2018 (UTC)

• Thx. Saw it in action right now. --Succu (talk) 07:11, 27 October 2018 (UTC)

Get sitelinks from taxon synonym (P1420) value

Another point mentioned in the project chat discussion is that sitelinks to various Wikipedias might be on one or the other item. A simple fix to offer to Wikipedias could be a modified version of Template:Interwikis from P460 (Q21529474). If. for a language, no interwiki is present on the item linked to an article, the template loads it from a second item linked from the first one. Even if Wikipedias don't adopt it, it becomes a decision of theirs (not have such links). --- Jura 04:26, 22 October 2018 (UTC)

Something like this might be a good idea. However, keep in mind that P1420 is not a symmetrical property. - Brya (talk) 04:46, 22 October 2018 (UTC)

Yes, but it's probably more of an issue if the sitelinks to the old name aren't present when one changes the article than the other way round. --- Jura 04:50, 22 October 2018 (UTC)

• I updated the module Module:Interwiki from P460 (Q21533309) to enable Template:Interwikis from P1420 (Q57672882) and suggested it at Commons. It's now active with c:Template:Wikidata_Infobox. Sample use at c:Category:Leptothorax kutteri. --- Jura 18:56, 29 October 2018 (UTC)

Multiple images for larva vs adult insects

How should one model multiple images corresponding to the larva and adult stage of the same species of insect? Is there a qualifier I could use for each image? Case in point: Adelpha serpa (Q2824271). @Ambrosia10, Daniel_Mietchen, Andrawaag: your thoughts? --DarTar (talk) 05:02, 22 October 2018 (UTC)

I have yet to come across an example of this in Wikidata to give me guidance. I haven't seen a qualifier and would like to know if one exists. Where I can find appropriate images I tend to add one of both the male and female of the adult of the species as well as the best image I can find of the larvae. Of course there are species where the larvae goes through stages where they can look quite different so I imagine that for some species several images of the larvae stages may be necessary.--Ambrosia10 (talk) 06:30, 22 October 2018 (UTC)

I'd set up a dedicated item for stages within that species' life cycle. --Daniel Mietchen (talk) 06:43, 22 October 2018 (UTC)

indeed, and maybe just used instance of (P31) as qualifier property, like I did in your example. --Andrawaag (talk) 11:16, 22 October 2018 (UTC)

@Ambrosia10, Daniel_Mietchen, Andrawaag: thanks for the notes. I removed the instance of (P31) qualifier Andra added because it created a pretty significant constraint violation (P31 is not expected to be used there). I find creating subitems for different species would be overkill unless there are extensive statements to be predicated of a specific stage. If not, a qualifier for an image seems to be the right approach, but we'd need to figure out what property to use. Alternatively, one could image different types of image properties (after all we have logo image (P154) as distinct from image (P18) and I don't see why distinguishing a logo from a generic image should be more important than differentiating types of images for an item about a species).--DarTar (talk) 05:11, 23 October 2018 (UTC)

@DarTar, Ambrosia10, Andrawaag: I fully expect that, over time, individual species will be represented by multiple items that reflect things like phenotype, genotype, evolution and diversity of the species. For instance, we already have items for individual genes (with SNPs being discussed) or cell types for some species, and so it would make sense to fill in the missing granularity as needed to bridge between the different levels of organization, and things like 3rd-instar larvae would make perfect sense to me to have as what you call subitems for arthropod species, as long as these items can be annotated usefully, e.g. with images. --Daniel Mietchen (talk) 11:10, 24 October 2018 (UTC)

@Daniel Mietchen, Ambrosia10, Andrawaag: my main concern with creating from scratch the lowest levels in a data model is that data becomes much harder to discover or aggregate. This also makes it difficult for contributors to understand what the canonical way of representing a concept should be. It's the exact same issue I have with the idea of individual preprint versions having their own dedicated item in Wikidata (see my recent tweets): of course they could, is it useful at this time, I don't think so. I'd much rather create the parent level and create "subitems" over time and as needed, not at a time when the overall data at the parent level is still so sparse that it's hardly of any use. Call me a pragmatic incrementalist?--DarTar (talk) 23:32, 28 October 2018 (UTC)

Since there is (I assume) no great hurry to resolve this, it would be "incrementally pragmatic" - ;-) - to wait for the outcome of current discussions around multiple depicts-type properties for structured data on Commons. A short-term work around would be to create items like "image of larva", and use object has role (P3831). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 07:26, 30 October 2018 (UTC)

I agree that what we have at the moment tends to be very empty, and that it is more useful to add data to items than to add more items. What we need is a suitable qualifier for images, something that indicates what is the topic of the picture. Is there a reason depicts (P180) would not work? - Brya (talk) 05:24, 29 October 2018 (UTC)