Roundup of feedback re: Open Referral scope/process/structure proposal

[Greg Bloom]

Hi folks - 

Long email ahead. For the majority of people who can't truck through long emails, here's a 'too long, didn't read' version (aka 'tl;dr') that should suffice:

I’m currently soliciting feedback on my joint proposals for a standards-development process and our local pilot implementations. This process will be iterative. Its first cycle (starting very soon) will be led by a working group including a balanced mix of perspectives, tasked with specific objectives. The local teams will implement and evaluate whatever comes out of this process, and the standards table will re-iterate based on the resulting feedback. We’ll evaluate this process over the course of regular check-ins and a series of summits. Within the next week, I’ll host an ‘Orientation’ video chat to run through all this face-to-faces and answer questions; a week later, I'll host an ‘Assembly’ video chat in which we’ll address any points that come up that require deliberation.

#

Okay! Diving deep:

Over the last couple of weeks, I’ve gotten some great feedback on my proposals for the structure/process of our ‘standards table’ and our ‘local teams.’ Most of this feedback came off-list, which is fine (though there were some interesting threads in the Bay Area google group that you might want to read) so I’ll synthesize here for discussion. 

There are a few recurring threads:

Semantics: how should we describe what we're doing? 

First (among many possible weeds to wade in): design vs architecture. My proposal for the Standards Table described the first half of its process as one of 1) conceptual architecture -> 2) technical architecture. Sophia Parafina of the Ohana team suggested that ‘architecture' suggests more structure than that which she thinks should be prescribed through the standard itself. We settled upon 'design' as an alternative — so right now the development part our plan reads: 1) Conceptual Design -> 2) Technical Design.  

Second: the concepts of ontology and logical models. Several of you have asserted that it’s crucial to develop an ontology, and a logical model, in order to accomplish our goals. However, several others have been (understandably) wary of the prospect of ontology development; most people (myself included) just aren't real clear what it means. Meanwhile, Sophia expressed aversion to the term ‘logical model,’ along the lines of her aversion to the prescriptive structure implied by ‘Architecture’ above. Well. I’m not trying to resolve this debate myself; I’m also not sure how much conflict really is here. It seems like there isn’t necessarily one right answer to the (meta-ontological) question of what our ontology should be. So let's keep things simple at the start. When we convene the working group that will develop the first iteration of our standard, they will simply be tasked with answering the following questions: given our mission and designated user types, what needs do our users have, and what requirements do those needs entail? What’s the minimal set of data types and relationships necessary to meet those needs? How should this model be implemented? How should it be tested? As the working group works to answer these questions, the participants will have some freedom to name and shape the outputs — the rest of us can rest assured that such decisions are not final, and in future cycles will be subject to evaluation and revision. 

Product vision vs initial scope - several people pointed out that the rather complex scope detailed in the proposal may not be necessary to fully develop in our initial cycle. In this first round, we don’t expect to get it 100% right, or even fully articulated. (For example, several people have emphatically asserted that we should aim to build this standard into the National Information Exchange Model and the associated National Human Services Information Architecture… but in the short term, our pilot projects aren't likely to identify this as an immediate priority, so unless the working group includes someone with the skills and energy to build it out as such, it probably won’t happen — and that’s okay. We can aim to accomplish it in future cycles.) All we need from this first cycle is a minimally-viable set of artifacts that can enable our pilot projects to successfully circulate resource data across heterogeneous systems.

Roles - In the proposal, I identify separate sets of key participants for each phase of the standards development. To keep things simple as we get our bearings, we’ll just have one working group for this first cycle. Sophia Parafina from the Ohana team will take a lead technical development role (as I understand it - her role will be synthesizing inputs and modeling, though these are my words, not hers). I will be co-facilitating, and we’re going to seek at least one lead ‘subject matter expert’ with technical experience who can commit some substantial amount of time. Sophia suggests a working group of seven designated participants (not including herself or myself) representing a mix of stakeholder interests (i.e. community anchor institutions and user groups), academics and other subject matter experts, vendors, legacy I&Rs and startups. If anyone else would like to step up to hammer out more details proposal for the working group with Sophia and I, let me know. I’ll start a thread on this specifically either later this week or early next.

Communication - My proposals are largely silent on the matter of communication. This will be something we figure out together. Broadly speaking, we’re going to use a mix of listservs, regular virtual meetings, and a series of regional summits. The open questions here branch in all directions — from the strategy and responsibilities of the openreferral.org website, to the listservs themselves (should the working group have its own? if so, is Google Groups the best tool for this? how will the local teams and standards groups communicate to each other? etc.), to the technical documentation (Google docs or Hackpad? How do our repositories in github correspond with those documents and each other?) To an extent, some of these questions I’m going to put to the groups themselves, while clarifying options and and aligning preferences. It bears repeating: your suggestions are welcome.

Two additions here that should probably be added into these documents: 

1) I’m going to start hosting regular virtual convenings for interested participants of all stripes (this is separate from the local teams and standards working group). One will be ORIENTATION, for new folks to learn and ask questions and get caught up to speed. The other will be ASSEMBLY, where we’ll take up any active matters that require more deliberation than that which we can hash out over email. I’ll start this process this week or early next, with an ORIENTATION; ASSEMBLY will follow the following week.

