Define workflows as cited from VC-API

[OR13]

Example api that supports these query data models can be found here:

• https://api.did.actor/docs
• https://github.com/transmute-industries/api.did.actor

These data models are also under use here:

• https://w3id.org/traceability/interoperability

Mesur, Transmute and Mavennet have used them to exchange VPs in interoperability demos associated with presenting critical supply chain data to US and CA Customs agencies.

---

Preview | Diff

[msporny]

Thanks for the PR, @OR13 -- I agree that we need to define workflows somewhere. It's debatable where the proper location is. VPR itself is probably not the ideal place, and I agree that VC API might not be ideal either. VPR doesn't presume a protocol layer... VC API does, and workflows need a protocol layer to make sense.

I'm not saying the decision is clear, we'll need to discuss, but it's not immediately obvious that VPR is the right place to put this either. For example, in VPR we can suggest that "interact" is a mechanism that enables mediated and unmediated workflows... but until there is a protocol in play, it might be argued that it's strange to provide an example that's "at another layer".

Again, more food for thought than a clear suggestion that we do it one way or another. We might put it in both places for now (so people don't miss it) and then remove it from one place later on after it becomes more clear that the section is sticking out like a sore thumb.

In any case, I'm largely in agreement w/ the /structure/ of the PR. I do think it would be useful to show how a VPR might be used in a workflow. I'll provide more line by line commentary in a bit.

[msporny]

There are multiple change suggestions in here, I expect we'll have to spend some call time talking through them to understand how we get both of these world views aligned (or understand that they really are two different things, and document both of them).

Feedback implemented

[OR13]

@msporny I tried to clean this up so that we can make progress on future PRs from contributors who might have a "simpler use case".. however, just because the trace use case is hard to understand does not justify blocking using it for the first examples, especially given the current state of the spec.

Please re-review.

[msporny]

I'm good with this PR given the simplification in the examples and that there is an issue #14 for the concern I raised. It's not a traceability vs. education example thing... it's was just from a "sheer volume of text that the reader might think they need to understand" perspective. I just didn't want people to look at the complete example and think it was complicated because there was a lot of data there.

People might complain about the Traceability examples for different reasons now ("It's not a complete example, how dare you!")... but I'm good with waiting for someone to come along and complain about it (and maybe we'll get lucky and no one will complain about it).