TC Meeting Minutes

ATTENDEES: Wendy, Darren, Oliver, Dan, Flavio

Web pages/ site plan
https://docs.google.com/spreadsheets/d/1bcvxmwoxUWyhZfTkuR9ZrVtmCxz2mkE8cFYYyjpCLtM/edit?usp=sharing
From Jared:
What would be useful is to make a final decision whether the Technical Committee is committing to supporting the website infrastructure or if we should go with the vendor. If the former, will you support all functionality currently on the site or just portions? At a minimum, I need a place to post announcements, manage a membership list, and manage/edit all pages other than the /specification sections.
There's other functionality on the site, like the Bibliography or the Glossary or the Tools list that are nice but maybe could be hosted separately. Those are also decisions we'll need to make.

Discussion:

• Could support static or file content in something like S3 buckets

• COGS stuff could be bundled up as static content and hosted on docs.ddialliance.org

• Don't forsee any major problems in doing a serverless website that looks nice and bounces over to an object storage

• Could do a test migration in July during a 2-day meeting

• Can set up S3 buckets to test

• Tools etc. could be a non-database filter system

• Hotspot has the management system build into it that should support Jared's editing needs

• TC taking this on would save the transfer fees of the outside vendor. We would need to look at ongoing maintenance. Zero risk as we can build this as a parallel system this summer, test it out, and institute further changes following that.

• Do need to make sure we have document and project page organization determined so that new products and versions can be assured of URL consistency for linking purposes

ACTION: Darren will write to Jared

Scientific Board Plan
Clarified a few points. Will get final draft for tomorrow

CV publication

• Basically there

• DevOps team at Michigan have made the changes they needed to make

• Working with CV group to update static content on pages

• Problem of duplicate language (again) in the HTML

• CESSDA is not seeing the problem - if they won't fix we could filter out duplicates as an interim response

• Darren plans to go live the week after IASSIST if this works with the CV group

• Meeting on Monday to finalize the ontoloty access

• Oliver has discovered source of duplication: CESSDA has put an all of the versions together because they use a select bar. The Rest API ends up with 2 versions of both

• We could switch to this display but it may be complex for the user

• The CESSDA change dropped out some of our requirements - do we drop our requirements or ask them to make the change. We don't want what has come out with multiple versions (different versions) in different languages.

• We are concerned with the RDF version and we need to go live with this. The HTML is still a problem

Codebook outstanding issues
DDICODE-93
DDICODE-95
DDICODE-97

Darren will look at these

Presentation on DDI-L .v4.0BETA - who presents
Will sort this out off-line

Future agenda:
Chair, Vice-chair (3 year term)

ATTENDEES: Wendy, Jon, Darren, Dan, Jeremy

Web pages -

General:

• Want to control the website and not have it jobbed out

• There is static content that could be usable but not necessarily optimal

• Get it over and done and implemented and then think of the redesign

• Need to get basics done first (lift and shift)

• Opportunity to move to keep it simple then talk to groups involved (Training, TC, Publications)

Products:

• Putting up stuff around infrastructure and pipelines

• Top level URLs for the products will be hard coded or redirected

• If CDI has specific requirements they need to write them down

• This seems the obvious stuff to write this down

Document site:

• Timing of when we are going to split the document move to doc site

• Identification of documents should be part of the new site map

• Do we retain the static pages as just the publications and say the docs are over there (old docs)

• A page for product on the site but all in-depth documentation on the doc site

• Useful to have a profile of what goes on the doc site for future additions and help to groups in identifying what goes where

ACTION ITEMS:

• Darren and Jon will draft up a basic skeleton of the site map to kick against

• Add to next weeks agenda

• Known static content changes should be made before TC f-to-f meeting (ACTION: Wendy)

TC report to SB
Comments noted on draft

Update on current review work
I will continue to send reminders to reviews of both products during the review period

• Glossary List

  • Review underway

  • Several volunteers from Training Committee

