4 ms·
Let me repeat this loudly so people in the back can hear: TRANSPORT MECHANISMS ARE NOT DATA STANDARDS! It is great that they want to build on REST and use com
by clavalle 8y ago
Let me repeat this loudly so people in the back can hear:
TRANSPORT MECHANISMS ARE NOT DATA STANDARDS!
It is great that they want to build on REST and use common authentication standards and what-not: but that's not the hard problem. The hard problem is the data itself (including the critical structure of the data) and getting it to agree.
I liken it to someone that wants to build a rail system out of LEGO and then saying it is a 'standard system' because the LEGO are all the same...but they don't say anything about the size of the tracks, the overhead clearance, how the train systems should act in case of junctions or possible collision.
This is yet another 'data transfer standard' that hand-waves away the hard part -- the inter-compatible data model.
- red0point 8y agoLet me shout from the back so you can hear: BUT THEY HAVE AN INTER-COMPATIBLE DATA MODEL?! Or at least they're trying to create one. They talk about it in their overview: https://datatransferproject.dev/dtp-overview.pdf https://datatransferproject.dev/dtp-overview.pdf And the actual implementation of the model is on Github as well: https://github.com/google/data-transfer-project/tree/master/portability-types-transfer/src/main/java/org/datatransferproject/types/transfer/models https://github.com/google/data-transfer-project/tree/master/...
- edraferi 8y agoThey have a couple Data Models: Calendars [0] is a simple Event + Attendees model Contacts [1] Re-uses vCard Mail [2] wants RFC 2822 compliant strings Photos [3] have just basic metadata with a URL to fetch pixels Tasks [4] is a simple to-do model Overall the data model seems like a significant amount of wheel-reinvention. These data models are all just JSON records... they should be JSON-LD with @context pointing to a shared schema, probably defined at schema.org. [0] https://github.com/google/data-transfer-project/tree/master/portability-types-transfer/src/main/java/org/datatransferproject/types/transfer/models/calendar https://github.com/google/data-transfer-project/tree/master/... [1] https://github.com/google/data-transfer-project/blob/master/portability-types-transfer/src/main/java/org/datatransferproject/types/transfer/models/contacts/ContactsModelWrapper.java https://github.com/google/data-transfer-project/blob/master/... [2] https://github.com/google/data-transfer-project/tree/master/portability-types-transfer/src/main/java/org/datatransferproject/types/transfer/models/mail https://github.com/google/data-transfer-project/tree/master/... [3] https://github.com/google/data-transfer-project/tree/master/portability-types-transfer/src/main/java/org/datatransferproject/types/transfer/models/photos https://github.com/google/data-transfer-project/tree/master/... [4] https://github.com/google/data-transfer-project/tree/master/portability-types-transfer/src/main/java/org/datatransferproject/types/transfer/models/tasks https://github.com/google/data-transfer-project/tree/master/...
- clavalle 8y agoHonestly, that's more than most that come out with their own pet data transfer standards. But, looking at the models, there is a loooong way to go. And once you have more than a handful of these very small, very shallow models they'll have to, themselves, fit in a meaningful structure (at least at each organization that plans to do something useful with them)... It will be interesting to see how they handle this when it reaches the next levels of complexity. I mean, since Leibniz there has been a time-honored tradition of very smart people trying and failing at this omni-model. Who knows, maybe this group will be the first to conquer it. I'll be happy if they take a small piece -- music services, for example, and really nail that. But the players have every reason not to get things too compatible so it's going to have to be a group of people pushing the services to use the data model than then other way around.