Yesterday, the Sony Playstation Network of 75 million gamers was compromised. Names, addresses, and possibly credit cards were accessed by attackers. This may well be the largest data breach in history.

And a few days ago, it was discovered that iPhones keep track of your location over extended periods of time and copy that data to backups, even if you explicitly tell your iPhone not to track your location. There are believable claims that law enforcement has already used this information without a court order. Apple now says this was a bug and they’re fixing it.

In 1984, Stewart Brand famously said that information wants to be free. John Perry Barlow reiterated it in the early 90s, and added “Information Replicates into the Cracks of Possibility.” When this idea was applied to online music sharing, it was cool in a “fight the man!” kind of way. Unfortunately, information replication doesn’t discriminate: your personal data, credit cards and medical problems alike, also want to be free. Keeping it secret is really, really hard.

I get the sense that many think Epsilon and Sony were stupidly incompetent, and Apple was evil. This fails to capture the nature of digital data. It’s just incredibly hard to secure data when one failure outweighs thousands of successes. In the normal course of development, data gets copied all over the place. It takes a concerted effort to enumerate the places where data end up, to design defensively against data leakage, and to audit the code after the fact to ensure no mistakes were made. One mistake negates all successes.

Here’s one way to get an intuitive feel for it: when building a skyscraper, workers are constantly fighting gravity. One moment of inattention, and a steel beam can fall from the 50th floor, turning a small oversight into a tragedy. The same goes for software systems and data breaches. The natural state of data is to be copied, logged, transmitted, stored, and stored again. It takes constant fighting and vigilance to prevent that breach. It takes privacy and security engineering.

The kicker is that, while it’s unlikely to get into the business of building skyscrapers by accident, it’s incredibly easy to find yourself storing user data long before you’ve laid out decent privacy and security practices: Sony built game consoles, and then one day they were suddenly storing user data. It’s also far too common for great software engineers to deceive themselves into thinking that securing user data is not so hard, because hey, they would never be as stupid as those Sony engineers.

So, am I excusing Epsilon, Sony, and Apple? Not at all. But if we keep thinking that they were just stupid/evil, then we are far from understanding and fixing the problem.

I’ve just finished reading Atul Gawande’s The Checklist Manifesto, which I strongly recommend. As industries mature (flying airplanes, practicing medicine, building complex software systems,…), they must build in processes to counteract inevitable human weaknesses. There’s bound to be resistance from experienced practitioners who see the introduction of process as insulting to their craft. Programmers are, in this sense, a lot like doctors. But it’s time to stop being heroes and start being professionals. Storing user data safely is easy until it’s not.

We are constantly fighting nature to meet our stated goals: we don’t want buildings to fall, disease to kill us, or private information to leak. For a little while, it’s okay to fail catastrophically and act surprised. But eventually, these failures are no longer surprising, they’re just negligent. That time of transition for software architects is now. Every company that dabbles in user data should assign a dedicated security and privacy team whose sole responsibility is to protect user data. We will not eliminate all failures, but we can do much, much better.

Last week, a few interesting security tidbits came to light regarding Dropbox, the increasingly popular cloud-based file storage and synchronization service. There’s some interesting discussion of de-duplication techniques which might lead to Oracle attacks, etc., but the most important issue is that, suddenly, everyone’s realizing that Dropbox could, if needed, access your files. Miguel de Icaza wonders if Dropbox is pitching snake oil.

Yes, Dropbox staff can, if needed, access your files. I don’t mean to harp on my fellow technologists but… this has been obvious since day 1, because Dropbox offers a web-based interface to download your files, and even with the latest HTML5 technology, you’d be very hard-pressed to do in-browser file decryption. Let’s say you still don’t buy that, you still think that Dropbox might find a way to encrypt files and decrypt them in your browser. Dropbox also offers a password recovery mechanism, which means they can fully simulate you, the user, including, of course, getting at your files.

In other words, unless you’re ready to lose the convenience of password resets and web-based UI, Dropbox inherently has access to your files. Just like Facebook has access to your entire account, and Google to all of your docs, spreadsheets, etc. The only question is what kinds of internal safeguards do these companies have to prevent abuse by employees. Unless you’ve worked there, it’s hard to know. You could ask Dropbox to do third-party auditing, like Miguel proposes, but in my experience that provides little real security, since you have little way to know what that third-party actually did as part of their auditing (was it just “logic and accuracy” testing?)

