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

I suggest you call the language ASN2.

thx ..Tom (mobile)

On Wed, Aug 7, 2024, 6:13 PM Gabe Cohen <gabe@tbd.email> wrote:

> 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
>>
>>
>>
>>
>>