A PROV document with two relations that share an identifier but carry different formal attributes (e.g. two generations both identified ex:gen1 with different prov:time values) is valid PROV-DM, but cannot round-trip through PROV-O/RDF.
Both times serialize onto the single qualified IRI, and on deserialization the decoder rebuilds one record and rejects the second value with ProvException: Cannot have more than one value for attribute prov:time.
Decision needed for 3.0: should the RDF serializer mint distinct IRIs per relation (making these round-trippable), or is this an accepted PROV-O representational limitation to document?
Tracks the 14 test_scruffy_* round-trip cases in src/prov/tests/test_rdf.py, which the Phase 3 test-suite redesign converts from bare unittest.expectedFailure to skip-with-reason referencing this issue (per maintainer decision). Root-cause analysis in docs/superpowers/specs/2026-07-06-test-suite-redesign.md.
A PROV document with two relations that share an identifier but carry different formal attributes (e.g. two generations both identified
ex:gen1with differentprov:timevalues) is valid PROV-DM, but cannot round-trip through PROV-O/RDF.Both times serialize onto the single qualified IRI, and on deserialization the decoder rebuilds one record and rejects the second value with
ProvException: Cannot have more than one value for attribute prov:time.Decision needed for 3.0: should the RDF serializer mint distinct IRIs per relation (making these round-trippable), or is this an accepted PROV-O representational limitation to document?
Tracks the 14
test_scruffy_*round-trip cases insrc/prov/tests/test_rdf.py, which the Phase 3 test-suite redesign converts from bareunittest.expectedFailuretoskip-with-reason referencing this issue (per maintainer decision). Root-cause analysis indocs/superpowers/specs/2026-07-06-test-suite-redesign.md.