The other thing we could ask is for the law to finally recognize that my files stored on Dropbox are no different than my files stored on a hard drive in my basement, from a legal perspective. They’re my property. And accessing them should require the same level of judicial oversight as a warrant to my home. That’s what a group of young MIT techies (myself included) and Harvard lawyers proposed in 1998.

But back to Dropbox. Did they do something wrong? Yes, they did. They exaggerated their security and privacy claims. Just like almost every other cloud data host today. I wish, instead of picking on whichever startup suddenly succeeds, we picked on the industry as a whole. Stop talking about encryption in transit and encryption at rest in the same breath, as if they were the same thing. Stop using “encryption” as a synonym for “secure.” Stop saying “military-grade security.” Start being honest about who can access what.

And we, technologists, should stop with the drama, and not fall prey to the inflated expectations that marketing-heavy security policies have set. The Dropbox weaknesses should have been obvious to technologists from day one. The problem is that all privacy policies and security statements make exaggerated claims using reassuring keywords. Let’s harp on that.

Problem Analysis is right on

Some nuggets of the problem analysis, all from the executive summary (a quick and useful read):

First, most current health IT systems are proprietary applications that are not easily adopted into the workflow of a clinician’s day, and whose proprietary data formats are not directly exchangeable from one system to another.

Yes! Proprietary systems and data formats are the number one problem, as I’ve complained about before.

Second, most healthcare organizations that utilize electronic health records (EHRs) view them as purely internal resources, and have little incentive for investment in secondary or external uses, such as making them accessible in appropriate form to patients, to a patient’s healthcare providers at other organizations, and in de­identified or aggregated form to public health agencies and researchers.

Yes! I’ve heard someone phrase this as “there’s no billing code for sharing data with a patient or another hospital.”

Third, legitimate patient concerns about privacy and security make patients uneasy about participating in health IT systems or granting consent for their information to be used in research. Fourth, health IT has historically been oriented toward administrative functions, not better care. This is in part because, under the current fee­-for­-service payment model, the economic benefits of investing in health IT can rarely be realized by the provider or organization that makes the investment.

OK, so the privacy-and-security point is a little bit vague, but the point about administrative functions vs. care is right on. Overall, this is one of the clearest explanation of the problems with Health IT today that I’ve seen.

Patient Involvement: too timid

2. [...] achievement of the President’s goals requires significantly accelerated progress toward the robust exchange of health information.

Effectively, the meaningful use rules are too modest in their interoperability demands. I agree. That said, the report doesn’t sufficiently emphasize the role patients could play. They certainly talk about giving patients their data, but not about how giving patients their data is the natural path to secure health-data exchange between providers. No one can argue that the patient doesn’t have the right to see their own data, and if the patient is the messenger, then consent is inherently part of the mix. Instead, for some reason, Health IT folks are obsessed with solving every problem on the backend, fuzzy matching master patient indexes, etc. I continue to believe that the patient (as in, you, me, every user of the healthcare system) is far better positioned to manage their health data than anyone else. Giving patients their data is not just an end-goal, it’s a means to accomplishing other health data exchanges.

So when the report says:

The best way to give clinicians a unified, patient­-centric record tailored for each medical encounter is to store, maintain, update, and exchange the data as small, distributed, metadata-­tagged elements.

I disagree. The solution isn’t a specific technology used in expressing the data, it’s about how/where the data flows. The best way to give clinicians a unified patient-centric record is to give patients all of their data and the means to share it easily with the doctors of their choice.

Data Exchange and Interoperability: needs more work

The report then spends a good bit of time talking about a universal exchange language, and an infrastructure for locating and assembling [...] a patient’s record. These are interesting points, but the devil is in the details.

On the universal exchange language: it’s a lot harder than it sounds. The report does mention extensibility as a key feature to allow for private industry to build on top of this universal language, and that’s a very good thing. The report also briefly says the language must be “open.” That’s very, very good, assuming we have the same definition of open: anyone can use it and redistribute it, without asking for permission from anyone.

