GA4GH Data Models and Schema Consensus Study Group (DaMaSC)

Minutes and Actions 2022-2023

Table of Contents

Overview

Links to Archived Meeting Minutes

Meeting Protocols

List of Meetings

2023-07-05

Discussion

2023-05-16

2023-05-16

2023-02-09

2023-01-12

2022-11-10 - Dropped

2022-10-13

2022-08-11

2022-07-14

2022-06-09

2022-05-12

END OF DOCUMENT

Overview

These are the minutes and actions for the Data Models and Schema Consensus (DaMaSC) Study Group Meeting as part of the GA4GH Discovery Work Stream.

To be inclusive across the globe, we will meet at alternating times:

• 3rd Monday of the month at 3pm GMT  in even numbered months (June, August, …)

• 7am PT / 10am ET / 12:00am AET

• 3rd Tuesday of the month at 9pm GMT  in odd numbered months (May, July, …)

• 1pm PT /  4pm ET /  6am AET

Participation in these groups is open but requires adherence to the GA4GH Standards for Professional Conduct.

Meeting Protocols

• Please note that by participating in meetings, attendees agree to adhere to the GA4GH Standards of Professional Conduct
• Meetings may be recorded for note-taking purposes. Recordings will be deleted within three months of the meeting taking place.

Useful Links

• Archived Meetings
• Schema Registry/Library Examples

• https://docs.confluent.io/platform/current/schema-registry/index.html
• https://www.crossref.org/documentation/schema-library/
• https://schemablocks.org
• http://schema.databio.org/ (Nathan)
• https://bioschemas.org

List of Meetings

2023-07-05

Attendees (Affiliation):

Discussion

2023-05-16

Attendees (Affiliation): Kathy Reinold, Beatrice Amos, Nara Sobreira, Michael Baudis

2023-05-16

Attendees (Affiliation): Kathy Reinold, Ian Fore, Alex Wagner, Beatrice Amos

Actions

Minutes

2023-02-09

Very brief meeting

Attendees (Affiliation): Amreen, Kathy Reinold, Robert Freimuth

Actions

2023-01-12

Attendees (Affiliation): Yash Puligundla (GA4GH), Fabio Liberante (GA4GH), Robert Freimuth, Heidi Sofia, Jeremy Adams (DNAstack),

Actions

Minutes

JA: Schema sharing in a network vs harmonization. 3 conversations.

RF: Having a concrete goal to work towards helps in person sessions be more productive.

2022-11-10 - Dropped

Attendees (Affiliation):

Actions

Info/Links

Minutes

2022-10-13

Attendees (Affiliation): Alex Wagner, Michael Baudis, Kathy Reinold, Robert Freimuth, Yash Puligundla,

Actions

Info/Links

https://www.enfogroup.com/blogs/master-data-model-vs-information-model

https://blog.softwaresuperglue.com/2018/11/09/information-model-vs-data-model/

https://en.wikipedia.org/wiki/Information_model#Overview

https://www.ietf.org/proceedings/86/slides/slides-86-i2rs-3.pdf

Minutes

Agenda 1. - Connect workshop sessions?

DaMaSC - Computable Cohort representation joint session?

AW: 30th November - Maturity Model versioning meeting. Coincide with Connect sessions?

Agenda 2. - Terminology

Information

Data

Logical

Physical

Technical

Conceptual

Schema

Reference

Agenda 3. - Outreach - other perspectives

AW: Nobody in mind beyond who is already involved.

MB: Other Schema registries.

[...]

KR: What is it we’re recommending here? We need to put a stake in the ground. SB?

AW: Strong proposals. But an actual discussion in a public forum. Connect session.

KR: +1. More wording around SchemaBlocks proposal?

MB: Plan would be the Tech Team working on this.

MB: Proposal for Fabio to draft and circulate with this group.

KR: Second thing is a little different. I should articulate the idea behind the Data Model and Metadata Model. Tell us what the objects are. Then SchemaBlocks underneath. I will draft something.

RF: +1

MB: VRS Q. Has a whole ecosystem. Needs a home. What’s your thinking?