• DDI-CDI Production:

  • Plans for sustainability of the standard; once its done in EA what is the pipeline (Jon will relook at the documents)

  • Olof - JSON

  • Pascal will begin in early June, may need extension

  • Dan - RDF output, looking primarily to see how they were transforming UML into RDF; special semantic relationships like traces in UML to identify patterns - how is this translated to canonical UML and then to syntaxes (are these just there to support their development of the model? this should be clarified)

Codebook (please look at before next week)

DDICODE-93 License - more detailed values for type attribute
DDICODE-95 https://ddi-alliance.atlassian.net/browse/DDICODE-95 deprecation - URI attributes needed
DDICODE-97 move license element to useStmt

ATTENDEES: Wendy, Jon, Oliver, Dan, Jeremy, Flavio, Christophe, Olof
APOLOGIES: Darren

Scientific Board Strategic Plan

[note Flavio and Dan are elected members on the SB. Wendy is ex-officio]
Flavio noted a couple of issues he'd already added
"horizon scanning capability"
"more robust" more of a clear source of truth

1.4 W3C and explore - RDF representation preparation in 2024 - why would we want to give away the variable cascade to another organization
Increase visibility, not "give away" needs to be more explicit

1.6 no date so when is this supposed to be worked on? non-open source like Colectica - what does it mean? The notion that we are working with commercial vendors and make no mention of those we currently work with. What exactly are we trying to develop? Work with related software (analysis tools) regarding input/output support?

2.2 we don't have an activity defined as such, what is in 2024? Clarify what this is mean here? architecture of content or of repository. Starting when?

2.3 addition of SDMX and HLG to this group specifically or as part of whole DDI interoperability. What do we mean by this in terms of organizational level?

2.4 The example is about domains not geographies but domain areas. Awkward, examples do not relate to geographies.