The problem is that existing standards organizations in health IT believe existing solutions to be “extensible” and “open.” SNOMED is open! RxNorm is open! HL7 is open! CCR is open! No, they’re not. Most are free of cost, but they’re not free of obstacles: you still need to sign up to get a “free license,” which means any organization must check that every other organization it deals with has signed those many “free licenses” to those vocabularies before data can flow. We need truly free medical vocabularies and formats, and we don’t have them yet. I wish the report emphasized this need more, since only the Federal government can make this happen.

And then there’s the “extensible” issue. This is, in my opinion, the worst part of the report:

We believe that the natural syntax for such a universal exchange language will be some kind of exten­sible markup language (an XML variant, for example) capable of exchanging data from an unspecified number of (not necessarily harmonized) semantic realms.

The emphasis is mine. Not necessarily harmonized? Then what is the point? We already have dozens of syntaxes for expressing medical data, and they all punt on semantic interoperability. That is insanity. We need semantic interoperability in this universal exchange language, lest we once again define the envelope without ever standardizing what goes inside the envelope. This is, sadly, how most health IT standards have defined interoperability: you can put anything in the envelope, so it’s extensible, right? No. Think about the implementer: where do they start on parsing that completely unspecified payload?

Let’s make this universal exchange language truly open and truly extensible. For best practices on openness, we can look to Open Source and Creative Commons for advice. For best practices on interoperability/extensibility, we can look to the World Wide Web Consortium‘s standards on Linked Open Data and RDF. These problems have been solved before, let’s not recreate half-baked solutions for health IT. And in the name of all that is holy, enough with the payload-agnostic interoperability standards. Payload agnosticism is anti-interoperable.

Privacy and Security: some good, some bad

The report recommends data provenance and privacy preferences tied to the data. That is a very good idea. It’s hard to do in practice, though, so if we go down this path, let’s really invest the time and money needed to figure out how to do provenance and privacy-preferences right. This is a big endeavor.

The report also recommends giving patients more control over the flow of their data. This is great, but it’s almost impossible for the average patient to understand what the various flows mean and how they’re used. This is yet another reason for giving patients their data so they can choose who gets to see it directly, rather than having to make decisions about transitive trust: do you allow doctor A, who spoke to doctor B yesterday, to speak to doctor C? Good luck with that.

Then the report goes into far too much detail about security and cryptography. It talks about keys, and digital signatures, and shared keys, and never storing the key on the same machine as the encrypted data (really? It’s only going to come together in RAM? How’s that going to work for gigabytes of MRI data?) There’s even discussion of how Data Entity Access Services can run authorization checks before delivering the encryption keys, and other descriptions of crypto protocol details. This is bad. It’s overly prescriptive and thus cannot take into account recent innovation, such as secure access delegation via attribute-based encryption. Instead, the report should have focused on general principles and requirements, such as:

• data should be secure even if someone eavesdrop on the network
• data should be secure even if someone obtains the hard drives from a decommissioned server
• authorized physicians, as certified by the AMA, should have access to any record via a break-the-glass approach, as long as there is an audit trail

Focus on requirements, and don’t mandate specific crypto concepts, as if all crypto innovation had stopped in the 80s. Let the technologists find/discover/invent the specific solution that meets the requirements.

Conclusions

I’m harsh on a few pieces of this report because, overall, I think it’s quite good. (And I thought this even before I realized, just now, that my colleague Ken Mandl was on the advisory committee for this report.) There are a few points that need more emphasis, however:

1. the government should NOT be building a concrete infrastructure for health data exchange. We don’t know the best way to exchange data nationwide, and we shouldn’t have a central, expensive top-down effort to achieve this. The market can figure this out… with some help (see next points.)
2. the government can and should define a truly interoperable syntax and semantics for medical record exchange. This may involve one-time purchases of proprietary coding systems, but at the end of the day, the output should be a truly free set of codes for all major medical concepts, an abstract model for representing them, and one default syntax for serializing this data.
3. the government should mandate that any healthcare provider make available, to any patient that wants it, all of their data in digital form using the universal syntax and semantics just mentioned, using a standard, open protocol. This should include transfer of said data to any Personal Health Record provider that complies with proper privacy protections and with the standard protocols, data format, and data semantics. No more one-off deals between one hospital and one PHR.
4. the government should mandate that any healthcare provider be capable of receiving, from a compliant PHR, a patient’s record, using the standard protocol, data format, and data semantics.
5. the government should sponsor Personal Health Records for all medicare/medicaid patients, say $5/month. Providers of these PHRs should fit conformance criteria for data portability and exchange, but otherwise should provide a relatively complete PHR service that the government can subsidize. The choice of the specific PHR should remain the patient’s, not any large hospital’s or other organization’s. We need market forces at work improving the PHR space, but we can use medicare to kickstart this market.