AW: GK pilot dataset - split out conceptual domains for the classes we needed. Shared concerns and class inheritance issues. Ended up with core schema and shared data classes. Abstract model can be inherited. Metaschema document - tooling to generate from these. Policy and ownership - who’s responsible for updating these models? Part of 30th November discussion. Need a process to get async development.

MB (in chat): Same in Beacon - we separate framework & models, but they inherit stuff... which live mostly in the framework

MB: This should be a principle for GA4GH broadly. Oversight from a body that lives in GA4GH.

RF in chat: Agree w/ Alex re: the questions that remain and ideas for future. Both persist, and have for a while.

AW: Draft ideas, as a starting ground for iteration and be governed by GA4GH.

MB: Local copy of frozen version for stability. Problem is having large groups of people is you find a solution, but it’s not optimal.

AW: Locally optimal - gradient descent and iterate on it.

MB (in chat): https://toddlohenry.files.wordpress.com/2012/09/hegel2.jpg?w=768&h=850

https://toddlohenry.files.wordpress.com/2012/09/hegel2.jpg?w=768&h=850

https://toaredplanet.com/index.php/2020/02/08/conflict-is-necessary-hegel/

(random Hegel etc...)

RF: Generally agree with what’s been said. My position is known.

AW: Ideas for Connect proposal?

RF: Happy to contribute feedback.

RF: Central repo of shared objects makes sense. Small object vs. Data Model. Two main issues, culture and policy. We do not have a culture where we discuss shared models across the community. The idea of creating models that can be adopted by others will have limited uptake. Governance level - we don’t want to be responsible for developing and maintaining infrastructure. How does tha wht fit with a concept of what we’re discussing here? Is that in scope or not? Mandate or expectations: unless there is an expectation at all levels that we are committed to interoperability and open data sharing - pain of harmonization across projects. Volunteer effort - owner of that model.

MB: Who is going there? Assumption was people come and do and then someone takes over. More practical question.

KR: Build it and they will come.

KR: Leaving Broad Oct 21st. Plan to stay in GA4GH.

KR: Initiate a conversation about both - but present both proposals. And their reasons. Focus on SchemaBlocks. Slides and proposal draft document. Separate proposal documents.  

MB: VRS ecosystem presented technical need for Schemas and Standards that intersect. Plenary VRS presentation - reference these slides.

AW: Intro - high level - what is a Schema Registry? How does this help? Why people are there? 20-30 minutes. Work through proposals. The need and solution.

RF (in chat): Shared meaning on terms we use often certainly won't hurt. I'm not sure we need to reinvent much, though.

AW: Where are the proposals?

KR: Google Drive folder?

2022-08-11

Attendees (Affiliation): Lindsay Smith (GA4GH), Fabio Liberante (GA4GH), Nathan Sheffield, Michael Baudis (), Larry Babb, Kathy Reinold

Actions

Info/Links

Minutes

LB: What’s the elevator pitch?

MB: SchemaBlocks - more of a documentation of how to express entities. Would have been better for TASC to provide stable endpoints for VRS/CURIE etc. This wasn’t developed in this direction. However, we need libraries for mappings. Rescoping again. Recently pulled SchemaBlocks back - more manual - just put your subschema, not data models. If you want something, just put it there.

LB: +1 for slimming it down. My first question - what’s the governance? Is this a GA4GH intiative? Who’s maintaining it? Just you MB?

MB: Me and others. For years people have talked about this.

LB: You need people. But what are the policies for governance or criteria submitting to this?

MB: Central space that leads to things. Still offers an entry point. Separate to data model library.

LS: Want feedback on Pedigree standard. Relevant to this group and reusing things. Do we need a standalone model, Phenopackets/FHIR? Didn’t want to remodel again. Documentation is how to implement in the context of FHIR or Phenopackets etc. Towards the end - maybe we did need to have a standalone solid form? But again something you have to convert between. Was this a good choice? Open to the group. Not mutually exclusive options. What is the best choice for interoperability?

AW: Probably best to have a formal model that is importable. You should always start with a informational model, but having a schema to play with. Falls short of a specification. Decisions of how data model could actually

