We should not have populations with the same population set and number (rdfs label)

[stappan]

We need to ensure that records in Composer do not reuse the unique combination of population set & index.

There are two different IRIs for 3 pairs of senmot populations. These are actually coming from the exported sheet where one is using http://uri.interlex.org/uris/composer/ IRI and the other is using the http://uri.interlex.org/tgbugs/uris/readable/sparc-nlp/ IRI. We should be using http://uri.interlex.org/tgbugs/uris/readable/sparc-nlp/ for these. But it was hard for me to manually fix these since they are actually different populations with completely different pathways with the same rdfs:label (the Short Name in Composer/ the Subject column in the exported sheet). I am using this export: https://composer.scicrunch.io/media/exports/export_v5-2-0_2025-10-16_20-56-09.csv
First pair:
neuron type senmot 1.
hasComposerURI: https://composer.scicrunch.io/statement/222
neuron type senmot 1
hasComposerURI: https://composer.scicrunch.io/statement/502

Second pair:
neuron type senmot 2
hasComposerURI: https://composer.scicrunch.io/statement/223
neuron type senmot 2
hasComposerURI: https://composer.scicrunch.io/statement/503

Third pair:
neuron type senmot 3
hasComposerURI: https://composer.scicrunch.io/statement/224
neuron type senmot 3
hasComposerURI: https://composer.scicrunch.io/statement/501

It's confusing, but 222, 223, and 224 have incorrect rdfs labels. (they're actually senmot 21, 22, 23).
222 has the wrong rdfs label, and should be senmot 21 ; not senmot 1. Statement 222 should be deleted because 477 is the accurate senmot 21.
502 is the correct senmot 1.

223 has the wrong rdfs label, and should be deleted. The one that should be kept is 435 *; they are senmot 22
503 is the correct senmot 2.

224 has the wrong rdfs label, and should be deleted. The one that should be kept is 427; they are senmot 23
501 is the correct senmot 3

How did this occur on ingest? and how do we prohibit this from occurring again?

[smtifahim]

The markdown syntax rendered the populations with embedded IRIs, so the IRIs for each pair were not obvious in the issue that Sue posted above. Here is the same list of pairs with visible IRIs for each pair of populations. Sue's suggestion is to keep the bold ones and remove the other ones. But we should definitely determine what caused this issue to occur.

First pair:

• neuron type senmot 1: http://uri.interlex.org/composer/uris/set/senmot/1
  hasComposerURI: https://composer.scicrunch.io/statement/222
• neuron type senmot 1: http://uri.interlex.org/tgbugs/uris/readable/sparc-nlp/senmot/1
  hasComposerURI: https://composer.scicrunch.io/statement/502

Second pair:

• neuron type senmot 2: http://uri.interlex.org/composer/uris/set/senmot/2
  hasComposerURI: https://composer.scicrunch.io/statement/223
• neuron type senmot 2: http://uri.interlex.org/tgbugs/uris/readable/sparc-nlp/senmot/2
  hasComposerURI: https://composer.scicrunch.io/statement/503

Third pair:

• neuron type senmot 3: http://uri.interlex.org/composer/uris/set/senmot/3
  hasComposerURI: https://composer.scicrunch.io/statement/224
• neuron type senmot 3: http://uri.interlex.org/tgbugs/uris/readable/sparc-nlp/senmot/3
  hasComposerURI: https://composer.scicrunch.io/statement/501

[afonsobspinto]

It looks like the problem is that the neurondm population IDs have changed. The ingestion mechanism relies on those IDs to determine whether it should create a new statement or update an existing one.

From the issue title, I understand that you’re suggesting we change the ingestion logic to use the population set + number as a stable identifier instead of the current neuron IDs — is that correct?

[stappan]

@afonsobspinto is this the same problem as relying on the path to determine the uniqueness of the anatomical entity? And since this seems to be an area where things are getting confused, can you state here what you are specifying as Neuron IDs?
is it Column B in the export?

Are you saying that we would need to not just ingest the rdfs label from neurondm (#385) but also use that as criteria to ensure we're not duplicating entries on ingest?

[afonsobspinto]

is this the same problem as relying on the path to determine the uniqueness of the anatomical entity?

The concept is similar, yes. For anatomical entities, we rely on the ontology_uri. This means that if we have URIs such as
http://uri.interlex.org/base/ilx_0726402 and http://purl.obolibrary.org/obo/UBERON_0004243, they’ll be treated as different anatomical entities, even if they represent the same one.

can you state here what you are specifying as Neuron IDs?
is it Column B in the export?

Yes — when I mentioned the Neuron ID, I was referring to Column B (Subject URI), which corresponds to reference_uri in Composer and id in neurondm.

Are you saying that we would need to not just ingest the rdfs label from neurondm (#385) but also use that as criteria to ensure we're not duplicating entries on ingest?

Yes, that’s what I was asking — whether this is the desired behavior.
Please be aware that in addition to the label, we’d also need to retrieve the index and for the mapping to work properly, the indexes would need to match between neurondm and Composer. Currently, there’s nothing enforcing that alignment on our side, so this could pose a problem.

[stappan]

I believe that this is the remaining effort in order to make #393 coherent and consistent across all uses of the knowledge statement records (creation, export, ingest). is there anything missing? this "Currently, there’s nothing enforcing that alignment on our side, so this could pose a problem." surprises and worries me