Discussions on Bird Info

My suggestion:

I don't see any way to do this except to add an AOU taxonomy CVT for each bird taxon’s English name. The CVT would link the AOU English name to its organism rank, Latin name, AOU edition, and AOU supplement. Both the English and Latin names can change over time so all this information needs to be stored together. Following the current Freebase format, the English name should be the topic described by the CVT. The higher and lower AOU taxa ranks probably need to be included in the AOU CVT too.

If the AOU English name is the same as the ITIS English name then the topic will have both types. If the AOU name is different than ITIS then it will only have one or the other type. There is no way to properly "resolve" these different taxonomic systems. They are similar but different and both change over time. The changes within each system need to be maintained. Perhaps a “most similar ITIS taxon” property is needed, especially for those bird topics that do not have the same AOU and ITIS common names. Alternatively, we could use a more generic “equals”, “overlaps”, “contains”, and “contained by” properties for defining relationships among taxon topics associated with multiple taxonomies.

I've brought this non-overlapping category issue up a few times now under the umbrella of "crosswalks" in various discussions, including those related to taxonomy. I still think they are a necessity. The world is categorized by different people in different ways. In this case, ITIS circa 2007 is not going to work as a one-size-fits-all taxonomic system. There are dozens of other taxonomies, including AOU. Freebase provides an amazing tool for describing relationships among taxonomies and other categorical classification systems. This ITIS/AOU conflict provides yet another example of how categories can be crosswalked in Freebase. Land cover classification schemes provide another.

I'm working on an AOU taxonomy type but the current version of the UI is stymieing me again by not allowing me to delete properties or change the key. The draft is: http://www.freebase.com/type/schema/user/spatialed/bird_codes/aou  Ignore the properties below AOU supplement. The AOU code properties will need to be added separately, possibly within an AOU bucket type that contains the taxonomy CVT and a standard type with additional properties that do not need to be directly linked to the taxonomy.

So... after playing with the AOU taxonomy type for awhile I wasn't happy with it.

I decided to let the existing Freebase English bird names drive the links between common names (linked to ITIS codes) and AOU English names. Each English bird name is type as "AOU English name" type. This type contains an "AOU Latin name" property/type that has disambiguation for taxon rank (e.g., species) and source (i.e., an edition of the AOU checklist and possibly supplement). For each AOU English name, one or more AOU Latin names can be added to track changes. For each Latin name, only one English name can be added. This means that there could be duplicate Latin names if one was changed in say the 5th edition of the checklist and then changed back in the 7th edition. Disambiguation is used to distinguish the similar Latin names topics by edition/supplement.

So far this seems to work alright. The English names are simple to update. The Latin names are where the effort must be made to keep track of changes.

Because of the way this is structured, Latin names are automatically reciprocated back to the checklist editions and supplements, which is great. Common names, however, must be reciprocated through additional properties. This adds some denormalization but I can't figure out how to get around that yet.

Update: I have added properties for previous and revised English and Latin names. This is so far the best way I can figure out how to explictly make those connections.

Also note that the AOU Latin names can only be linked to 1 edition of the checklist/supplement whereas common names can be linked to multiple. My thinking is that the Latin name will be used to identify the first case in which the Latin-English combo were used (only the American Flamingo data currently represent this relationship). The common name on the other hand can hold all instances of association with Latin names, editions, and supplements.

+1, we should have one topic for one concept, and co-type as required for AOU or whatever other data we wish to capture for that concept.   

What are the examples of AOU and ITIS taxonomy (not just names) conflicting?  It could be that we just have not added taxa aliases yet... 

I stick with my comments above for why your simple approach, while very desirable, is not appropriate.

I have tried to link to existing topics whenever possible but it is not always possible. I have also tried to provide documentation when links with existing topics are not appropriate (read above as well as the description and data for those topics). Jeff's reference to American Flamingo (the "here, here, here, and here") related topics is a great example. See this discussion on some of the historical merges and splits of this taxon/taxa with P. roseus in the 80's and 90's. How can this historical information be documented in the current schema? As an alias? That's not very useful. I'd like to see historical information summarized in Freebase rather than see Freebase turn into an encyclopedia limited to a single taxonomy at a single point in time with aliases that may or may not be appropriate depending on the date.