LS: If we push Phenopackets, would that solve it?

AW: Not what I mean. You have individual defined elements, but in JSON or Protobuff. Not just particular standards that exist.

KR: Totally with you. A conceptual model is what I call a data model. Phenopackets is a schema implementation of a data model. I disagree slightly with AW. A JSON would be an example implementation of a concept.

MB (in chat): Also you cannot easily point to Phenopackets since Protobuf...

MB (in chat): Reference implementation.

KR (in chat): Reference schema.

AW: Info model and data model - typed data entities within the model. Concept of an ID and it’s required. Data model - ID is a CURIE. You might make different choices.

LS: There wasn’t a need initially.

From Larry Babb to Everyone 02:30 PM

are the examples in the pedigree RTD all based on strictly on the phenopackets schema? and if so does it demonstrate the mapping back to the information model elements so that it's clear how Phenopackets relates to the info model?

From Lindsay Smith to Everyone 02:31 PM

We have a rough mapping between models here: https://docs.google.com/document/d/1GQRd5jeZeB5qhHclLZxDe6kPD173bXWGYlTsmCbTeuI/edit 

From Kathy Reinold, Broad Institute to Everyone 02:31 PM

+1

From Larry Babb to Everyone 02:31 PM

primary and foreign keys)

AW: A minimum information standard. Different to a data specification.

KR (in chat): Hmm need to think about the primary and foreign keys part -- sounds like a relational database implementation rather than a model.  thinking ...

LB (in chat): essentially, the pk/fk associations should be clear via the associations between entities and their cardinality

LS: Do they go ahead or pause?

MB: Original question is whether we need another model? Solidify this by going all the way. Challenges to the structure and preconceived notions. Somethings cannot be expressed technically.

NS: Comment. Not sure I understand the differences in how people. More broad way of thinking. Maybe that’s all you needed at that point, this was a bridge. More useful is when you actually specify what exactly is the thing. AW - Data Model. Will eventually become necessary for someone at some point in analysing data by someone. A library of reusable models is where the effo

LB: Nathan nailed how confusing how this is. Case Study - AW and I have been working for an enormous amount of time of VRS. Everyone is attached to their models, willingness to change drops. Matt Brush on the other side and building landscape analysis for pathogen response statements leveraging our VRS. Academic world over here. Three attributes predicate, object, subject. It needs to transparent to human beings. RDF semantic thing. We need to be able to show clearly where this variant maps to. Semantically if we all come back to the same model it will make it easier. Can’t figure out where the data/info model is. Where are the gaps? What will phenopackets do that is going away from this? Implementers do well is create models. FHIR has more control, but you can change the cardinality and modify things. We can guide them.

KR: A conversation we would like to have at GA4GH. Do we mean a Schema registry or a Data Model registry? NCPI/NCI - people are saying we don’t a model, we want a metamodel. Can we get together and have a conversation about this? Alignment on terminology is helpful. Reference schema is a good idea.

MB: Dictionary, tracking of schemas, data models etc. Library of equivalency.

KR: A registry of mappings between.

KR: A lot of efforts between NCPI - what is it we need? Wrestling with the same questions. GA4GH teams are tackling different aspects of it. NCPI wanted a deeper conversation to improve interoperability.

NS: Response to that - interested to hear what people think. Cultural aspect - how do we get people to reuse stuff? Technical aspect - how do we actually write/use these? Is this a library of schemas or models. It would be useful to have like Github for Schemas. Anybody can put whatever they want in there, the ones that fit become standards. Discoverability. Currently in silos. Make it super easy to create and share Schemas.

MB: This was SchemaBlocks. Main issue is maintenance. Forcing/interacting with donor schemas. An approved standard. Horrible that Phenopackets is in ProtoBuff. There isn’t a driver for them to want to have this in an external site. It distracts from core development. We had a complete schema version in JSON, with stable endpoints. Needs to be maintained by someone. TASC team didn’t go in that way. Donor needs to stick with it.

NS: Limitation for SchemaBlocks - I can’t create a SchemaBlock.

MB: This is just a GitHub repo. Was prototyping for some developer to take over.