2.5 Progress toward ISO certification (we started, why is this 2025? What is meant by progress. More details - contact continuation, paperwork,

GENERAL: of strategic plan to prioritize and focus work on specific areas. Concern there is too much for too many. Who is going to do this.

3.1 TC is working on in terms of organizing documents and publication

3.2 difference between 3.2 and 3.4?
Maybe some collapse into a broader infrastructure for development, management, presentation

GENERAL: Verbiage is abstract making it difficult to differentiate and make sure that different aspects are identified as sub-bullets

Omitted support of DDI Codebook 2.6

3.8 don't understand what this means (modularity within a product), but between products? Why is the example is a provenance model.

Discussion on user mailing list (conceptual, and reference variable) was the actual issue we would face with 3.8. things differ between products and there are different implementations in various products. Need for metamodel to understand what is found in multiple products, but varying implementation. Example of metamodels (Groups).

Need both metamodel to understand differences, and in some areas a single mullti-use content.

Suggestions in the scientific model that haven't been discussed. They seem to be arising from a minimum number of sources

"Let's do a provenance model" opens up a can of worms. No background discussion. There is a process raising topical rears and pursuing their development across products in one way or another.

HOLES?: Lack of content regarding how to use DDI suite together. (maybe related to 2.6) maybe expand to include 2024?

ACTION:

• Wendy will add notes to document

• Start list of content for report, next year priorities for TC; send out to get comments before next week

ATTENDEES: Wendy, Jon, Darren, Dan, Christophe, Jeremy
APOLOGIES: Flavio, Oliver

Newsletter submission
Thank you for XKOS work on publication process
Alert people to recording on Lifecycle 4.0 BETA and continuing work

TC report to Scientific Board
Web page support through AWL
Infrastructure
Codebook
CDI review
4.0 BETA continue to finalization

Glossary Group document publication
TC to look at in terms of technical review
Check in Glossary that its DDI
Hayley get a few Training people to look at
Christophe will talk with INSEE folks regarding clarity
Month deadline

https://ddi-alliance.atlassian.net/wiki/spaces/DDI4/pages/2790359041

DDI Lifecycle github issue

Rather than think of the specific item raised here
What is the purpose of the represented variable
If its available it should be in represented variable
there is a difference between practical use cases which might not be the dominant ones
Issue is primarily around missing values and problems of how coding or options change from capture through processing to instance and physical store differences
Currently clear change from represented to instance is going from universe to population (spatial temporal specifications)
Different sorts of data throw up different problems
One of the strengths of the schema it is quite directional (this can also)

ACTION: Wendy enter this discussion on #38 (DONE); others should add comments on role of RepresentedVariable or other points as needed

NEWS:
Guillaume is returning come September

ATTENDEES: Wendy, Jon, Darren, Flavio, Dan, Oliver, Christophe, Jared, Jeremy

1. AWS and Drupal site interaction and support
   Recap: some sections will move to AWS (specifications) remaining will be moved to wordpress
   Is it wise to split this down the middle and move to 2 sites. This might be difficult to split correctly and to maintain in the future.

--Is it possible to move everything to AWS? How complex might this be to maintain and supervise
--Need to move away from Drupel as it is not supported by ICPSR and want to move it to a vendor
--Fee for moving it over and an annual maintenance amount ($3-4,000 a year)
--Urgency because support for their version of Drupal had gone away, did get year's reprieve
--In the mean time the AWS option arose and discussion of how
--Lots of static content that would just be moved
--Some functinality - bibliography that is maintained in an ongoing basis; posting news etc.
--Happy if it did not got to vendor
--Can we support on-going posting and maintenance
--If not, we can still go to WordPress keeping basic content there and other on AWS

Current view of what goes to AWS:
(1) Content under the following virtual URLs will be moved to the new UMich AWS instance
 https://ddialliance.org/Specification/* - static content
 https://ddialliance.org/products/* - static content
 - single static web page
 - single static web page
 - single static web page with filter
o Also move relevant referenced items under https://ddialliance.org/tool/*

o Also move relevant referenced items under https://ddialliance.org/sites/default/files/*
 At the root level under .
o https://ddialliance.org/Tables.dtd - downloadable document

--Clean up even before vendor
--Hidden stuff would not move and Darren's list may include that

--Splitting may have unintended consiquenses such as loss of database functions (publications, examples, etc.)
--Do we need all the functionality that is there (examples etc.) - if we add in with the vendor

--Would the options we are looking support these

--Issue about having to shadow the brand and sync it between 2 sites and with a 3rd party vendor

--What potential costs there would be with backup etc. - there is still need for web support (not completely volunteer)

--It seems to me that we are missing a written target sitemap (whether we have one or two platforms) that would guide the specifics of the migration.

--Could we take a few weeks out to design what we want the site to look like
Include Training Group
We have a current website that needs a spring clean but we have no idea what it should look like
Can we take 4 weeks to say this is where we want to end up (google doc) - we don't have much written down on this at the moment
Drupal to WordPress is somewhat automated there is also a lot of sorting and hand work to make the move.

Lists out the sections and owner groups
Detail gets complex in the products sections
Resources has some sections
What exactly do we have - can we flatten it out?
ACTION:
We should look at what we want rather than just what we have
Create small group to look at this: Jared(co), Jon, Darren (co), Wendy

2. CDI technical review kickoff
   Flavio looked at it
   No draft of production process review issues - get from Arofan (send him a draft of request and list of people we've identified)
   Automation is still lacking so how is that evaluated
   We did write to them some time ago regarding - dig out letter we sent to them and verify all the parts are there
   Asking more information on production process itself; make sure its available
   Jon will look next Friday

3. Funding requests
   see google sheet:

4. Workplan for coming year
   Review workplan for tweaks

5. Updates on feedback for DDI LIFECYCLE V.4.0 BETA
   No only had one piece of feedback from Romain
   BETA 2 would be good to do when we have the ordered flags