Family shown as child of another family

[dhobern]

COL includes three records for Margaritidae:

https://www.catalogueoflife.org/data/search?facet=rank&facet=issue&facet=status&facet=nomStatus&facet=nameType&facet=field&facet=authorship&facet=extinct&facet=environment&limit=50&offset=0&q=Margaritidae&sortBy=taxonomic

One of these is listed as a child of another family Trochidae.

The MolluscaBase record is here: https://www.molluscabase.org/aphia.php?p=taxdetails&id=714634

It is a record for the subfamily name Margaritinae but shows that MolluscaBase accepts this at the family level as Margaritidae.

Somewhere, this has been interpreted to mean that Trochidae : Margaritinae -> Trochidae : Margaritidae

I think there must be an inference failure on the CLB side that should handle cases like this better, but it is possible there is a failure in the data exported from MolluscaBase.

This issue was pointed out to me by Diana Hernandez.

[yroskov]

@bart-v, do you think it's WoRMS related issue or CoL@CLB interpretation issue for @mdoering?

[TonyRees]

Hi all, I cannot answer the question above, but as a side issue, the homonymy between Margaritidae Blainville (Bivalvia) and Margaritidae Thiele (Gastropoda), both currently treated as accepted names, has been requested to be addressed by the Commission as of now (15 Oct 2022):

Case 3828 – The Family Name of the Pearl Oysters: Proposal to Remove the Homonymy of Margaritidae Blainville, 1824 (Mollusca: Bivalvia) with Margaritidae Thiele, 1924 (Mollusca: Gastropoda) by Emending the Latter to Margaritesidae https://bioone.org/journals/the-bulletin-of-zoological-nomenclature/volume-79/issue-1/bzn.v79.a007/Case-3828--The-Family-Name-of-the-Pearl-Oysters/10.21805/bzn.v79.a007.short

So a decision from the Commission on this one will be useful when it arrives...

Cheers Tony

[TonyRees]