AW: Real thing we need to coordinate. What is our plan for a way to share? What is the strategy? We all need to commit to it. The next step is to formalize it. Use these calls to work out the challenges. Specifics of implementation second.

NS: +1. Don’t understand {S}[B]. I don’t get it. So I’m currently publishing on my own GitHub repo.

MB: In SB organization, you would have a repo for your Schema. Just format it and run a script.

NS: Past tense.

MB: It is possible, but it was retired in favour of something more limited. Still possible.

Zoom chat transcript.

14:11:47 From  Michael Baudis  to  Everyone:

        https://schemablocks.org/schema_pages/ 

14:20:00 From  Michael Baudis  to  Everyone:

        The website of the GA4GH SchemaBlocks Community ({S}[B]) represents information about data schema components, standards and procedures with consensus support from GA4GH members. The documents should not be considered "authoritative GA4GH recommendations" but rather represent community-provide documentation and implementation examples.

14:21:31 From  Kathy Reinold, Broad Institute  to  Everyone:

        I can identify -- just finished w/ covid myself!

14:22:57 From  Lindsay Smith  to  Everyone:

        https://pedigree.readthedocs.io/en/latest/ 

14:27:08 From  Michael Baudis  to  Everyone:

        Also you cannot easily point to Phenopackets since Protobuf...

14:28:26 From  Michael Baudis  to  Everyone:

        ... or reference implementation

14:29:21 From  Lindsay Smith  to  Everyone:

        Lindsay.smith@ga4gh.org

14:30:07 From  Kathy Reinold, Broad Institute  to  Everyone:

        reference schema!

14:30:21 From  Larry Babb  to  Everyone:

        are the examples in the pedigree RTD all based on strictly on the phenopackets schema? and if so does it demonstrate the mapping back to the information model elements so that it's clear how Phenopackets relates to the info model?

14:31:09 From  Lindsay Smith  to  Everyone:

        We have a rough mapping between models here: https://docs.google.com/document/d/1GQRd5jeZeB5qhHclLZxDe6kPD173bXWGYlTsmCbTeuI/edit 

14:31:19 From  Kathy Reinold, Broad Institute  to  Everyone:

        +1

14:31:23 From  Larry Babb  to  Everyone:

        A data model “should be”(IMO) a 3rd normal form representation of entities and their attributes (including primary and foreign keys)

14:32:17 From  Kathy Reinold, Broad Institute  to  Everyone:

        Hmm need to think about the primary and foreign keys part -- sounds like a relational database implementation rather than a model.  thinking ...

14:33:02 From  Larry Babb  to  Everyone:

        essentially, the pk/fk associations should be clear via the associations between entities and their cardinality

14:33:45 From  Larry Babb  to  Everyone:

        it may be a semantic difference in terms of what we refer to as a "data model" vs an "informational or conceptual model”

14:34:37 From  Larry Babb  to  Everyone:

        for example a "class diagram" uml style to me is a bit more useful for conceptual modeling whereas an ERD is more useful for data modeling. IMO

14:34:51 From  Alex Wagner  to  Everyone:

        +1 Larry

14:36:18 From  Michael Baudis  to  Everyone:

        We need a GA4GH dictionary about the semantic use of model / schema / implementation / serialization / concept ...

14:36:28 From  Alex Wagner  to  Everyone:

        Increasing concreteness: Information Model -> Data Model -> Exchange format / schema

14:37:59 From  Michael Baudis  to  Everyone:

        Waht is a "variant" :-)

14:38:11 From  Michael Baudis  to  Everyone:

        What...

14:38:35 From  Alex Wagner  to  Everyone:

        😂

14:40:28 From  Alex Wagner  to  Everyone:

        Isn't this what schemas are for?

14:40:34 From  Michael Baudis  to  Everyone:

14:44:28 From  Michael Baudis  to  Everyone:

        Actually a lot of interest isn't even there but just sets of mappings - I wouldn't call these models (but this might be me...).

14:47:23 From  Michael Baudis  to  Everyone:

        In Beacon we have descriptions about the relartion to other standards ... http://docs.genomebeacons.org/formats-standards/?h=phenopackets

