Wikipedia Article Discussion

This page is for suggestions about which VRM terms should be added as Wikipedia articles and how they should be linked. Please edit as needed to share your views.

New Articles

Drummond suggests adding the following Wikipedia articles. See his blog entry about these terms for rationale.

1. Personal data service
2. Personal data server
3. Personal data store
4. Personal data ecosystem

Disambiguation Links

Drummond suggests editing the PDS page to add disambiguation entries with links to the first three articles above.

Cross-Links

Drummond suggests all three of the above include links to each other and to the [1] page (plus other page-specific links as needed, such as to the Mydex white paper.

Next Steps

1. Complete preliminary discussion of the above on the ProjectVRM mailing list.
2. Compose first drafts of the three articles above.
3. When there is consensus, post everything to Wikipedia.

Change Log (Reverse Chronological Order)

• --DrummondReed 05:19, 8 October 2010 (UTC): Added Joe Andrieu's feedback below.
• --DrummondReed 22:06, 7 October 2010 (UTC): Broke out personal data server so it will be its own article per feedback from Katherine Warman Kern.

Feedback

Joe Andrieu 2010-10-07 Email to ProjectVRM List

Drummond,

I'm a bit surprised you didn't include references to the work already done by folks in this community. An oversight, I'm sure, because I know the point of the exercise is, in fact, to unify these disparate views. And I'm guessing I may have missed some of the references in what I list here, like Paul's work. I'd suggest linking to all of those as part of the VRM wiki to provide background & context.

My single biggest complaint would a personal data service sounds like it would also include those services which use my personal data to provide value to me, as opposed to just those services that mediate access & permissions.

In UMA, this role is an Authorization Manager: http://kantarainitiative.org/confluence/display/uma/Lexicon

Using the information sharing terminology developed last year: http://kantarainitiative.org/confluence/display/infosharing/Lexicon This role is an intermediary.

Or using the glossary from the pRFP Engagement Model: http://kantarainitiative.org/confluence/display/infosharing/Personal+RFP+Engagement+Model This role is a facilitator.

Finally, if you use the lexicon that Doc, Iain, Kaliya, Craig, and I developed after the last VRM Workshop: http://blog.joeandrieu.com/2010/09/17/personal-data-stores-exchanges-and-applications/ This role is a personal data exchange.

My hope is that at the end of this process, we have a set of terms that will be essentially understood by the unitiated at first sight. The first three times I read through your blog post, Drummond, I thought you were combining exchanges and applications in your definition of personal data services. So, I think personal data service fails to be easily understood, even with a sophisticated reader.

I think this is backed up by Katherine's comments where she imagines a personal data store as an aggregator of information. It's more likely that it's the exchange that acts as the aggregator, while the underlying data continues to live at its "native" store.

One key element here I don't think any of us have adequately addressed is the distinction between on-demand data used in mash-ups, and collated, cached data aggregated and stored. A premise I've been operating on is highly preferential to the first, but many people's mental model of a datastore is of the latter. Given the zero-distance network, I believe the future is in mashups, not in stored aggregation. Yes, we'll cache when it speeds things up, but that's fundamentally different than aggregating all your data into one place so you can use it. Instead, use an exchange to let the data be served from wherever it is and consuming applications can pull it together at run-time to provide value. Not only does this eliminate a whole raft of data quality & maintenance issues, it removes the aggregated data store as a honey pot for hacking one place to get all your lovely information. Unfortunately, I'm not sure how to make this distinction in our lexicon.

My second biggest complaint is similar to the first, but regarding the connotative confusion between a personal data server and a personal data store. If I hear (or read) "personal data server", my first interpretation is to think that is a machine that serves up personal data. But it isn't. It's software that operates a personal data service. Unfortunately, "server" is used to mean the software, the hardware, and the running instance of that software, depending on context. This innate ambiguity doesn't bode well for "server" as a term.

I think the root of the problem is that "service" and "server" are incredibly general terms that are used throughout our industry for several different meanings. Even combined with an adjective and declared as part of a curated lexicon, I have a hard time believing that a majority of people would hold on to the distinctions in common usage. On the other hand, stores, apps, and exchanges seem to have fairly distinct niches in our mental model of how the world works.

Finally, I'll put in a vote against Ecosystem. I know a lot of work has gone into using that name, especially with the formation of the new IC3's Personal Data Ecosystem group. However, an ecosystem includes predators and parasites and digestive, destructive niches. I've never been a fan of its use for engineered systems because unless you're doing some sort of genetic evolution, you rarely design in willful subjugation, exploitation, and destruction of elements in the system.

Doc, Craig and I played around with "grove" as a metaphor for this system of stores, exchanges, and apps, but that has it's own problems. What it /does/ have, however, is a unique space in our mental architecture. If "grove" were established in our lexicon, it'd be absolutely clear what we mean when we tell companies to integrate the Grove into their business or be a part of the Grove or get in the Grove, just as we said the same things about the Web. Telling a company they need to get into the Ecosystem just doesn't have the same clarity. You still have to answer which ecosystem you're talking about.

Since I have so many comments on the basic breakdown, I didn't want to directly edit the wiki. We should get the framework in general consensus, then flesh it out. Also, it'll probably be easier to understand the lexicon as a whole if all the terms had definitions on the same page, instead of having each definition separate.

-j