Stream: implementers
Topic: Provenance with target = Bundle
Eric Haas (Aug 04 2020 at 23:39):
Just to make sure I understand how to transact a bundle with a provenance referencing it as a target ? -Use X-provenance or as transaction?
Lloyd McKenzie (Aug 04 2020 at 23:51):
Latter. I don't think something in the Bundle can reference the Bundle.
John Moehrke (Aug 05 2020 at 01:31):
The X-Provenance header could certainly be used on any POST/PUT to indicate the Provenance of the content of the POST/PUT. It is an X header, so does require that the server understands.
John Moehrke (Aug 05 2020 at 01:31):
what is the use-case you are trying to satisfy with a Provnance of a bundle?
Eric Haas (Aug 05 2020 at 03:29):
Forwarding a Message using $process-message. The Message bundle has been modified by an intermediary. Part of Notifications tracker and resolution. Scenario is Sent to intermediary - based on business rules and user agreements the Recipient is not forward some content ( in my example Coverage) so the intermediary forward the message less the Coverage. Hence the bundle has been modified . Prov on MessageHeader since that is updated and Prov on Bundle. A transaction would consist of the Message with POST to operation endpoint and Prov with POST.
So I am guessing both as well...
René Spronk (Aug 05 2020 at 06:47):
If the message has been modified, it's a new message, with a new id, and should show the intermediary as the sender. Provenance (contained within the message bundle) could indicate what the original sender was.
Eric Haas (Aug 05 2020 at 14:32):
Thanks @René Spronk That helps me with my use case. But in general if the the Provenance target is the Bundle can't point to the Bundle in the Bundle. Hence a Transaction or X-prov header Outside of it.
Vassil Peytchev (Aug 05 2020 at 16:09):
How do you plan to use a transaction? A transaction bundle with a message bundle inside it? While you can invoke operations from a transaction bundle, can you invoke "$process-message"?
Eric Haas (Aug 05 2020 at 18:31):
While you can invoke operations from a transaction bundle, can you invoke "$process-message"?
I assumed is possible. iI there a reason why you cannot? Is it explicitly prohibited.
René Spronk (Aug 06 2020 at 07:13):
@Eric Haas Sure, but the provenance could reference the MessageHeader resource. "This message is a transformed message as received from original source X"
Lloyd McKenzie (Aug 06 2020 at 14:42):
Pointing to the MessageHeader isn't really the same thing as pointing to the Bundle
John Moehrke (Aug 06 2020 at 15:40):
I expected that if a bundle needed to be persisted, that would be an exceptional case. One where one would capture the persisted Bundle in a Binary and create a DocumentReference to capture the metadata about that Binary(Bundle)
John Moehrke (Aug 06 2020 at 15:41):
This would give you an id and means of discovery
Eric Haas (Aug 06 2020 at 18:57):
@René Spronk Thanks again - that is much more practical solution and avoids the issue and extra burden of receivers having to suppor transactions and x-prov.
Lloyd McKenzie (Aug 06 2020 at 18:59):
But it doesn't actually say what you want to say... A Provenance pointing at the MessageHeader says the header has changed. It doesn't say anything at all about the other resources. (Though I guess you could have the Provenance point at ALL of the resources in the Bundle. That would cover everything except the elements that appears only on the Bundle...)
René Spronk (Aug 07 2020 at 14:54):
Depends on the level of tracing one requires. If it's only "this message is modified version of a message originally by system X" then having a provenance associated with the MessageHeader suffices. The use case (as I recall) was for the intermediary to remove some financial resources from the message.
Lloyd McKenzie (Aug 07 2020 at 15:31):
Provenance tied to Messageheader doesn't tell you that the message was modified, only that the MessageHeader was modified.
Vassil Peytchev (Aug 07 2020 at 17:05):
Just to make sure I understand how this latest suggestion is supposed to work:
- A message bundle is sent from source to intermediary
- Intermediary removes one or more entries from the original bundle, and creates a new message bundle (new
Bundle.idand newMessageHeader.id) - The new message bundle contains an extra Provenance resource pointing to either MessageHeader (René) or to MessageHeader and all other entries in the new message (Lloyd).
Is that right? Will the provenance resource have enough useful information?
Lloyd McKenzie (Aug 07 2020 at 17:08):
If the Provenance is about stuff that's been stripped from the message, there's no way to express that in a Provenance that just points to resources in the Bundle. To cover that, the Provenance would have to point to the Bundle - which means that it would have to be in the header, given that you can't point to a Bundle from something inside it - at least not right now.
John Moehrke (Aug 07 2020 at 17:24):
the Provenance can point (.entity) at elements removed (.entity.role = removal)
John Moehrke (Aug 07 2020 at 17:25):
the Provenance.target is the output of the activity, the .entity is the input to that activity. the .entity.role is how that input was used in the activity
John Moehrke (Aug 07 2020 at 17:27):
Very exhaustive detail can be recorded in Provenance. not clear to me why one would want to record this exhaustive detail, but we did design Provenance to be able to do it.
Vassil Peytchev (Aug 07 2020 at 17:42):
Provenance.entity.what is Reference(Any). If the removal of entries needs to be recorded, then it seems to me that an identifier would be required in this case, as there is no URL to point to resources in the original message. Will all removed resources have a identifier? Or do you have to require that the entry.fullURL is resolvable, in which case you can use a reference?
Based on the above, it seems to me that recording what was removed is way too involved and likely not necessary. Which leaves the other interpretation that the "new message" needs to indicate that a) it was changed from the original, and b) the original was authored by Z
Does that sound right?
Lloyd McKenzie (Aug 07 2020 at 18:03):
@John Moehrke How can Provenance point at entities that have no identify outside the message they've now been removed from?
Lloyd McKenzie (Aug 07 2020 at 18:03):
Can multiple provenances be sent in the header?
John Moehrke (Aug 07 2020 at 19:05):
if no id or identity is known, it can always be recorded as .entity.what.display -- okay, not a very satisfying answer. but I am not clear on what is trying to be accomplished. Provenance is not a journaling-database. If there is a need for a GIT like change tracking, then use GIT.
Eric Haas (Aug 12 2020 at 22:37):
So I've done a simulation here that forwards a message based on this discussion and guidance from US Core. Thanks for the feedback:
http://ehaas.pythonanywhere.com/
Last updated: Apr 12 2022 at 19:14 UTC