14:48:06 From  Michael Baudis  to  Everyone:

        ... which is descriptive, for "readers", to understand / track some provenance & equivalencies.

14:48:16 From  Larry Babb  to  Everyone:

        is there a mapping between phenopackets and the “core" pedigree conceptual model? or is phenopackets "the" representation which 100% representative of the "core" pedigree model?

14:50:17 From  Larry Babb  to  Everyone:

        a class diagram would be a nice start

14:50:43 From  Kathy Reinold, Broad Institute  to  Everyone:

        schema.org?

14:51:07 From  Kathy Reinold, Broad Institute  to  Everyone:

        or is GA4GH Schema Registry schema.org for biomedical research?

14:53:09 From  Lindsay Smith  to  Everyone:

        @Larry - There's a class diagram of the Pedigree model here: https://pedigree.readthedocs.io/en/latest/classes.html , but the mapping to phenopackets was done in the table here: https://docs.google.com/document/d/1GQRd5jeZeB5qhHclLZxDe6kPD173bXWGYlTsmCbTeuI/edit 

14:53:18 From  Nathan Sheffield  to  Everyone:

        @Kathy, yes, exactly something like that.

14:53:44 From  Larry Babb  to  Everyone:

        it's at least a 2 person (more than 50% each) kind of effort to kick it off. then if it is successful, it will need more resources to keep it from dying on the vine.

14:54:50 From  Larry Babb  to  Everyone:

        thx @lindsay re: answer to question above

14:56:35 From  Kathy Reinold, Broad Institute  to  Everyone:

        Sorry, need to drop off.  Look forward to more conversations ...

2022-07-14

Attendees (Affiliation): Yash Puligundla (GA4GH), Fabio Liberante (GA4GH), Miro Cupak (DNAstack), Jules Jacobsen, Robert Freimuth, Lindsay Smith (GA4GH),

Actions

Info/Links

https://buf.build/product/bsr/

https://docs.confluent.io/platform/current/schema-registry/index.html - JSON & Protobuff

https://github.com/ga4gh/vrs-protobuf/blob/main/vrs2proto/y2p

https://github.com/ga4gh/vrs-clojure

https://github.com/envoyproxy/data-plane-api/tree/main/envoy/api/v2

Minutes

2022-06-09

Attendees (Affiliation): Yash Puligundla (GA4GH), Alex Wagner (Nationwide Children’s Hospital, Ohio), Fabio Liberante (GA4GH), Melissa Haendel, Kathy Reinold

Actions

Info/Links:

Discovery_subgroup-SchemaBlocks_Meeting_Minutes_2021-210309

19 - Connect 2022 Agenda - Data Model Sharing

• LinkML 
• https://docs.google.com/presentation/d/1jtV2vQhCwsGv_9fPplkG8ww1ru4V_JYyRGLAm2dxvdE/edit see slide 10
• emergent phenopackets in LinkML, as an example: https://github.com/cmungall/linkml-phenopackets 

Options:

Minutes

Alex Wagner - initiatives already in GA4GH. SchemaBlocks. Beacon as an exemplar for benefit. GKS overlap - data models - tightly version and specify - to harmonize on these models. Implement on different stacks. JSON/ProtoBuf schema - other tech artifacts. Model providence, version, maturity. X-GA4GH setting. URI my own schemas. Outside hosting of data models is outside our scope. System for models to be added internally GA4GH. Product Review Process integration.

Haendel - SchemaBlocks was a failure. Some progress on identifiers. Some success, lacking maturity for tooling and use cases. Just never took off. Not enough experts for the tool chain. Not a big enough library. Schemas in 6 languages back then. Documentation is worth looking at again. GA4GH tools should work together.

AW: - +1 MH’s idea. Data Models agnostic to Tech artifact. Think about ways to specify that. Metamodel - link existing models. Derive tech artifacts - something like this in GKS. What about LinkML. Move away from tech language like JSON/Protobuf.

JR: Opposite approach to LinkML - move away from a general language that is good for everything. Schema is limited by whichever languages you want to move/convert it into. Something standard enough for everyone, WTC/JSON schema? Metaschema like LinkML - some things currently in Beacon can not be done in LinkML.

