RE: Diagrams for VC HTTP API work [was Re: [AGENDA] VC HTTP API Work Item - August 17th 2021]

I started doodling with Archi this evening and created a simple ArchiMate model for Hollace Holder, an Actor, and his Holder Agent, and his Holder Wallet.
It’s simple but it’s an interesting start. 😊

Check out https://github.com/mwherman2000/VC-ARM/blob/main/README.md


Best regards,
Michael Herman
Far Left Self-Sovereignist

Self-Sovereign Blockchain Architect
Trusted Digital Web
Hyperonomy Digital Identity Lab
Parallelspace Corporation

[cid:image001.jpg@01D79605.EB839130]



From: Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>
Sent: August 18, 2021 5:53 AM
To: Joosten, H.J.M. (Rieks) <rieks.joosten@tno.nl>; Manu Sporny <msporny@digitalbazaar.com>; public-credentials@w3.org
Subject: Re: Diagrams for VC HTTP API work [was Re: [AGENDA] VC HTTP API Work Item - August 17th 2021]

+100
Archi is an excellent open source ArchiMate modeling tool. ...and very appropriate for a project like this:
https://www.archimatetool.com/

GitHub based multi-party collaboration is also supported.
The ArchiMate modeling language is also very well supported by several books and, of course, the excellent Open Group ArchiMate 3.1 specification: https<https://pubs.opengroup.org/architecture/archimate3-doc/>://pubs.opengroup.org/architecture/<https://pubs.opengroup.org/architecture/archimate3-doc/>archimate3<https://pubs.opengroup.org/architecture/archimate3-doc/>-doc/<https://pubs.opengroup.org/architecture/archimate3-doc/>
Lastly, I'm an Open Group ArchiMate (and TOGAF) certified enterprise architect and would love to help with this. I would likely end up doing this anyway for the Trusted Digital Web project.
Here's an interactive example where I modeled the entire Sovrin Glossary using ArchiMate: https<https://mwherman2000.github.io/sovrin-arm/>://mwherman2000.github.io/<https://mwherman2000.github.io/sovrin-arm/>sovrin<https://mwherman2000.github.io/sovrin-arm/>-arm/<https://mwherman2000.github.io/sovrin-arm/>
Here's another example where I modeled the entire Indy platform including the DID specification: https://mwherman2000.github.io/indy-arm/

Michael Herman
.
Get Outlook for Android<https://aka.ms/AAb9ysg>

________________________________
From: Joosten, H.J.M. (Rieks) <rieks.joosten@tno.nl<mailto:rieks.joosten@tno.nl>>
Sent: Wednesday, August 18, 2021 12:03:11 AM
To: Manu Sporny <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>>; public-credentials@w3.org<mailto:public-credentials@w3.org> <public-credentials@w3.org<mailto:public-credentials@w3.org>>
Subject: RE: Diagrams for VC HTTP API work [was Re: [AGENDA] VC HTTP API Work Item - August 17th 2021]

My guess is that the confusion comes from the inability of readers to determine whether or not their interpretation is in line with the intensions of the author(s). Enabling readers to do so is the first step (followed by discussions and ultimately reaching consensus).

Regarding the symbols in figures (rectangles, lines, arrows) it would help to either define their meaning, or stick to a meaning that is defined elsewhere, e.g. by UML, ArchiMate, or ... . Here 'sticking to' doesn't mean to simply use the various symbol, but to use them in the way that UML, ArchiMate or ... have actually specified them.

For words/terms this is the same. 'Simply' adding a criterion to a word/term that readers can use to determine whether or not something qualifies as a term enables them to understand what the authors intended. They do not necessarily have to agree, but in order to start a proper discussion, knowing that the participants can at least agree on (the meaning of) what is said seems a good basis to me.

The activity of creating such meanings and phrasing/drawing your 'messages' that are consistent therewith is an exercise that takes more time than an arbitrary hit-and-run activity. But this time is well spent as it prevents numerous future fruitless discussions, and it is work that needs to be done anyway if all this would ultimately need to end up in a standard.

Rieks

-----Original Message-----
From: Manu Sporny <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>>
Sent: dinsdag 17 augustus 2021 21:38
To: public-credentials@w3.org<mailto:public-credentials@w3.org>
Subject: Re: Diagrams for VC HTTP API work [was Re: [AGENDA] VC HTTP API Work Item - August 17th 2021]

On 8/16/21 5:16 PM, Joe Andrieu wrote:
> f. *Verifier Role* The website or software that uses a Verification
> Service as part of its decision making process for providing services
> to holders.

This is one of the things that threw me... "Role" and "Website" felt strange in the Communications diagram.

I get that the "Website is playing the Role of Verifier", but when I see a low-level component, like a "Verifier Service" communicating directly with a "Holder", it feels like a layer/terminology violation for some reason.

I do think the previous diagrams suffer from this same problem to a degree as
well:

https://docs.google.com/drawings/d/19wJSXTVabVpYJIv1b2hXPPpJ2mPlDkhyYnHylQFwE0Q/edit


It's hard to escape when you have two layers of detail in a single diagram.
Just making an observation, no idea how to make it better at present.

-- manu

--
Manu Sporny - https://www.linkedin.com/in/manusporny/

Founder/CEO - Digital Bazaar, Inc.
News: Digital Bazaar Announces New Case Studies (2021) https://www.digitalbazaar.com/



This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.