These design principles seek to guide the reference design by establishing the thought framework in which the DataPortability Technical Blueprint is developed
Ownership - Recognition of ownership rights
Rationale: Data ownership refers to the right to possess and control data that you contribute to, or get access to in a given system/data silo. Ownership implies power as well as control. The control of information includes not just the ability to access, create, modify, package, derive benefit from, sell or remove data, but also the right to assign these access privileges to others (Loshin, 2002).
Implications:
- The Owner can assign Access to information to a second party.
- The Owner can assign Ownership of a copy of the information to a second party. Each party has exclusive right to their.
- The Owner can assign Stewardship of their information to a second party. The Owner may delegate some rights to the Steward. The Owner still has ultimate control, and may revoke the rights.
- Shared Ownership is possible. Sometimes data is created as the result of an interaction between two parties. The two parties will need to agree upon protocols for managing ownership rights.
Further reading:
Implications for DataPortability:
- RIGHTS: What type of system do you need for Ownership Rights? Something like Creative Commons? How do you automate it?
- SHARED RIGHTS: Can we build a system that copes with Shared Ownership Rights for things like medical records? Or do we duplicate records and each party stores a copy?
- How do you revoke rights?
Consistent Formats - Use of existing and open standards throughout the system
Rationale: There are many active standard communities. Wherever possible, we will use their work. We will put the standards in context of each other, so that they are easier to understand and implement as an end-to-end solution. We will ensure that their work is rewearded and respected and that their source code and other contributions are compatible with the design.
Implications:
- We intend to invent or re-invent as little as possible
Implications for DataPortability:
- Standard selection process
- Handling Standard deprication or upgrades within the reference design
- Legacy support and translation
Availability -- Data available anywhere, anytime
Rationale:
Implications:
- Unless explicitly requested, data will remain with the vendor/application that created it (unless of course the user explicitly chooses to back-up or move the data).
- People assume the data will always be available, 24x7, taken care of by their Service Provider
Implications for DataPortability
Simplicity and Longevity - The reference design should reflect clear and straightforward decisions and approaches
Rationale:
Implications:
- The system has to be transparent. Is it possible to take data from 10 years ago and convert it into today's reference design? Will it be possible to take data in today's reference design and update it to use new technology developed 10 years from now?
Implications DataPortability:
Security/Privacy/Control - Built in control points for privacy and security.
Rationale: While it is desirable that Data is accessible across vendors and applications, users must ultimately have complete and final say over the accessibility of data between vendors.
Implications:
- Permission request screen
- Enforced security models
Implications for Data Portability:
- Permission screens much like remote OpenID/Oauth confirmation screens prior to any data accessibility