The standard protocol for exchanging data between two endpoints could be NHIN Direct / the Direct Project, assuming they continue to simplify their approach.

There is an opportunity for the government to significantly improve health IT, mostly by greasing the wheels of data exchange and interoperability. There are some tough decisions to make, however. We cannot punt on the medical data payload and semantics. And we must involve the patient at the crux of the architecture. Once the government has established fertile ground for innovation, by standardizing the data exchanges, privacy standards, and otherwise removing silly licensing obstacles, the market can do what it does best: find the set of optimal solutions within those principled constraints.

Kim points out that two issues got confused in the flurry of press activity: the accidental collection of payload data, i.e. the URLs and web content you browsed on unsecured wifi at the moment the Google Street View car was driving by, and the intentional collection of device identifiers, i.e. the network hardware identifiers and network names of public wifi access points. Kim thinks the network identifiers are inherently more problematic than the payload, because they last for quite a bit of time, while payload data, collected for a few randomly chosen milliseconds, are quite ephemeral and unlikely to be problematic.

Kim’s right on both points. Discussion of device identifiers, which I missed in my first post, is necessary, because the data collection, in this case, was intentional, and apparently was not disclosed, as documented in EPIC’s letter to the FCC. If Google is collecting public wifi data, they should at least disclose it. In their blog post on this topic, Google does not clarify that issue.

So, Google, please tell us how long you’ve been collecting network identifiers, and how long you failed to disclose it. It may have been an oversight, but, given how much other data you’re collecting, it would really improve the public’s trust in you to be very precise here.

Now, two points:

1. taking a second look at EPIC’s letter and Kim’s original post, it still seems to me that there’s some confusion of the device identifier and payload data issues: the uproar materialized after Google revealed they had mistakenly collected payload data, and EPIC’s letter and Kim’s original post seem to weave back and forth between both issues, never really mentioning intent. Is this because the payload data story is juicier in headlines, and so bundling the two issues helps make the more important point? Maybe, but still, I think we should be more precise and careful when we attack on privacy grounds.
2. I agree that device privacy can be a big deal, especially when many people are walking around with RFIDs in their passports, pants, and with bluetooth headsets. But, in this particular case, is it a problem? If Google really only did collect the SSIDs of open, public networks that effectively invite anyone to connect to them and thus discover network name and device identifier, is that a violation of privacy, or of the Laws of Identity? I’m having trouble seeing the harm or the questionable act. Once again, these are public/open wifi networks. For the most part, these are static access points. Given Google’s stated interests in providing geolocation services, it would be detrimental to them if they catalogued roving access points. So, what’s the worst-case scenario here? Is it that, when I move to a new apartment, Google will know?

None of this excuses Google’s lack of disclosure. This was intentional data collection, it should be disclosed, period.

And it’s worth asking the questions that Kim asks, raising awareness of device privacy. I’m not sure I’m as worried as Kim is on this particular issue, but the questions are certainly legitimate.

So, in the end, the privacy advocacy theater is coming first and foremost from the EU privacy folks, who did get enraged about payload data more than anything else. There’s still some coming from EPIC and, to remain blunt, a little bit from Kim’s first post. But his second post brings up very legitimate questions, and Google should take some additional action here, at least to let us know what they were collecting, when, and whether they properly disclosed it.

We weren’t the only folks proposing this kind of markup, and there remain healthy competing technologies. But because RDFa was architected with minimal centralization, anyone can create a vocabulary for it, anyone can use it and extend it without central approval, and that’s exactly what Yahoo, Google, and now Facebook did. They didn’t consult with the RDFa team. They didn’t have to. I consider that a great success: distributed innovation at work.

There will be work to do to reconcile the Yahoo, Google, and Facebook vocabularies. But that’s okay. RDFa lets you add as many vocabularies as you want, so you can easily combine the three vocabs for now to be maximally compatible. Over time, the tremendous power of the linked-data toolchain that forms the underpinning of RDFa will be brought to bear to progressively make the vocabularies compatible.

