Wikidata talk:WikiProject Infoboxes/terms

On properties, ranks, and redundancy (biology)

Sorry, but I'm not sure that listing every rank is necessary. Why not just indicate the value for the next rank "up" in the tree and use recursion to get the rest? πr² (t • c) 22:24, 2 February 2013 (UTC)

For example, Wikispecies uses templates that call the next level-up template to generate the ranks you see. πr² (t • c) 14:17, 3 February 2013 (UTC)

You are right, there should be some way of automation. --Kolja21 (talk) 18:13, 3 February 2013 (UTC)

Example for people who might not understand: Q3238275 (Homo sapiens sapiens) should link to Q5 (Homo sapiens) as the "next level up", which in turn should link to the genus Q171283 (Homo). This chain would continue all the way down to Q729 (Animal[ia]). Even Animalia should link to Eukaryota. After that, we could have it link to the article on Life, but I don't think it's strictly necessary (that's just a minor detail anyway). So please revise this, otherwise we will have lots of redundancy in data! (Every simian [monkey, apes] species item will need to duplicate the Animalia, Chordata, Mammalia, Primates, Haplorhini, Simiiformes chain even though we only need to specify this information once. And even this example chain I wrote is skipping more obscure ranks like "Gnathostomata"; we would definitely add those steps in between, I just thought it would be obscure for an example. This would save space, and it would allow us to correct errors more quickly. Wikispecies currently uses this approach: see the code of the template {{Homo sapiens sapiens}}. which calls the template {{Homo sapiens}}, which in turn calls {{Homo}}. You can follow this tree all the way to species:Template:Animalia, and even that has links to the superregnum. This is a very interesting system, and (IMHO) it is better than the option specified on this page. πr² (t • c) 02:30, 4 February 2013 (UTC)

The best way to make this public is to leave a note at Wikidata:Contact the development team‎. I would wait till tomorrow, after the first step of phase 2 has started. I think/hope the development team is already planing in your direction. --Kolja21 (talk) 02:44, 4 February 2013 (UTC)

Posted. πr² (t • c) 02:55, 4 February 2013 (UTC)

What you want here is reasoning I think. It is currently not planned to implement this in the system because that is a major thing and needs careful thinking and a good concept before working on it. You can have bots take care of this for specific cases if you want it for now. --Lydia Pintscher (WMDE) (talk) 15:23, 5 February 2013 (UTC)

But someone needs to start thinking about this, or we won't be able to proceed with properties of the more than 1,000,000 entries we'll have for biological species. Right now "cat " (Q146) is being held up as a model, but it uses direct input of all the higher levels. That's what editors are going to see and start copying. This will lead to enormous problems down the line, as when a new classification changes the family and order for thousands of species (it's happened more than once in the last twenty years). Taxonomic information should proceed only to the next higher rank, and not include all the higher ones, to avoid unnecessary work in data maintenance. --EncycloPetey (talk) 06:35, 26 March 2013 (UTC)

I think it is a real big problem if we try to list every rank here.

First lots of species have more than one scientific name which is currently in use. If you look in Avibase for the Masked Duck you find that

• "American Ornithologists' Union 7th edition (incl. 53rd suppl.)", "Birdlife checklist version 05", "Commission internationale pour les noms français des oiseaux (1993)", "Howard and Moore 3rd edition (incl. corrigenda 8)", "IOC World Bird Names, version 3.02", "South American Classification Committee (4/09/2012), "Zoonomen - Zoological Nomenclature Resource" : call it Nomonyx dominicus
• Sibley and Monroe 2nd edition (1996): Nomonyx dominica
• "The Handbook of the Birds of the World (vol 1-16)", "Morony, Bock and Farrand" and "James Lee Peters": Oxyura dominica[1]
• Additionally Erismatura dominica and Oxyura dominicus are mentioned as scientific names for the bird
• If you look for really old scientific synonyms, for example in worldbirdinfo.net there are much more: Anas dominica, Querquedula dominicensis, Anas spinosa, Fuligula dominica, Cerconectes spinosa, Erismatura spinosa, Erismatura ortygoides, Dendrocygnus spinosa, Biziura dominica, Erismatura ferruginea

