We’re just past halfway into the first year of the Open Referral Initiative, and I’ve just posted an updated version of our ‘Public Documentation’ — a living document that lays out the strategic framework of this project. You can read it here or in Github, and you can also comment and make suggestions in the Google Doc.
Generally speaking, the framework that was laid out at the commencement of this initiative has been validated by our pilot projects, subject matter specialists, and the participatory deliberation during our first workshop.
That said, a number of changes are worth noting. (Note: this gets wonky. You’ve been warned!)
Changed our first value from ‘open’ to ‘accessible.’
This is a bit of a semantic nit — and it is not meant to signal a move away from ‘open source,’ which is still our first principle. (Open source — and with it, open data — is the means by which we work to fulfill our values.) But ‘open’ is an ambiguous term, and that ambiguity can be problematic. ‘Accessibility,’ however, sufficiently conveys the point. As in, “this information should be accessible to everyone, in as many ways as possible.”
Added a fourth core ‘type of use’: data administration.
Our first three ‘types of use’ were seeking help, providing help, and research/analysis. (These types of use are the perspectives we take when thinking about what our values actually look like.) This first framework left out the perspective of ‘data administration’ itself. But people administering data are essential users in any effort to make data standardized and easier to access! So an effective data model, and the tools that use it, must meet the needs of those who do the technical work of data administration. [See here for more details about our ‘persona’ for data administration.]
We’ve simplified our structure and process, and we’re starting slow.
My initial proposal was complex and ambitious. Indeed, this problem is complex, and our mission is ambitious. But I’ve been helpfully reminded that healthy complex systems only emerge from successful simple systems. So we’ve kept it (relatively) simple.
On the technical side, this has primarily shown up in two choices about what we prioritize.
First: we’ve deferred questions of taxonomy, in terms of eligibility and type of service.
For now we recognize that users may use their own taxonomic methodology in conjunction with the Open Referral model. Future iterations of Open Referral may choose to take on this challenge more directly, but for now we consider it an orthogonal problem (i.e., it interconnects with our primary problem, but it’s not presently in our scope).
Second: we’ve deferred the establishment of compatibility with the National Information Exchange Model.
NIEM is an important component of our framework of interoperability, but our primary foundational objective is interoperability between AIRS and W3C. Open Referral is designed to be cyclical, and once we’ve had some success in validating a basic model, we will include the objective of ‘NIEMifying’ the service directory domain in subsequent iterations
On the procedural side, we streamlined the structure of the Working Group and the Local Pilots.
The initial proposal called for both the Work Group and the Local Pilots to each have four subgroups pursuing distinct objectives, but we’ve stepped back from that kind of structural complexity. The work group and our pilots are each pursuing multiple objectives in one group (well, in the San Francisco Bay there are more-or-less distinct groups in different counties). Locally, those objectives are: standardizing data, building open platforms, implementing/evaluating tools to use the data, and developing plans for sustainability/governance. Globally, the working group’s objectives are: conceptual design of the Open Referral model, technical design, implementation/evaluation, and sustainability/governance. More complex processes may be called for in the future, but for now we are defaulting to simplicity.
So those are the primary changes to date. They might seem trivial, and there is surely much more change to come. (As the saying goes: we walk slowly, because we are going far.)
It bears repeating that this is a living document, and it’s meant to be improved through reader feedback. Should something be clarified? Does something important seem to be missing? Please comment in the document, or open an issue in Github. Thanks 🙂 and onwards!
Leave a Reply