Found by the weak-inferred-identifier warning added in v0.24.0 (spec_validate / SpecBuilder.warnings). These are advisory, not blocking — all ten shipped profiles have zero blocking issues — but each is a real finding: the entity declares no is_identifier, and the positionally-inferred identifier is an optional, unconstrained string.
| Profile |
Field inferred as the identifier |
| isa/1.0 |
Process.name |
| miappe-htp/1.0 |
Location.name |
| miappe-htp/1.0 |
ObservationLevelHierarchy.name |
| miappe-htp/1.0 |
SpatialDistribution.description |
| pride/1.0 |
Publication.title |
Clean: darwin-core/1.0, dissco/0.4, ena/1.0, jerm/1.0, metabolights/1.0, miappe/1.1, miappe/1.2.
Why they were not fixed in place. Adding is_identifier to a released profile is classified BREAKING by compare_specs, so it would force a MAJOR bump on three shipped standards purely to record an identifier that inference already resolves to the same field. That is a deliberate decision to make, not a drive-by edit — hence this issue.
Options: (a) declare the markers and bump each profile's MAJOR version; (b) declare them and argue the comparator should treat 'declaring what inference already chose' as compatible — which would need the comparator to compute the inferred identifier, and is a real design question; (c) accept the advisories as documentation of a known weakness in those standards' own models.
Note the rule was already narrowed once to avoid noise: it exempts a field whose own name states identity (id, sample_id, locationID, database_identifier) and one pinned by pattern/enum/options/unique_within. Without that exemption it fired 25 times across 6 profiles, including all 13 dissco id fields, which are the right identifiers merely unmarked. name/title are deliberately not exempt — they state a display label, which is what the markers exist to keep separate from identity.
Found by the weak-inferred-identifier warning added in v0.24.0 (spec_validate / SpecBuilder.warnings). These are advisory, not blocking — all ten shipped profiles have zero blocking issues — but each is a real finding: the entity declares no is_identifier, and the positionally-inferred identifier is an optional, unconstrained string.
Clean: darwin-core/1.0, dissco/0.4, ena/1.0, jerm/1.0, metabolights/1.0, miappe/1.1, miappe/1.2.
Why they were not fixed in place. Adding is_identifier to a released profile is classified BREAKING by compare_specs, so it would force a MAJOR bump on three shipped standards purely to record an identifier that inference already resolves to the same field. That is a deliberate decision to make, not a drive-by edit — hence this issue.
Options: (a) declare the markers and bump each profile's MAJOR version; (b) declare them and argue the comparator should treat 'declaring what inference already chose' as compatible — which would need the comparator to compute the inferred identifier, and is a real design question; (c) accept the advisories as documentation of a known weakness in those standards' own models.
Note the rule was already narrowed once to avoid noise: it exempts a field whose own name states identity (id, sample_id, locationID, database_identifier) and one pinned by pattern/enum/options/unique_within. Without that exemption it fired 25 times across 6 profiles, including all 13 dissco id fields, which are the right identifiers merely unmarked. name/title are deliberately not exempt — they state a display label, which is what the markers exist to keep separate from identity.