Re: 7th August: DIDWG Special Topic Call - Abstract Data Model

 Hi all,

We had our first special topic call earlier today. The chairs made a
last-minute decision to not scribe these calls, and treat them as an avenue
for informal discussion, with no ability to make resolutions or impactful
decisions. Given the comments made by some working group members on today’s
call we realize this was a mistake. Going forward we will treat special
topic calls similar to regular calls, with scribing.

I did take (rough) notes during the meeting, which you can find below. I
added some editorialization and stripped away who said what. I believe the
notes capture the essence of the conversation. Please reply with
corrections as you see fit.

———

*Topic: Abstract Data Model (ADM) Discussion*

*Background and Context*
- The discussion centered around the use of the Abstract Data Model (ADM)
in DIDs, its origins, and current relevance.
- Historical context: XML was initially used, then JSON-LD became popular.
Concepts were extracted to create an abstract data model.
- The term "representations" was preferred over "serializations" to avoid
implying a precise ordering.
- Noting that the VCDM v1.1 supported multiple syntaxes (plain JSON and
JSON-LD).

*Key Points of Discussion*

*1. Reasons for Implementing ADM*
- Addresses preferences between JSON and JSON-LD (e.g., optional context).
- Enables lossless conversion between different representations.
- Aims to facilitate understanding of DID resolution.

*2. Current State and Concerns*
- Significant work has been invested in the ADM.
- No known major implementation problems.
- Questions raised about the necessity and benefits of ADM today.

*3. Practical Considerations*
- Interoperability between different representations.
- Extensibility concerns, especially regarding JSON-LD contextualization.
- Potential for a common representation for resolution.


*4. Implementation and Testing*
- Translation between formats was not trivial; ADM provided a common ground.
- Test suites currently use concrete serializations for testing.
- Suggestion to keep ADM but have a concrete representation for resolution.

*5. Extensibility and Internationalization*
- JSON-LD offers a story for extensibility and internationalization.
- Concerns about potential conflicts as technology scales.
- Discussion on the registry model for term extension.

*6. Future Considerations*
- Potential for simplifying resolution by removing the distinction between
[production and consumption representations](
https://www.w3.org/TR/did-core/#production-and-consumption).
- Need to consider impact on existing implementations before making changes.
- Suggestion to focus on necessary data representations for
interoperability.
- Perhaps a path forward -- keep the ADM, but define a concrete
representation necessary for interoperability with Resolution.

*Action Items and Next Steps*
1. Clarify the definition and purpose of ADM for better understanding. It
is confusing to newcomers and implementers.
2. Gather feedback from implementers on the usefulness and impact of ADM.
3. Consider the possibility of maintaining ADM while introducing a concrete
media type for resolution. Focus on what issues may arise during specifying
resolution.
4. Evaluate the potential impact of any changes on existing implementations.
5. Further discuss the balance between theoretical work and practical
implementation concerns.

*Additional Notes*
- The group acknowledged the recurring nature of discussions around Linked
Data (LD) and expressed a desire to move forward.
- There was a reminder that implementers are not required to register
terms/properties in the registry, but specifiers are encouraged to do so.
- The group recognized the need for caution when considering significant
changes to the existing model.
- The group acknowledge the political, and not purely technical nature
around the ADM. Maintaining the ADM may serve a great political purpose
than a technical one.


On Jul 26, 2024 at 8:25:18 AM, Will Abramson <will@legreq.com> wrote:

> Hi all,
>
> Just following up from our call yesterday.
>
> Our first special topic call will be on the 7th of August at 7am PST/ 10am
> EST / 4pm CET.
>
> We are going to focus on the abstract data model. See the following issue
> - https://github.com/w3c/did-core/issues/855.
>
> We are asking for proposals for presentations from people that provide an
> overview of the abstract data model. What is it? How does it work? Why did
> we choose the abstract data model in v1? What are the trade offs vs a
> concrete model? What are the possible directions and decisions the group
> could explore? What are the implications on other aspects of the work, e.g.
> DID Resolution?
>
> In particular, if you have experience using the abstract data model we
> would like to hear from you.
>
> The aim of this call is to set the scene and context for this issue, so we
> can have meaningful discussions that advance the work.
>
> Please reach out to the chairs *by Thursday the 1st* if you think you
> have something to contribute that will help us move this work forward.
>
> All the best,
> Will
>
>
>
>
>