And I am shure, these are not all of them, as I didn't find all old bird names, I was searching for, in this database. For example I didn't find the modern names of Thaumatias affinis, Eucephala caeruleolavata and Eucephala chlorocephala from the old prints of John Gould: A Monograph of the Trochilidae in worldbirdinfo.net

For us the really relevant fact is: There are two genuses for this bird, wich may be in use in the Wikipedias today.

In the higher orders there are such problems too. I you look in Category:Accipitriformes in Commons you find: "Included families (for IOC classification 2.3): Accipitridae, Cathartidae, Pandionidae, Sagittariidae. Note: Most of these families is placed under Falconiformes by IUCN, under Ciconiiformes by ITIS"

--Kersti (talk) 03:25, 7 April 2013 (UTC)

Dealing with synonyms isn't such a problem. Wikispecies already has a good system in place for synonyms of taxa names. However, Wikidata can't simply patch in to that, because the data structure between the names on Wikispecies and the taxa on the Wikipedias is not one-to-one, and never will be. The Wikidata model for data structure assumes one-to-one matches, and as long as it does, then the Wikispecies and Wikipedia interconnections cannot be established. --EncycloPetey (talk) 04:26, 7 April 2013 (UTC)

My topic is not dealing with synonyms - that is for itself very easy. My topic is dealing with the fact that the same Genus in different taxonomic systems has not the same species and not the same number of of species in it. That the same genus may in different taxonomic systems belong to different families. But if the included species change, the genus and family description has to change too. This information changes in the IOC twice a year. We can change the taxobox info here twice a year - but a small Wikipedia can't change all the articles with this kind of changes twice a year! And taxobox information has to fit with the article information to be understandable as a whole. Therefore it is nessesary to give the possibility to choose one version of one taxonomic system and keep it for some years and than to update it group by group in a time the small wikipedia can manage such changes.

One-to-one-matches are possible, I think, as each taxon has a type species by which it is defined even if the total number of includet species changes. I don't see a problem, if one uses the scientific name.

Therefore the taxonomic information hast to be sourced for example as "IOC 3.2" and the information has to be kept. And it must be possible to choose the information by taxonomis System and its version. Kersti (talk) 20:03, 7 April 2013 (UTC)

In dewiki there's some experience concerning this task. The trigger was the rearrangement of taxoboxes of plants due to APG III in 2009. The goal was to implement a procedure to be aware for next comparable rearrangements. A template based solution was favored first (like WikiSpecies, see above). Finally we preferred a bot-based procedure: Taxobot (see Taxobot, only german yet). In short:

