Technical standards around MyData and Covid-19

coronadata
#1

If we assume that JLINC can be one of the ‘standards’ that we use to underpin MyData app building in this urgent context, then this topic will gather notes and suggestions on what needs to be done with the JLINC technology, UI and data management to prepare for such hackathons.

Start point:

Consider two scenarios:

  1. What, if anything, should we do immediately with existing UI and methods?

  2. What should we do with live, production variant of JLINC apps that are around 2-3 weeks away (so early April).

In the live, production environment mode we should start with:

  • external APIs through which personal data services can connect to the A Server to build deep data services for individuals
  • external APIs through which application developers can connect to the B Server in order to push and pull data from the A Server via the B Server
Multiscale approach to COVID-19
#2

Sorry for this question that will get your mind racing, but can data commons be generated programmatically?

Also, can we invite people en masse?

#3

@Simon @pidoux @Luca the idea will be to have an international MyData hackathon. I suggest we repurpose the EPFL hackathon around this. What do you think? Does that mean everyone in MyData hacks on the same day? I would say not necessarily.

2 Likes
#4

One thing I wasn’t clear on. Could app developers directly use the A-side of the protocol in their app?

1 Like
#5

What specifically do you mean by ‘data commons’; do you mean nodes on the B server?

If so the answer is no not immediately, but that is what we are working towards in the next release. The key thing the JLINC team need to deliver is external API’s to A and B services (i’ll start calling them services rather than servers as that framing will make it easier to explain I think).

As a general rule, things that would most logically connect to A Service would be classic personal data services - the DigiMe, Meeco’s, Cozi etc. There job would be to deal with the more complex individual data needs (data over time, analytics etc) to take that burden off of the J LINC A Service UI which is optimised for data provenance management, not for analytics presentation. The things that most logically connected to the B Service are anything that is moving data in and out of the eco-system. Does that help?

Yes, people can be invited en masse via .csv import (which was fixed I believe after your bug; need to test that).

One other thing i’d consider looking into, for example, would be a connector to Salesforce Health Cloud. That would enable rapid scaling into those health care organisations using that service (which I think will mainly be in USA). It would quite probably also bring in resource/ funds from SF.

#6

Yes, when the external API’s are completed. So we need a fine balance between urgent desire for hackathons and those API’s being ready. The discussion I have had with the JLINC Dev team suggests they are most likely w/c 30th; but I have pointed out that API’s do not need to be complete to run a hackathon if documentation is sufficient to clarify what will be there. We probably have more of a documentation need than anything else. I’ll start a separate thread on that.

#7

I think a rolling set of related hackathons that build on each other would be better than one big focused one. As per the dialogue on MyData Slack, we can hopefully bring Johannes Ernst into the mix as another silicon valley located volunteer.

#8

Commitment to document APIs and agreement on what they should be (cc @Hanz0mon) + rolling hackathons seems to me to be a big win.

On the other hand, and quite crucially, keeping with the viral theme throughout, we do need to enlist various forms of support for this project and our approach. The best way to do this is to already roll out something, that will be useful in showing the approach is viable. Makes sense?

1 Like
#9

Yes, that makes sense thanks; we carry on with tactical and strategic work. Johannes Ernst has already done some external documentation on JLINC so hopefully he can join in and help on that.

#10

Here are two screenshots from JLINC Preview deployment; i.e. not the sandbox one we have used to date. This significant upgrade has a number of new key capabilities; firstly the concept of networks and spaces (it says nodes on UI at present but that will change). What this means is that an overall network can talk to and aggregate data from within all the spaces and individuals in its network. So practically that would mean Paul would be a member of the Swiss Covid 19 data commons, which itself is a member of the global Covid 19 data commons. The second main upgrade in this mode is that the overall system is much more interactive; so a bit like a social network but for org relationships; not individual at this stage. Clearly lots more to say on that as we’ll most likely build strategic solutions using this model for data provenance.

16
161246×718 54.3 KB

#11

Following this discussion from the side, here are some comments:

  • Discussion so far looks very platform and tech specific: Lots of idiosyncratic tech terminology.
    This is a problem, both for people not buying into specifc tech
    (e.g. bc competitors in the mydata space), but also non-experts,
    feeling that this discussion is not for them.
    I know it is a standard, still it is currently effectively about a single implementation.

  • Target unclear. Do one specific use case please, to start with,
    e.g. self reporting on places and contacts history.
    If i learnt anything yesterday, then that this use case is the most important one
    in two weeks time, latest.

  • We can discuss how to keep it flexible to be extensible, but people need
    something really specific in front of them, that they can contribute to.