Exciting stuff for the structured-data Web!

So, HL7 is unlocking the power of health information, and to do that they’re going to sell you a standard.

Meanwhile, the National Library of Medicine has toiled for years on the Unified Medical Language System (UMLS), which attempts to codify *everything* in medicine, from anatomy to viruses. It’s a pretty impressive piece of work. Conveniently, they provide a “meta-thesaurus” that maps other coding systems, like SNOMED, to UMLS. Brilliant! Awesome! Except… to use UMLS, you have to register. And you have to fill out a yearly survey. And you’re not allowed to redistribute the UMLS codes. Oh, and you have to sign a 10-page licensing agreement that explains how you can use UMLS, but you can only use SNOMED under these conditions, and this other coding system you can only use in these other conditions, and if you don’t have three lawyers and a few weeks on your hands, good luck answering this simple question: “can I use this in my open-source library and release it freely to the world?”

Imagine, for a second, if we had a similar situation without computers. Doctors would have to pay a fee to speak official medical terms when discussing your health. You would have to pay a fee to have those terms translated into plain English. Canon would have to pay a licensing fee before making fax machines able to send medical documents from one doctor to another. In short, every time a health transaction occurs using standardized language, there would be a tax.

This is insane. Folks in the health IT world are focused on much harder problems while ignoring this blatant ball-and-chain on innovation.

I submit that the quickest path to health-IT reform is the complete and unconditional freeing of these medical vocabularies and data formats. And I mean complete. No access fees, no yearly surveys, no constraint on redistribution, country of origin, commercial or non-commercial. Free. like HTTP and HTML. Like English. Like a patient-doctor conversation.

Take a precise example: my group at Children’s Hospital Boston just released Indivo X, the latest version of our Personally Controlled Health Record. It’s great, but there’s one key feature we had to strip out before shipping this free, open-source tool built using federal grant money: SNOMED codes. Sure, we’re a hospital with a license, we can use them internally. But we can’t redistribute them. So now, to install Indivo, instead of a 30-minute process, you need to go get a UMLS ID, wait 3 days for approval, then download the files, extract the codes we think are useful, and load them into the database. No exaggeration, you’ve now multiplied your time-to-working-install by 100.

This must change. Either the existing formats must be opened up, or new formats must emerge that do to the existing formats what HTTP and HTML did to Gopher: kill them with freedom. Taxing human interactions, simply because they’ve been digitized, is an unacceptable brake on innovation, and in a complex field like Health IT, it’s the last thing we need and the first thing we need to eliminate.

Here’s the short version of the story: Apple produces iTunes, which manages all of your music and videos, and syncs them to your iPod/iPhone. Very cool software, magnificently built, great experience overall. I’ve been using this setup for 6+ years.

Along comes Palm with the Pre, a phone with functionality similar to the iPhone. Obviously, Palm wants to let its users sync their music and photo library with the Pre. Seems fair, right? Here’s how the story unfolds:

iTunes 8.0: I will only sync with devices called ‘iPod’
Pre 1.0: Hmmm, ok I’m an iPod! sold by Palm and manufactured by Palm
iTunes 8.1: Oh I see how you want to play it, I will only sync with devices sold by Apple
Pre 1.1: OK, then I’m an iPod sold by Apple, but manufactured by Palm
iTunes 9.0: dammit, two can play that game, I will only sync with devices manufactured by Apple!
Pre 1.2: OK, I’m an iPod, sold by Apple and manufactured by Apple

Now, some Apple fanboys, including John Gruber and Craig Hunter are calling Palm out:

Whatever hype and capital Palm built up around the launch of the Pre has been squandered on a pointless and trivial cat and mouse game with Apple over iTunes sync. The saddest part is that this was totally unnecessary, though Palm wants you to think otherwise.

You see, Palm doesn’t need the iTunes app to sync the Pre. They don’t need to draw Apple’s ire, or play yo-yo with their customers over this important capability. They can sync the Pre to a customer’s iTunes music library with a public, open, and documented approach that has been used by third-party developers and device makers for years. This capability was created by none other than Apple itself.