2) We’re planning our first summit for June, in the Bay Area. This will be a relatively small gathering focused on preparing our local Bay Area team (and DC team) to implement, test and evaluate the Open Referral spec. There will be a travel budget for active members of the working group who are based outside of SF or DC. 

More details on both of these coming soon.

Finally, I think we should add into this public documentation a set of assumptions that we are explicitly naming and planning to test. Here are the assumptions I’m making and remaining conscious of: 

• Interoperability between AIRS / 2-1-1 standards (schema/taxonomy) and new standards such as the W3C civic services schema is possible.
  
• Data standards are a necessary and effective step towards making community resource directory data openly available. Standards will also help spur innovation, lower the cost of development, and strengthen a community of practice in this field.
  
• The production of open community resource directory data can be sustainable.
  
• Communities already have most if not all of the resources that they need to sustainably produce reliable open data. But these resources are currently trapped in silos, and it will require both technological development and social facilitation to break down those silos.
  
• The cost of maintaining up-to-date resource data can be lowered by opening systems to receive input from users.
  
• The cost of data upkeep will not drop to zero, and some designated steward of the data is important to ensure reliability and accountability. 
  
• Local stakeholders can play a leading role in researching, proposing, and implementing plans to achieve that sustainability.
  

Thanks for reading thus far. As long as this is, I’m sure it’s not exhaustive — so if there’s something else you’d like to see discussed at this point in time, let’s have at it. 

~greg

[Clive Jones]

Greg,

Thanks for the huge email and for all your work on this project ... there is a lot going on ... and a lot to keep tabs on. And I am finding that pretty hard!

I think that your list of assumptions are very important and I wonder if everyone reads them and takes the same meaning from them ... I must admit I sometimes feel confused about some of this and what its relationship is with things that already exist. 

From the AIRS/211 point-of-view, we see this project as an opportunity to work with people who know what they are doing on the technology/data front in order to provide organizations (government, nonprofit and commercial) that maintain community resource information with the opportunity to dramatically increase the portability/accessibility of community information by allowing it to move (with permission) onto open platforms and therefore onto other systems/applications -- so it can help more people in more ways. And for these open standards to link up with similar open standards such as Open311 and NIEM. We appreciate that this is not being done "for us" but for the communities we serve. 

I think this is the same project!

I (and I believe others) are OK with having some of our long-time assumptions challenged and tested, as long as the final results are based on things which are as verifiable and practical as possible. 

• Interoperability between AIRS / 2-1-1 standards (schema/taxonomy) and new standards such as the W3C civic services schema is possible (Clive: The project is to create open data community resource standards that would allow existing data sources such as I&R/AIRS/211 to be interoperable with other human services systems and applications. And for any new data sources that emerge to adopt the same structure. Is this the same thing?)
• 
  
• Data standards are a necessary and effective step towards making community resource directory data openly available. Standards will also help spur innovation, lower the cost of development, and strengthen a community of practice in this field. (Clive: What are data standards in this context? Are they related to data management? Or arrangements of data elements/attributes? What is a community of practice that is different from one that already exists?)
  
• 
  
• The production of open community resource directory data can be sustainable. (Clive: I would go with "more sustainable" for yes ...)
  
• Communities already have most if not all of the resources that they need to sustainably produce reliable open data. But these resources are currently trapped in silos, and it will require both technological development and social facilitation to break down those silos.(Clive: Existing resource databases need technological innovation and genuine partnerships to allow them to become accessible in more ways, to more people in more places. ... is this the same thing? And if it is, can you see why it is different?!)
  
• 
  
• The cost of maintaining up-to-date resource data can be lowered by opening systems to receive input from users.(Clive: As mentioned a few times, virtually all of the software currently used by I&R agencies allows listed organizations to access their data and submit changes, and for change requests to be pushed out directly to those organizations and often for anyone using the public site to submit information based on their experience "I phoned and it said it was closed". I am not sure what dramatically changes with this 'change'. Maybe there will be an increased visibility impact as more folks become conscious of the data - although there is an impact on the other side of the equation as the more info coming in, the more management of it that is required - but having more accurate data is obviously a good thing)
  