Does this make sense?
Sorry Iain, my pushback, stating it being too JLINC specific is by no means a critique of the product or the standard.
I just feel that it will impede the effectiveness and acceptance of the whole exercise.
Certainly it should be used within a stream of the hackathon, but the event should not be framed around it.

P.S. Note that I have no relation to any such tech, whatsoever.

#12

Hi Marcel, yes that’s all fine; so far as i’m concerned this is the early start of the technical part of the hackathon discussion, and until someone else pipes up with an alternate proposal then it is by definition 100% about JLINC. That said, there is a big learning curve in this area that we are trying to go up very quickly. Simplistically, JLINC is a protocol first (protocol.jlinc.org); and on top of that people can build stuff. It is still early for the protocol, even earlier for things on top of it; were it not for the Covid 19 emergency i’d not be pitching it at all in here as a solution. Even at that stage we will struggle to get bandwidth from the small development team; hence hackathon is a good way to build on and around a core.

There are no competitors to JLINC protocol in the MyData space; their might be some that perceive that they are but that is because they are looking at what is built on it rather than the protocol itself.

The counter point to not building in a focused way (which lets face it is what will happen anyway) is that we’ll end up with 10k Covid 19 apps in the app stores; silo-ed data all over the place with no provenance, and who knows what being done with it 12 months down the track.

I’m personally not convinced about the places and contacts tracing as I think that will run our of effectiveness quickly; but i’m happy to go with the flow/ epidemic expertise.

#13

Doing a hackathon is fine, but I think building a broader alliance with the likes of ODI is even more important. Lots of tech/process/standards alignment required everywhere within the next month.

#14

Absolutely, each of us can only speak on behalf of our particular skill-set; but what we are trying to achieve with MyData is a single global movement with many local and thematic ‘hubs’. MyData Global already has that shape and plumbing; so the question now is how can we transition from talk to action across multiple fronts under the same banner.

#15

You are right, Marcel. More and more people are understanding the need for this crowdsourced data collection. We should broaden the alliance in many different ways (most added value: in the MyData network).

This thread should remain to discuss, to the best of abilities, standards and protocols. Since we have only one player willing to play ball so far, feel free to go ahead!

As for a formal hackathon, the situation is changing so fast!

#16

This is a very promising development from the perspective of open source, bottom up standards bringing something unique to the table - a globally applicable digital credential of a persons Covid 19 status. I’ve added myself to the group along with MyData. Plan is for Paul and I to have a call with one on the team later Sunday 22nd. https://docs.google.com/document/d/1tSF0ARg022jC4Irj5c4bz10oXf0pmHSXoczWuuLeOdw/edit#

#17

Indeed, that looks very promising. I suggest every MyData Hub who feels this is a good idea officially registers itself as a participating organization ASAP (MyData Geneva, MyData South Korea, etc).

We can align on that technical standard, which would then all help us do the best thing for our little neck of the woods.

#18

Agreed, but my inclination is that we should have that call with Tony/ Victor later today before we chip in and overwhelm that document with MyData stuff. It has long been the case that JLINC and Everynm for example have known that we can demonstrate inter-operability of DIDs and Credentials. We have never had anything to force this issue, nor indeed should we up till now as neither standard is quite yet formally signed off as such. But I guess (hope) we’ll never have a bigger forcing factor than what we have now.

We also need to be aware that this is only a piece of the jigsaw; being able to issue credentials is very different to all of the relying parties being able to accept, digest and use them. That’s part of the bigger picture; but if we do this it is a very strong signal that bottom up solutions can help now and in the future.

#19

My thoughts on the architectural components needed:

We need to work with them to tease out the architectural components; as I see it those are:

  1. a human being
  2. a user controlled identity for that human that is able to share data in rich, valuable ways whilst retaining appropriate privacy
  3. a data store/ data-set related to the above identity; data store and access to it also controlled by that human; this data-store/ data-set must be able to be updated and tweaked without losing historic integrity
  4. a mobile and desktop interface to the above, run by a trustworthy entity
  5. a data store within the trusted entity
  6. an interface (API) to/ from the trusted entity and those other defined entities able to interact with this data-set
  7. a UI for the data-set proving visual and data analytics to all parties
  8. External entities who will use that data-set and analytics who will be in position to sign up to the fair terms associated with accessing that data-set
  9. An audit log to keep all partiess right down the track
  10. an appropriate data sharing agreement that all parties can digitally sign
1 Like
#20

The short answer is yes.

The core JLINC protocol specifies two endpoints and an agreement on an Information sharing agreement. If the data commons expresses the purposes and uses and disclosures of the data that it ‘wants’ to receive from the data rights holder (AKA Alice）then any Alice (or agent acting for Alice) can enter into the commons under the terms of the data commons information sharing agreement. Ideally the commons would act as a fiduciary with respect to the data it holds in trust for the alices that contributed.