Also noting @bart-v that currently in MolluscaBase, Margaritidae Blainville (https://www.molluscabase.org/aphia.php?p=taxdetails&id=564652) does not include its type genus Margarita Leach, 1814, although it should (as a synonym of Pinctada), along with another 8 or so other synonyms of Pinctada.

[dhobern]

@yroskov - I didn't have time to dig deeper over the weekend, but the place to start is by looking at the actual data supplied from WoRMS/MolluscaBase. Does that assert that Margaritidae is a child of Trochidae? Or does it correctly express the relationship and CLB misinterpret it?

This should be easy to check - then it will be clear whether it is a data or a code issue.

[dhobern]

From the original version imported into CLB, here are four relevant name records:

ID basionymID scientificName authorship rank uninomial genus infragenericEpithet specificEpithet infraspecificEpithet cultivarEpithet code status referenceID publishedInYear publishedInPage publishedInPageLink link remarks

urn:lsid:marinespecies.org:taxname:564652 Margaritidae Blainville, 1824 Family Margaritidae ICZN established 8670 1824 313 https://www.molluscabase.org/aphia.php?p=taxdetails&id=564652

urn:lsid:marinespecies.org:taxname:714634 Margaritidae Thiele, 1924 Family Margaritidae ICZN established 40522 1924 https://www.molluscabase.org/aphia.php?p=taxdetails&id=714634

urn:lsid:marinespecies.org:taxname:224537 Margaritinae Thiele, 1924 Subfamily Margaritinae ICZN 40522 1924 67 https://www.molluscabase.org/aphia.php?p=taxdetails&id=224537 original rank

urn:lsid:marinespecies.org:taxname:1438246 Margaritinae Stoliczka, 1868 Family Margaritinae ICZN 40484 1867-1868 367 https://www.molluscabase.org/aphia.php?p=taxdetails&id=1438246 invalid: type genus (Margarita Leach, 1819) a junior homonym

And here are the three associated taxon records:

ID parentID nameID namePhrase accordingToID scrutinizer scrutinizerID scrutinizerDate provisional referenceID extinct temporalRangeStart temporalRangeEnd environment species section subgenus genus subtribe tribe subfamily family superfamily suborder order subclass class subphylum phylum kingdom link remarks

urn:lsid:marinespecies.org:taxname:138396 urn:lsid:marinespecies.org:taxname:564652 urn:lsid:marinespecies.org:taxname:138396 Marshall, Bruce https://marineinfo.org/id/person/26967 2020-03-25 0 352078 marine Pinctada Margaritidae Pterioidea Ostreida Autobranchia Bivalvia Mollusca Animalia https://www.molluscabase.org/aphia.php?p=taxdetails&id=138396

urn:lsid:marinespecies.org:taxname:564652 urn:lsid:marinespecies.org:taxname:489069 urn:lsid:marinespecies.org:taxname:564652 Bieler, Rüdiger https://marineinfo.org/id/person/19929 2019-10-24 0 8670 marine Margaritidae Pterioidea Ostreida Autobranchia Bivalvia Mollusca Animalia https://www.molluscabase.org/aphia.php?p=taxdetails&id=564652

urn:lsid:marinespecies.org:taxname:224537 urn:lsid:marinespecies.org:taxname:443 urn:lsid:marinespecies.org:taxname:714634 Bouchet, Philippe https://marineinfo.org/id/person/7192 2013-01-03 1 40522 marine Margaritinae Trochidae Trochoidea Trochida Vetigastropoda Gastropoda Mollusca Animalia https://www.molluscabase.org/aphia.php?p=taxdetails&id=224537

The fourth name record seems to be mislabeled as a family, but that's the one that seems not to be referenced in the taxon file. Does one of these records somehow get overwritten by or conflated with another?

I can't see where it will have gone wrong.

[mdoering]

You can find the original record in CLB being interpreted with an issue classification rank order invalid: https://www.checklistbank.org/dataset/1130/taxon/urn:lsid:marinespecies.org:taxname:224537

The verbatim records are here: Taxon: https://www.checklistbank.org/dataset/1130/verbatim/1067178 Name: https://www.checklistbank.org/dataset/1130/verbatim/784384

The name record clearly declares it to be family Margaritidae, the Taxon record places it into the family Trochidae (both consistently via col:family and col:parentID). I don't see we interpret sth wrong, it is given that way.

We should look at flagged issues more carefully to avoid these problems.

[dhobern]

@mdoering It doesn't seem to be that simple. The original name record on which the CLB record is meant to be based is this one:

urn:lsid:marinespecies.org:taxname:224537 Margaritinae Thiele, 1924 Subfamily Margaritinae ICZN 40522 1924 67 https://www.molluscabase.org/aphia.php?p=taxdetails&id=224537 original rank

That is clearly a subfamily record. Something has gone wrong somewhere in WoRMS letting this through as provisionally accepted, but that's a separate issue.

The only name record in the WoRMS dataset that declares Margaritinae to be a family is the OTHER Margaritinae one:

urn:lsid:marinespecies.org:taxname:1438246 Margaritinae Stoliczka, 1868 Family Margaritinae ICZN 40484 1867-1868 367 https://www.molluscabase.org/aphia.php?p=taxdetails&id=1438246 invalid: type genus (Margarita Leach, 1819) a junior homonym

That is certainly another error in WoRMS, but it should not have affected how we interpret and display 224537.

[mdoering]

The links you point out are the original WoRMS/Aphia pages. They differ from what was supplied to CLB via the ColDP files, so it seems to me like an issue in the coldp exporter/generator in WoRMS. @bart-v, could that be?

worms 224537 is given to CLB as a family, not subfamily.

[dhobern]

No - the records I gave were cut-and-pasted from the "Original" ColDP files that I can download again from CLB.

[mdoering]

@dhobern are these lines from the Name.csv file?

It seems the Taxon record causes the problem, because urn:lsid:marinespecies.org:taxname:224537 is linked to nameID https://www.checklistbank.org/dataset/1130/verbatim/784384 which is the family Margaritidae.

The subfamily name record with the 224537 id indeed exists, but it is not used by the taxon with the same id. See https://www.checklistbank.org/dataset/1130/verbatim?q=urn%3Alsid%3Amarinespecies.org%3Ataxname%3A224537&type=col%3AName&type=col%3ATaxon

[dhobern]

Thanks - I guess then that this issue is for WoRMS / @bart-v.

[bart-v]

The main problem is that COL does not allow taxa/names to have unaccepted parent names/taxa, while WoRMS does.

So, when we come across such cases, we replace the unaccepted parent name with the accepted parent name. (we are very flexible in taxa vs. names, vs. classification)

In this example: Gazini Hickman & J. H. McLean, 1990 (unaccepted, tribe) is a child of Margaritinae Thiele, 1924 (unaccepted, subfamily). Thus, when we export, we replace the parent: Margaritinae Thiele, 1924 (unaccepted, subfamily) with the parent: Margaritidae Thiele, 1924 (accepted, family), and mark them as "provisionally accepted". So you end up with Gazini (genus) -> Margaritidae (family) -> Trochidae (family) ...

The issue is that the higher level parents of Margaritidae Thiele, 1924 (accepted, family) are not updated in COL This explains why there are two entries for Margaritidae Thiele, 1924 (provisionally accepted) in COL, while only one in WoRMS

I'm not sure how to fix this. Needs some thinking :)

[dhobern]

Unaccepted names don't need a parent at all in CoLDP. Only (accepted) taxa do. You could declare a name Margaritinae and use that as the basionym for another name Margaritidae and associate the latter with a taxon. The former can be synonymised with the latter. Would that meet your need? I'm not sure where you want to place Gazini in the absence of an accepted location.

--

Donald Hobern / @. / +61 420511471 Araba Bioscan Project https://stangeia.hobern.net/araba-bioscan-project/ / Pterophoroidea https://pterophoroidea.hobern.net/ / Alucitoidea https://alucitoidea.hobern.net/ / BOLD Australia https://bold-au.hobern.net/ ORCID: 0000-0001-6492-4016 https://orcid.org/0000-0001-6492-4016 / Blog https://stangeia.hobern.net/ / iNaturalist https://inaturalist.ala.org.au/people/dhobern / Flickr https://www.flickr.com/photos/dhobern// GitHub https://github.com/dhobern / Twitter https://twitter.com/dhobern / Mastodon @.>

On Tue, 8 Nov 2022 at 23:56, bart-v @.***> wrote:

The main problem is that COL does not allow taxa/names to have unaccepted parent names/taxa, while WoRMS does.

So, when we come across such cases, we replace the unaccepted parent name with the accepted parent name. (we are very flexible in taxa vs. names, vs. classification)

In this example: Gazini https://www.marinespecies.org/aphia.php?p=taxdetails&id=411625 Hickman & J. H. McLean, 1990 (unaccepted, tribe) is a child of Margaritinae https://www.marinespecies.org/aphia.php?p=taxdetails&id=224537 Thiele, 1924 (unaccepted, subfamily). Thus, when we export, we replace the parent: Margaritinae Thiele, 1924 (unaccepted, subfamily) with the parent: Margaritidae Thiele, 1924 (accepted, family), and mark them as "provisionally accepted". So you end up with Gazini (genus) -> Margaritidae (family) -> Trochidae (family) ...

The issue is that the higher level parents of Margaritidae Thiele, 1924 (accepted, family) are not updated in COL This explains why there are two entries for Margaritidae Thiele, 1924 (provisionally accepted) in COL, while only one in WoRMS

I'm not sure how to fix this. Needs some thinking :)

— Reply to this email directly, view it on GitHub https://github.com/CatalogueOfLife/data/issues/482#issuecomment-1307171679, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGHP4ZU3HFI5DQMIWYWWHQLWHJEWFANCNFSM6AAAAAARXWJ6NE . You are receiving this because you were mentioned.Message ID: @.***>

[bart-v]

I know that, so for synonym we could remove the parent. But we have accepted names with unaccepted parents too...

[dhobern]

I see two options there. One is to treat the child as an incertae sedis child of a higher taxon. The other would be to set the provisional=true flag on the unaccepted taxon.

[bart-v]

And don't swap the unaccepted with the accepted parent. So only change the status. Looks like a plan.

Agree @mdoering ?

[mdoering]

The plan is to just set the provisional flag for those unaccepted taxa? Thats a good plan !

[mdoering]

But how do you differ between unaccepted being a synonym and unaccepted being a provsionally accepted name? Is it a synonym if it has no children and provisionally accetepd in case there are children?

[bart-v]

Yes!

[dhobern]

@mdoering - I don't understand your question there. If it's a synonym, there will be a synonym record. If it's a provisionally accepted taxon, there will be a taxon record with provisional=true and no synonymy. There should never be a taxon AND a synonym for the same name. (Not sure how it would work in the NameUsage version.)

[mdoering]

@dhobern my question was to Bart how you can discover in Aphia whether it is a synonym or provisional name - it is both unaccepted there.

And you can definitely have the same name being accepted and a synonym, that is quite often the case with sensu latu names after a split. Examples from latest release. The old name s.l. is a synonym of a new name, but still accepted s.str. While thinking about taxon concept ids I would actually hope to increase the existance of such s.l. synonyms to be more precise.

[dhobern]

Thanks, Markus.

I understood that case, but I don't think it could apply in the situation here of higher taxa.

On Wed, 9 Nov 2022 at 15:04, Markus Döring @.***> wrote:

@dhobern https://github.com/dhobern my question was to Bart how you can discover in Aphia whether it is a synonym or provisional name - it is both unaccepted there.

And you can definitely have the same name being accepted and a synonym, that is quite often the case with sensu latu names after a split. The old name s.l. is a synonym of a new name, but still accepted s.str. While thinking about taxon concept ids https://github.com/CatalogueOfLife/general/issues/6#issuecomment-299317496 I would actually hope to increase the existance of such s.l. synonyms to be more precise.

— Reply to this email directly, view it on GitHub https://github.com/CatalogueOfLife/data/issues/482#issuecomment-1308180646, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGHP4ZUDKQL6P2HZJYYS7UDWHMPEDANCNFSM6AAAAAARXWJ6NE . You are receiving this because you were mentioned.Message ID: @.***>

[mdoering]

surely not, no.

[bart-v]

Actually, it seems like we are already doing this.

This specific case was triggered by something else in the export query that is now fixed. This name will not appear as provisionally accepted any more, as there is no accepted children. Will be available the the next export on 2022-12-01

[camiplata]

@mdoering this issue has been fixed an can be closed