Report of Technical Committee In-Person Meeting

Date: 1-5 August 2022

Attendees 

Wendy Thomas, Jon Johnson, Ingo Barkow, Oliver Hopt, Darren Bell, Dan Smith, Jeremy Iverson, Flavio Rizzolo (remote), and George Alter (remote)

Agenda

  • COGS DDI Lifecycle 3.3 input

    • Review of Current status of COGS input to CSV files

    • Goals of COGS work: serialization, automation, multiple implementations

    • Documentation of input process: assumptions, processes, edits, modification of schema prior to input

    • Documentation of output process: injection of content, variations for different implementations

  • COGS output for DDI Lifecycle 3.4 (structural revision) 

  • Technical Committee role and activities in new organizational structure and multi-product environment

    • Pre-discussion for TC future session - clarification of current organizational structure and issues

    • TC future - next 5 years; working relationship with SB, membership, leadership

    • Listing of specific activities required prior to review - assignment and timing of tasks

  • Review of DDI Lifecycle 3.4 (or 4.0)

    • Approach for review - how to set up, what to ask for, capturing input, iterative process (roll out implementation languages as completed)

  • DDI Lifecycle process workflow using COGS (business process/rules)

    • Documentation of development process once content is in COGS - review SDTL process

Discussion Points and Decisions

DDI Lifecycle in COGS

Discussion:

We resolved a set of XML Edit issues (14), Bugs (6), and special case/hard coded cases (16) were checked and verified. We identified 11 schema changes to be made in COGS and completed 4 of these. A total of 9 issues were filed and completed regarding the COGS repository and 3 future issues for DDI Lifecycle were identified and filed. 

The group reviewed the COGS generated documentation including a review of the Topic categories and the presentation of content. Suggestions were made regarding Topic categories and how items were distributed within each (allow for listing in multiple topics and provide an option for an alphabetical listing of all items). Changes in the page content for the use of items (example: Agent used by Citation/Creator/Agent) allowing for increased path depth and changes in the content of the image of an item and its relationships. Discussed the integration of former high level document content into the Sphinx documentation, retaining Best Practices materials as official documents external to the product package. The materials in the product package should be stable.

Decisions:

  • Documentation of the review content should include a statement of DDI Lifecycle Production Pipeline Goals and Rational (see Appendix 1)

  • Include readme documentation from COGS with links to fuller material

  • Retain and note differences between the published DDI Lifecycle Version 3.3 and the material in COGS 

    • Handling of xs:choice objects

    • Expansion of Managed Representations to include all representations

    • Compiling of multiple Record Layout types found in different schema to a single schema with name differentiated Record Layout types

    • Other

  • Tone and content should reflect the change from a schema based to model based

    • Explanation of how to use and interpret the documentation

    • Functionally focused

    • Some things like identification, grouping etc. need spelling out

  • Identified as short list of changes to be made in the COGS Sphinx output

  • Identified a list of articles to include in the Sphinx documentation (in addition to the field level documentation) 

Technical Committee role and activities

Discussion:

The recent reorganization of the Scientific Board, the growth in the number of work products of the Alliance and the need for a succession plan for TC officers prompted a preliminary discussion on the focus of the TC and the way it could function effectively in the medium to long term. Associated with this is the desire to have a more consistent way of working and communicating across the active work products so that the TC has a better technical overview of the growing suite of products. 

The discussion took place in two sessions, a background session to look at the broader environment of the Technical Committee followed by a session discussing specific actions the Technical Committee can take and the focus of the committee over the next year.

Decisions

The current definition of the Technical Committee is still workable. The issues facing the Technical Committee seem to be more in terms of focus, in particular the management of development and product maintenance over the long term as opposed to the detailed management of Lifecycle and Codebook. With the current number of products that need to work together and be maintained over time, we need a better model for our overall work processes.

The Technical Committee will start a review of its overall work processes to think about a recommendation for process changes, especially If this would result in a shift in the Technical Committees focus. 

The TC will bring forward proposals on new ways of working and, if necessary, will bring a proposal to the Scientific Board to create a temporary working group to work on any necessary bylaw changes. Currently there does not seem to be a need for this.

  • There is a special relationship between the Technical Committee and the working groups that focus on the development and maintenance of the DDI products. There needs to be set of guidelines for these working groups so that new areas of content coverage (as opposed to application coverage) arise, that the content is reflected in the appropriate products in a coordinated way.

  • Lifecycle and Codebook development and maintenance has traditionally been handled directly by the Technical Committee. Recent Codebook work has been done by a temporary group. Management of these two products will be reviewed and recommendations put forward to how this should be handled in the future.

  • The role of oversight and coordination has expanded and is focusing more on devops as well as content coordination. The details of this need to be determined.

Role of the Technical Committee (DDI Alliance Bylaws)

The purpose of the Technical Committee is to model, render, maintain, and update the DDI specifications to meet community needs and align with Alliance strategic goals. The TC receives input from substantive working groups of the Scientific Board, DDI users and developers, and other interested parties. This includes the development of conceptual models, implementation of models in various technical forms, monitoring the metadata landscape and related developments, and initiate and plan possible future directions for the standard.

Activity Areas

  • Platform designation - management

  • Making sure the whole thing works - across all products

  • Cross Product- Roadmap/Programme management and monitoring

  • Product standards assessment and compliance <> product maturity levels

    • What should be common across products (such as identification, use of controlled vocabularies, other?)

    • Common areas of application/use of specification languages

    • Clear roadmaps to keep better alignment and to keep all informed of product work

    • Applications supported by different products - intended focus of each

    • Overall content coverage of DDI Suite

  • Requirements management for development products

    • Recording

    • Tracking

    • Integration with products

  • Tools management

  • Overall content coverage 

    • In or out of DDI

    • What goes in which products

    • What is a new product

  • Product related work

    • Lifecycle

    • Codebook

    • Controlled Vocabularies

    • XKOS

    • SDTL

    • CDI

  • Training Group

  • Paradata Working Group (topical coverage not related to a specific product)

  • Review and publication of products and technical documents

  • Approval process at various levels

    • Executive Committee

    • Scientific Board

    • Technical Committee - within the realm of their remit