Open itsrobli opened 4 years ago
I agree with @amdk8800 and @itsrobli. We need more use cases to formulise the data exchange structure. We need vision, planning and efforts into defining the format, and I reckon it would be no easy.
From the perspective of technology implementation, I suggest we can have a look at Protocol Buffer. It is a strongly typed interface description language that provides strong validated data format. Paired with gRPC or even REST, strongly typed data format can deliver much faster client-server communication performance than JSON + REST. As a reference, here is how Google Implement FHIR standards using Protocol Buffers. https://github.com/google/fhir
I'm very inspired by this: https://github.com/google/data-transfer-project
Just had another read of the updated README, @itsrobli great job of converting complex concepts into easy read! The host platform reminds me of blockchain node :)
The host platform reminds me of blockchain node :)
Aha! Now there's an idea to get some attention! 😃
Per @amdk8800
• We should have a look at some of the existing data standards / reference models available. OSCRE and MSCI comes to mind. Private company data submission templates can also be adopted if their use is common enough, an example being URBIS for retail sales; • We may have to collate a fuller set of use cases before deciding on what the generic looks like. This will help us manage the standards – what’s core, what’s a side module, which part will satisfy Retail requirements vs Office, Residential and Industrial. • It is vital to plan for the different systems interoperability requirements from companies of different data maturity level – from small JVs wanting to use CSV/VBA interfaces to larger REIT’s that are wanting API driven workflows; • We may have to do a bit of thinking structuring the various data transform layers and try to decouple them as much as possible. E.g. Client Business Definition, Data Cleansing, Incoming Data Validation.