• There is a master page with complete required taxon tree (e.g. Mammalia)
• the relation of taxa ist defined using a list with indend (*, wiki markup)
• a taxon line consist of following elements (separated by backslash, some optional
  1. rank
  2. scientific name
  3. comon name
  4. linkname (that is, lemma, if different to 2 or 3)
  5. taxon authority (required only for monotypic taxa)

The advantages of bot procedure and using a master page in this way:

• the entire systematics is found on one page
• it is comparatively easy to understand (non-geeks are able to edit this page)
• conformance of taxobox and categories can be checked/corrected too (e.g. [2])
• somte intermedia taxa can be marked as less importad ("^" before rank). Then they will be left out in upper half of taxobox.

Certainly, there are some disadvantages too. In my experience it is sufficient to run Taxobot half a year. It's doubtless a challenge to implement a procedure in Wikidata that will be accepted by experts. I suggest you should think about a bot based procedure even with Wikidata. Another advice: Don't start with Taxoboxes, we should gain experience with easier things first. --Cactus26 (talk) 06:45, 8 April 2013 (UTC)

That really sounds like a good idea. Kersti (talk) 13:25, 8 April 2013 (UTC)

References

How does Wikidata show where the data entry comes from? For example wikipedia:de:Vorlage:Infobox Chemikalie strictly enforces a source for the GHS labelling and has it's own data field where source templates or reference tags have to be added to warn with a maintenance category that this article needs attention if this required field is missing. Other entries such as boiling point might also come from the same material safety data sheet but get a references tag placed just behind it in the same value field. Should we therefore add a $_source field for every entry? Matthias M. (talk) 14:31, 4 February 2013 (UTC)

I think yes, but I haven't tested the properties yet. --Kolja21 (talk) 20:14, 4 February 2013 (UTC)

Unfortunately the sources field is not in use yet. You can enter whatever you want. --Kolja21 (talk) 02:54, 5 February 2013 (UTC)

Enantiomers

There are very similar substances that are not the same in toxicity (think of Thalidomide) or physical properties such as melting point. They are usually described together in one Wikipedia article. What is the best way to handle them in WikiData? Matthias M. (talk) 10:30, 5 February 2013 (UTC)

Just add them as new items.I don't know how it works on other wikipedias but in the french one, there are different article for enantiomers or mixture of enantiomers. The only restriction will be to be accurate when filling the database with the correct information at the right place. Snipre (talk) 16:55, 5 February 2013 (UTC)

Comment: Enantiomers do actually have the same melting point etc. However, this is not true for the mixture vs. single enantiomers. --Leyo 18:42, 5 February 2013 (UTC)

The current version of the software only allows one to one sitelinks between a wikidata page and pages on language wikipedias. Each Wikidata page can only link to one page on each language wikipedia (links to redirects not allowed) and each page on each language wikipedia can only link to one page on Wikidata.

This means that we need wikidata pages for each bunch of different language WP pages which describe one Enantiomer and we need a separate wikidata page for the wikipedia pages which describe them all on one page. Unfortunately this means that the language links on the WP page for one Enantiomer only link to wikipedias which have that Enantiomer as a separate page and wikipedias which have a group page can only have language links to other wikipedias with group pages though they can have infoboxes for each Enantiomer provided the data is imported from the wikidata pages for each Enantiomer rather than from the wikidata page for pages which group the Enantiomers. I have asked the devs for a 'see also' field to be added to each WD page so the pages for groups of Enantiomers can have a link to the WD pages for individual Enantiomers to help you find the right page when you are adding sitelinks.

If there are Enantiomers which do not have Wikipedia pages in any language then under the current guidelines they should not get a Wikidata page but this is a community guideline, not a software requirement and I think there would be a good case for changing the guideline to allow WD pages with no sitelinks in this case.

At least that is how I understand it. Did I get it right? Filceolaire (talk) 18:39, 6 February 2013 (UTC)

Astronomical parent bodies

Today, planets can have multiple 'natural satellite' properties. Should there be a property 'Parent body' on satellites that refers to their parent planet? Same comment goes for planets referring to their parent star, stars to their galaxy/cluster, and so on up the hierarchy. Should there be a separate property for each 'level' of hierarchy, i.e. "parent planet", "parent star", "parent galaxy" etc? There are some cases, like Pluto and Charon, where it's unclear whether Charon's parent body is Pluto or the Sun. How can these be resolved? Jkl (talk) 10:14, 25 February 2013 (UTC)

I opened a discussion here. If you want, it is possible to move it here. --Paperoastro (talk) 12:02, 25 February 2013 (UTC)

I think that there should be a greater level of hierarchy in the properties. Currently there are Natural satellite, Planet and Host galaxy. I think that the range should be increased so as to have from Small Solar System body to Galaxy Filament as I believe this would add order and structure. --名無し (talk) 13:50, 1 March 2013 (UTC)

I'm agree with you. There is two manner: increase the number of properties or make as for administrative division, with few general ones. An idea might be these four property: parent body, children body, companion of (for pairs of galaxies or stars systems) and belong to (for rings, "places" on planets or satellites, protoplanetary accreting discs, filaments...). What do you think about it? --Paperoastro (talk) 15:03, 1 March 2013 (UTC) P.S.: the discussion that I opened at project chat was archived: if you are interested, here there is the opinion of Espeso.

I have just proposed four properties following your and other user indications. Bye, Paperoastro (talk) 17:47, 5 March 2013 (UTC)