MH: People need schema in different languages. JSON-LD has become a de facto standard. Doesn’t define upstream schematics (e.g. closure). Struggled with that in Protobuf. A way to integrate somehow. GA4GH has been trying to do it for 5 years for Protobuf. Nothing like LinkML currently?

JR: Do we need things in different languages? Not everyone happy, but clear and defined. JSON schema is less mature than XLST, but more so than others. Do we need meta-schema languages?

MH: I do not think it’s helpful to GA4GH. Library of interoperable standards. Everyone has. Lossy transform between them. GA4GH wild west.

AW: We all agree that we want to find a consistent way to represent stuff across GA4GH.

KR: Can never guarantee that the languages won’t change. Seen 40 languages across my career. Mess to clean up afterwards. We will always have to implement data models in different languages.

MH: This was why LinkML was invented.

JR: Do we have any LinkML representation here?

MH: My team has done a lot of work with it. Not personally. Don’t use LinkML unless it’s actually the correct one. Converting PhenoPackets into LinkML to allow FHIR implementations. You still need a strategy to actually describe data. Metadata work stream and SchemaBlocks both failed.

KR: LinkML is still quite early to me. OWL has some nice visual tools. Graph models work well for connecting data. Different ways to express it. For higher level, LinkML makes more sense. A little heavy for moving JSON Schema around.

JR: An agnostic way is totally fine. Many years ago “logical model” and “physical model”. I can understand that. If we decide on a modeling language - we can define . In Beacon we have 3 responses, boolean, count, detail. You can check against the schema. In JSON schema some parsers are having issues with these things. Simply moving the problem from one place to another.

AW: Lots of these points make sense. Challenges of a single framework. Tech stack is not as important as a way to collect our requirements. Then find the framework afterwards. The activity of this group - a set of requirements. Then find the framework afterwards.

===Check Recording at ~42 minutes===

AW: Some things limited in JSON Schema.

JR:

AW: Requirements of GA4GH community. Tech question is secondary. Tendency for us all to want to use the latest.

KR: +1. What are the requirements?

MH: My major requirements for this group are to define interoperability requirements :-). do we even have a list of all the models now? can we examine overalap? implementation pros/cons? interop?

KR: Not get into the tech immediately. Would be good to have demos. Requirements could be concise, but not a serial process.

MH: Get a list of the schemas across GA4GH. Is there even documentation? I cannot do PhenoPackets until GKS schemas are interoperable. I am blocked until VRS is defined. Starting with a list.

AW: Overlap analysis. Where are we going with this? Steps that help with that interoperability?

KR: Things outside of GA4GH?

JR: Beacon approach - you have your own schema/models and then allow others afterwards. Otherwise you have different approaches.

MH: use cases :-). biolink model - this is for Kathy, community model for graphs: https://biolink.github.io/biolink-model/docs/ 

(it predated linkML, but was an inspiration for it)

MH: VRS + PhenoPackets. 3 examples like that. A registry of existing standards? Where are the numbers? Data tags, like this is the schema for this tool?

2022-05-12

Chair:

Attendees: Susan Fairley (GA4GH), Nathan Sheffield, Michael Baudis, Jordi Rambla, Jonathan Fuerth, Kathy Reinold, Jeremy Adams, Melanie Courtot, Matt Brush, Bob Freimuth, Isuru Liyanage

Info/Links:

Discovery_subgroup-SchemaBlocks_Meeting_Minutes_2021-210309

19 - Connect 2022 Agenda - Data Model Sharing

Minutes:

MB: Still a need for something like SchemaBlocks. Perhaps not to the same scale. Re-enlivened  somehow? More atomic, and with a clearer focus.

SF: Need to define the need/gap more broadly.

MC: There is a need to define purpose of this work. This was a limitation of SchemaBlocks.

KR: Limitations in our ability to share data. Difference between a Data Model and Schema! Does this fit with GA4GH?

MB:

JA: Main question was what is this and what do we want to achieve. Main aim is to align GA4GH better internally, but if we build this in a way that can be public-facing it increases the applicability. A standard allows this and other use cases. Start with use cases and what that the Registry standard/API looks like.