What about a hypothetical but possible example of taxa that were split, where one side of the split keeps the Latin name and the other doesn't but both get new English names?

What about a hypothetical but possible example of three taxonomic classification systems for plants, where one describes a taxon, the second splits it into two taxa, and the third splits it into two taxa but merges the second with a third that is not included in the first. Worse yet, each of these three classification systems may use the same English name for one of the taxa but different Latin names. Now what?

I agree that we should only have one topic for a concept but there are few universal taxonomic concepts, especially if considered since Linneaus.To model dynamic and sometimes conflicting taxonomic systems and relationships, I did exactly what jg suggested: "have one topic for one concept, and co-type as required for AOU or whatever other data we wish to capture for that concept." My approach may not be the best way to model these relationships but I don't make up data or relationships to fit a simple mold. It seems that's what you want to sometimes by funneling conflicts into aliases.

Aye Aye. I'm interested in your interpretation of the status quo. There have been eight supplements to the 7th edition of the AOU check-list since it was published in 1998. Are these changes to be ignored or are the historical data to be erased? For example, there is no longer a Caribbean Flamingo so what are you going to do with that topic? Just add an alias? Currently you keep the defunct name for the topic and add the new name as an alias. This is an issue for 12 other taxa too: 

"13 English names are changed (Phoenicopterus ruber becomes American Flamingo, two species of Colibri become Violetear rather than Violet-ear, Goethalsia bella becomes Pirre [rather than Rufous-cheeked] Hummingbird, Cnipodectes subbrunneus becomes Brownish Twistwing rather than Brownish Flycatcher, six species of Turdus become Thrush rather than Robin, Chlorothraupis carmioli becomes Carmiol’s [rather than Olive] Tanager, and Troupial becomes Venezuelan Troupial)"

 A little more difficult is that "two genera (Lysurus and Buarremon) are lost by merger (with Arremon);" Are the historcal genera to be deleted OR is the new genus to be ignored OR is the new genus to be added as an alias to both defunct genus topics OR are the historical genera to be merged into the new genus, added as aliases, and all documentation (which might have conflicts) merged into the new genus topic?

Similarly, "18 scientific names are changed by transfer from one genus to another".  Will the new genus be added as an alias to the old one? Will the higher classification be changed to the new genus? If the higher classifcation is changed, will the old genus (or at least its links) be deleted? 

What happens when someone wants to add data for a species that is no longer considered a species (e.g., name changed in the 1800s) and is therefore not included in Freebase? Are they supposed to link it to the closest existing taxon topic and list the old name as an alias even if the historical taxonomic concept was quite different than the existing one?

Thought I would share a comment on this discussion subject from a person who's job is to lead the development of large international conservation projects:

" On taxonomy, you're right.  If the Freebase folks don't appreciate the complexities in taxonomy, they will not be prepared to accept many other complexities in this messy world.  Frankly, I'm surprised - sounds naive to me."

Chris, I'm pretty happy with my model for AOU taxonimical history. The biggest issue I have with it is the creation of duplicate Latin names when there are only changes in English names. It just needs data now, which should be possible to scrape from the AOU editions but would need to be entered by hand from the supplements. I'll enter data from time to time as needed for projects. Hopefully others will too. 

I have no issue with the attempt to model the complexity of a taxonomy -- I'm all for it.  And maybe what Freebase can supply for now is a template to which more complex structures can be appended.

But I share your concern with having to create multiple Latin names when only the English name has changed (and presumably vice versa).  Actually, I have a concern with creating new topics based solely on name-changes in general, but this one is particularly odd.  In cases where there is no change in what is being described, merely the way of describing it, why not just use a CVT linked from an "AOU classification" type, that would contain these properties: Latin name, English name, AOU checklist edition, Supplement, and Reason for change (with the names being text strings). You could then have properties to describe splits and mergers specifically. The current AOU model doesn't seem to allow for this useful distinction, other than as text string note. Right now, for example, you can't necessarily tell whether the "American flamingo" and "Carribean flamingo" are different names for the same organism, or two different ways of splitting up the organisms.

That's my $.02, anyway.