Funny that Palm is the only one blamed in this cat-and-mouse game. Why is okay for Apple to purposely reduce user functionality for no other reason than to stick it to Palm? At least Palm is trying to provide features to its users!

Also, if you’re going to start picking apart Palm’s design, then maybe it’s time to send the coding police after Apple, too: why not sync with any device that offers itself up as meeting the iPod API? Why force Blackberry and others to build their own sync apps? Maybe it’s okay for Apple not to go out of its way to help Palm, but then why actively spend resources shutting them out repeatedly? Do Gruber and Hunter actually believe that this is meant to protect users?

I’m 99% sure I know what’s going on. And Gruber and Hunter probably do, too. Blackberry syncing works great for non-DRM’ed songs, but read the fine print:

Certain music files may not be supported by the media player, including incompatible file types and files that contain digital rights management technologies.

There is no way for the Palm Pre to provide the full feature set that its users are entitled to without acting like an iPod, because Apple specifically built their system to prevent synchronization of DRM’ed media with devices other than the iPod. Once again, the legitimate user who bought his songs, bought his TV shows, and bought his Palm Pre, gets screwed.

I’m an Apple fanboy on many issues, but that’s not okay. And Gruber and Hunter should know better than to chastise the party that’s trying to do right by its users.

Stefano argues:

The difference between RDFa and Microdata (syntactic differences aside) is basically the fact that the proponents of the first believe that once everybody naturally starts reusing existing ID schemes and ontologies a densely connected web of semantically reconciled information will come together naturally. The second just want to focus on immediate values and avoid speculating on what’s going to happen next.

In the same vein, he adds:

The RDFa camp see it as a vector to promote the growth of the web of data, while the Microdata camp focuses on solving practical problems of embedding richer machine-processable information in web pages

That’s not true. RDFa is 100% focused on solving practical problems, e.g. for Creative Commons search: Google and Yahoo now support Creative-Commons image search based on RDFa (check out the Google video on how to add RDFa to your images). RDFa builds on existing technology, RDF, not because it’s the gospel but because it has some nice properties: you can reuse someone’s vocabulary if you want, or you can invent your own if you prefer. If you invent your own, there’s a little bit of overhead to prevent stepping on toes and to enable others to reuse your vocabulary if they choose. We don’t expect everyone to reuse all the time. We expect duplicate vocabularies to arise. But we do think it’s a good idea to make reuse possible, easy and scalable to the Web.

We absolutely do not expect a “densely connected web of semantically reconciled information” to “come together naturally.” But we do think that, when users want to build more densely connected semantically reconciled graphs, they should be able to.

This isn’t just a theory, it’s actually happening: Google is reusing Yahoo’s RDFa vocabulary intermixed with other vocabularies. They didn’t have to. Other groups at Google are making up their own vocabularies. And that’s okay: both approaches are part of a healthy Web-data ecosystem.

So, are we speculating too much on what’s going to happen next? I don’t think so. In fact, I think it’s quite the opposite: RDFa is giving users a choice, while other technologies are purposefully reducing choice. I call it overly opinionated software: being so certain that even slight future-proofing is pointless that you actually make it deliberately harder for your users. The criticism that Stefano offers actually applies the other way: solutions that de-emphasize Web-scale identifiers are reducing options by deciding that there shall be no meaningful, scalable reuse or distributed innovation. With RDFa, you have a choice. With a number of other technologies, you can’t choose to reuse / mash-up easily.

You said something about reconciliation

Now, one of many areas where I’ve learned quite a bit from Stefano, one where everyone in the Linked Data community should stop and listen, is reconciliation. RDF promises reconciliation, where one day Google and Yahoo will realize that google:author and yahoo:creator are actually the same thing, they’ll come together around a campfire somewhere between Mountain View and Santa Clara and sing Kumbaya by mapping each URL to the other. And Stefano is absolutely right to point out that this won’t be trivial when the data is not identically sampled, when strings contain much embedded structure that hasn’t been normalized. He summarizes this as:

I find it frankly disheartening that purists still believe that the secret to a useful web of data is already there in the guts of the architecture of the web and that by simply turning a URI into a URL will cause enough social pressure to solve the other issues.

I agree. The Linked Data community shouldn’t overpromise what same-as mappings will accomplish.