SF: Motivation not only internal GA4GH alignment. Whose problem are we solving? Is there something we can already use? Data Connect needs something like this, at least external implementations. Better defined use cases will make a better/more useful product.

MC: DUO has been adopted widely, but the format for sharing varies. Implementations are very individual.

SF: How is DUO using SchemaBlocks?

MC: Data set is labelled DUO00006, but the encoding does not use a shared structure. Incoming requests for data would need to adapt the DUO format/implementation, inconsistency makes it complex. Importance of consistent structure for publishing/referencing

SF: Could SchemaBlocks address this?

MC: It has to certain degree.

MB (in Chat): So SchemaBlocks has addressed the problem and e.g. Beacon has implemented the JSON-converted Phenopackets (though running ahead of the {S}[B] version & it would have been much easier if we'd had kept pace there...). https://schemablocks.org/schemas/ga4gh/DataUseLimitation.html 

MC: EGA is an expert on using DUO, but chose a different approach to Broad for example.

JR: Helping submitters with DUO codes.

MC (in chat): everyone has done it in a way that works for them, but is not standard, which eans each has their own implementation and set of tools

SF: Who outside GA4GH would use this?

MB: Beacon is the poster child for using SchemaBlocks to convert PhenoPackets. http://docs.genomebeacons.org/formats-standards/#phenopackets {S}[B] was designed to sit separately from Data Models. Data specific projects - mappings in data sets is a bit of a separate story.

JR: Who are the targets? Inside GA4GH or outside? Is our goal to set examples for how to represent data?

SF: Data Model Library - only GA4GH models. Product Approval Process should encourage re-use and alignment. This piece of work is different, a schema equivalent to the tool registry service. A long-term centralized registry doesn’t fit with GA4GH, decentralized is better. Could a testing platform help?

JA (in chat): I'd say the main action coming out of this meeting is to collect use cases for a data model library/API. If the use cases are all internal to GA4GH (e.g. DUO), then it's not necessary to a develop a standard, a core GA4GH data model library will suffice. If we see Driver Projects also want to publish/share data models and schemas beyond GA4GH schemas, then a standard would be needed, which would allow for multiple implementations

JR: Is there nothing already out there?

SF: SchemaBlocks is a good example. Should be looking at Global Open Science etc.

MB: Even if we align well, there will always be things that do not fit quite so neatly. DUO is an example.

JR: Big projects publish their own data models. Doesn’t seem an important need.

JA: Standard would allow more sophisticated shared interactions between APIs.

MC: What’s the next step?

JR: As a user, I would expect uniformity from across GA4GH. Tame the beast ourselves, before tackling outside. E.g. MB’s idea to convert everything to JSON. A style guide.

MB (in chat): I didn't say no LinkML! ... but experienced people said it would be hard ¯\_(ツ)_/¯

SF: There are plans to move in that direction. We have 2 data model languages.

MC (in chat): but even then not everyone agreed than JSON was a good choice - as per susan

SF: Product Approval Process will help interoperability.

MB: It would have been better to have a data model registry/standard to prevent the need for on-the-fly conversion of PhenoPackets as in Beacon.

SF: Consistent data structure simplifies sharing. E.g. FTP data providers. Doesn’t solve the mapping problem. How do I understand how to figure out what the data?

MB (in chat): Well, GA4GH went AVRO -> protobuf -> JSON Schema, so let's assume that this "evolutionary". Well, Beacon does this. Showing the schemas of the response.

IL: Google SoC - developed a tool to store/share Schema.

MC: + the biovalidator you developed @Isuru

JR: ProtoBuf is a way to move data fast, not complex data descriptions. Data Connect is a query language. Limited/or complex to query alternatives/nested. Like using Excel for DB, or PowerPoint instead of PhotoShop. Schema language, LinkML is a bridge. Mixing tools?

JF (in chat): factual corrections: anything you can do in JSON Schema, you can do in Data Connect

SF: Maybe JR is right about Driver Projects not having a need for something like this. Perhaps the big data houses would be better places to start?

END OF DOCUMENT