3 ms·

Let 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 the

Let 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 ago
They 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 ago
Honestly, 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.

edraferi 8y ago

They 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 ago

Honestly, 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.