But take a step back: what is the other option? Having even less information about the vocabularies we use? Not having the ability to map vocabulary terms to one another? Once again, it’s an issue of choice: RDFa and RDF give you the ability to map concepts to one another. You don’t have to. You can ignore those features if you want. But isn’t it still a good idea to let users map concepts when they choose and when they can?

RDF and RDFa shouldn’t overpromise what reconciliation can deliver. At the same time, critics shouldn’t use the argument that, because RDF doesn’t solve all problems, then it solves none. Especially when the alternative solutions provide zero functionality in that department.

Who you callin’ Purist?

So here’s my take. The folks preventing reuse are the ones over-speculating. They are placing deliberate obstacles to vocabulary reuse, not because they are being cautious about the future, but because they think they know the future exactly, and they think that future doesn’t include vocabulary reuse. Meanwhile, contrary to popular belief, there are no RDFa cops watching over your shoulder, smacking you upside the head when you reinvent a term that FOAF or Dublin Core already specified. But there are RDFa genies, waiting to be invoked to help you reuse and augment FOAF and Dublin Core, if you want to.

With this added context, who’s the purist, really?

“No one wants to live in a surveillance society,” Zuckerberg adds, “which, if you take that to its extreme, could be where Google is going.”

Umm, seriously? I mean, sure, Google might be pushing us towards a surveillance society, but then, isn’t Facebook doing exactly the same thing? At least Google promises to remove your records after a certain period of time, whereas Facebook wants to keep your data forever for your friends’ sake. Interestingly, Zuckerberg repeatedly depicts other companies as potential evil entities, while Facebook is just the air your breathe, it could never be evil. So when the article points out that:

[Zuckerberg] has described Facebook as a once-in-a-century communications revolution, implying that he is right up there with Gutenberg and Marconi.

You have to stop and wonder… what if Gutenberg had said “here’s the printing press, but books can only be printed by me.” Or if Marconi had said “here’s the radio, all transmissions go through my central station, and I will relay them.”

Facebook is impressive, but in their model, all data goes through them. At least with Google, though they may keep my data for a while, I can switch search engines at any time. Yahoo is pushing the envelope every day. And Bing isn’t bad. But on Facebook, I can only do what Facebook is willing to let me do. So, if Google is a surveillance society, then Facebook is a surveillance society with a shock collar.

UPDATE: my metaphor at the end was slightly incomplete, so I tweaked it.

I want my blog to be used for education, training, and research. I hope that its contents appear in derivative works such as other blogs, websites, and wikis. I’d prefer that these derivative works be openly shared.

I would also ask that any material that is repurposed has attribution to me as the author.

Content from my blog should not be sold. Charging for access to that which I make freely available seems wrong.

How do I express these preferences legally?

Exactly! Now, if only health IT interchange specifications followed the same path. For example, HITSP, which aims to “enable healthcare interoperability”, has the following copyright statement:

No portion of the ANSI Sites may be reproduced in any form, electronic or otherwise, for any purpose other than personal use, without prior written permission of ANSI. To the extent that ANSI is not the copyright owner of some portion of an ANSI Site, ANSI has received permission to include such material in such ANSI Site.

The individual specifications might be a bit more lenient, but it’s not clear because they refer to other specifications’ individual copyright licensing terms, so you have to follow your nose to every sub-specification and figure out how to reconcile the terms from these disparate sources. Yeah.

Meanwhile, you have to pay to even see the Continuity of Care Record (CCR) standard. And HL7 licensing handwaves about how “strict copyright” is the only way they can maintain the integrity of their standard (untrue and likely ineffective), with a relatively amusing comparison of their per-download fee to “Apache and Linux distributions”, even though of course you can download Linux and Apache at no cost whatsoever, and you can redistribute them if you wish.

Just this week, there’s a new effort to give individuals control over their health data. I think it’s a great effort, but one of the necessary conditions to get there is to have truly open Health IT standards. No usage fees, no download fees, open licensing that enables others to innovate on top of the standards for novel medical applications, and probably a trademark approach to encouraging interoperability (i.e. you can’t call it “HL7″ unless you pass the HL7 test suite). There will not be widespread patient-controlled flow of health data until there are truly open Health IT standards.

John, if you’re listening, let’s bring that Creative Commons attitude to the Health Standards groups ASAP!