• The cost of data upkeep will not drop to zero, and some designated steward of the data is important to ensure reliability and accountability. (Clive: I don't think it will drop at all but I would be happy if it did so. I wonder if this is a disconnect with the concept of data standards ... I&Rs have data standards that yes, makes the work more challenging in order to make the data more clear and concise. Does this project surmise that this will no longer be happening?)
  

• 
  
• Local stakeholders can play a leading role in researching, proposing, and implementing plans to achieve that sustainability.

--
You received this message because you are subscribed to the Google Groups "OpenReferral" group.
To unsubscribe from this group and stop receiving emails from it, send an email to OpenReferral...@googlegroups.com.
To post to this group, send email to OpenRe...@googlegroups.com.
Visit this group at http://groups.google.com/group/OpenReferral.
For more options, visit https://groups.google.com/d/optout.

--
Clive Jones
AIRS
www.airs.org
www.twitter.com/AIRSplace

[Greg Bloom]

Hi Clive - 

Sorry to have slept on your response - been traveling. 

It seems to me like we are more or less in alignment :)

I think you ask some great questions here that I want to pull out (I could offer some answers myself, but after that whopper of an email above, I'd just as soon hear from some of the other folks on this list - anyone want to chime in?).

I&Rs have data standards that make the work more challenging in order to make the data more clear and concise. Does this project surmise that this will no longer be happening? What are data standards in this context? Are they related to data management? Or arrangements of data elements/attributes? What is a community of practice that is different from one that already exists? 

Clive, I encourage you (and others) to formulate more questions like these. Some will be readily answerable; some will hang with us as open questions, and that will help focus the course of this work. (In particular, I think you're gesturing towards something important in your comments about the difference between 'breaking down silos' and 'technological innovation and genuine partnerships.' Can you elaborate?)

Lastly (for now) it sounds like one of the assumptions that you're most skeptical of is that open platforms can reduce the cost of data maintenance by generating distributed user feedback regarding data accuracy. And I'm intrigued by your suggestion that the objectives of lower costs and data standards might actually be at odds. Do any open-data proponents want to offer a more detailed hypothesis here?

~greg

[Greg Bloom]

Folks - sorry for the triple-email blitz, just trying to cram a bunch of updates together in a way that keeps people abreast. 

I want to share here a few changes to our public documentation that I’ve made based on feedback from this group and beyond. To many, these may seem like wonky nuances. But a couple of these changes simplify our work, and one complexifies (in a way that I think is helpful). 

To start, a semantic tweak to the overall frame of the work that will be done in view of this group: I've changed the language in my proposal about a 'standards table' to a 'working group.' The talk about a 'standards table’ where we will develop 'a new standard' has confused some, and I think the concern is valid. Our goal is indeed the establishment of new standards, but our approach may seem different from conventional standards-development undertakings. This process will be anchored in pilot projects and centered around stakeholder engagement. So we should be careful to note that what we are producing can only be called a 'standard' when it's being widely adopted (duh) -- and until then, we should probably describe our work as producing a 'common model' and/or 'open format.’ I've changed some documents but if you spot this language elsewhere, let's examine and clarify if necessary.

Semantic nit picked out of the way, now for the procedural changes:

First, my original document proposed four different working groups to each take on its own phase of work (Conceptual Design, Technical Design, Implementation/Evaluation, Sustainability/Governance). That may eventually be a viable structure, but for now to keep things simple, we're going to integrate all four different branches of work as different phases of one working group. (I detail this at greater length in the email I sent out a few minutes ago.)

Second, as mentioned before, we're identifying that our long-term vision does include big challenges like establishing compatibility with the National Information Exchange Model, and development of a methodology for sorting service types (presumably this entails some alternative that is interoperable with the existing AIRS taxonomy, or an evolution of the AIRS taxonomy into an open source product), but ultimately these may be outcomes of a longer-term process -- not necessarily something we can or should try to establish out of the gate. In this first cycle, we will focus specifically on producing a minimal set of artifacts and tools that our pilot projects (and anyone else trying to establish open, interoperable directory platforms) need to advance toward their goals.

Third, a compelling case has been made to me that we should add one 'user type' to our core set: ‘database worker.’ (I’d welcome suggestions of better phrases for this.) This could range from actual IT staff to a volunteer civic hacker. Someone who needs to be able to understand and use the model, if it is to work. That brings our user types to a core four -- 'help seeker,' 'service provider,' 'analyst,' and 'info-sys manager' -- and user stories and evaluations from each of these types will direct and check our work on the common model. 

That’s all for now - thanks for your thoughtful feedback so far. 

~greg