"Can we just meet up whenever most people can, videotape it and others
can watch to catch up and participate next time? Finding consensus on
meet times for this many people will probably never happen. Thoughts?"
I am encouraging people who are interested in leading ChangeCamp
projects to use this list and the wiki to find one another and
organize. I'm having moderate success with live-streaming and
recording meetings with ustream.tv.
So, the ChangeEngine folks should really start to think about who's
got a real passion for the project and want to form a tight little
crew. I see my role as one of providing support, context and
connections as needed.
We have the technology, all we need is people to step up and lead.
What's next??
Mark.
On Feb 19, 2:33 pm, pkeenan <interfa...@gmail.com> wrote:
> "Can we just meet up whenever most people can, videotape it and others
> can watch to catch up and participate next time? Finding consensus on
> meet times for this many people will probably never happen. Thoughts?"
In an effort to keep up some kind of momentum on this, I'd like to
propose that we have a guaranteed meet next week. Let's survey for
availability, and just go with the best option. Whoever can't make it
can watch the video afterwards.
I'm also thinking since we all have such busy schedules, perhaps we'd
be best off to pick a regular day/time for bi-weeklies or monthlies so
that there's enough advance notice to slot them in.
> "Can we just meet up whenever most people can, videotape it and others
> can watch to catch up and participate next time? Finding consensus on
> meet times for this many people will probably never happen. Thoughts?"
Was writing my post while you were writing yours...Would you prefer
that we start a new GoogleGroup for ChangeEngine to keep the clutter
out of the main ChangeCamp group?
Adam
On Feb 20, 10:08 am, Mark Kuznicki <mark.kuzni...@gmail.com> wrote:
> I am encouraging people who are interested in leading ChangeCamp
> projects to use this list and the wiki to find one another and
> organize. I'm having moderate success with live-streaming and
> recording meetings with ustream.tv.
> So, the ChangeEngine folks should really start to think about who's
> got a real passion for the project and want to form a tight little
> crew. I see my role as one of providing support, context and
> connections as needed.
> We have the technology, all we need is people to step up and lead.
> What's next??
> Mark.
> On Feb 19, 2:33 pm, pkeenan <interfa...@gmail.com> wrote:
> > And I quote Mr. Thody:
> > "Can we just meet up whenever most people can, videotape it and others
> > can watch to catch up and participate next time? Finding consensus on
> > meet times for this many people will probably never happen. Thoughts?"
I would use this main Group to find one another, engage stakeholders,
solicit feedback. Once things get going, you can fork to another
Group, but I'd take the time for the core team to find itself.
Also @changecamp on Twitter for anything you might want retweeting the
whole ChangeCamp community on Twitter.
Thanks for taking the initiative!
Mark.
On Feb 20, 10:34 am, Thody <adam.th...@gmail.com> wrote:
> Was writing my post while you were writing yours...Would you prefer
> that we start a new GoogleGroup for ChangeEngine to keep the clutter
> out of the main ChangeCamp group?
> Adam
> On Feb 20, 10:08 am, Mark Kuznicki <mark.kuzni...@gmail.com> wrote:
> > Patrick,
> > I am encouraging people who are interested in leading ChangeCamp
> > projects to use this list and the wiki to find one another and
> > organize. I'm having moderate success with live-streaming and
> > recording meetings with ustream.tv.
> > So, the ChangeEngine folks should really start to think about who's
> > got a real passion for the project and want to form a tight little
> > crew. I see my role as one of providing support, context and
> > connections as needed.
> > We have the technology, all we need is people to step up and lead.
> > What's next??
> > Mark.
> > On Feb 19, 2:33 pm, pkeenan <interfa...@gmail.com> wrote:
> > > And I quote Mr. Thody:
> > > "Can we just meet up whenever most people can, videotape it and others
> > > can watch to catch up and participate next time? Finding consensus on
> > > meet times for this many people will probably never happen. Thoughts?"
> I would use this main Group to find one another, engage stakeholders,
> solicit feedback. Once things get going, you can fork to another
> Group, but I'd take the time for the core team to find itself.
> Also @changecamp on Twitter for anything you might want retweeting the
> whole ChangeCamp community on Twitter.
> Thanks for taking the initiative!
> Mark.
> On Feb 20, 10:34 am, Thody <adam.th...@gmail.com> wrote:
> > Hey Mark,
> > Was writing my post while you were writing yours...Would you prefer
> > that we start a new GoogleGroup for ChangeEngine to keep the clutter
> > out of the main ChangeCamp group?
> > Adam
> > On Feb 20, 10:08 am, Mark Kuznicki <mark.kuzni...@gmail.com> wrote:
> > > Patrick,
> > > I am encouraging people who are interested in leading ChangeCamp
> > > projects to use this list and the wiki to find one another and
> > > organize. I'm having moderate success with live-streaming and
> > > recording meetings with ustream.tv.
> > > So, the ChangeEngine folks should really start to think about who's
> > > got a real passion for the project and want to form a tight little
> > > crew. I see my role as one of providing support, context and
> > > connections as needed.
> > > We have the technology, all we need is people to step up and lead.
> > > What's next??
> > > Mark.
> > > On Feb 19, 2:33 pm, pkeenan <interfa...@gmail.com> wrote:
> > > > And I quote Mr. Thody:
> > > > "Can we just meet up whenever most people can, videotape it and others
> > > > can watch to catch up and participate next time? Finding consensus on
> > > > meet times for this many people will probably never happen. Thoughts?"
Can you add some evening times to see when people are available as
well? I could probably swing early morning but my brain doesn't
usually start working creatively until at least 10/11.
On Feb 20, 12:36 pm, Thody <adam.th...@gmail.com> wrote:
> FYI all, I'm happy to offer up The Blog Studio as a venue for these
> meets. We're at Queen & Spadina, so it's fairly central location.
> '
> Adam
> On Feb 20, 10:42 am, Mark Kuznicki <mark.kuzni...@gmail.com> wrote:
> > Adam,
> > I would use this main Group to find one another, engage stakeholders,
> > solicit feedback. Once things get going, you can fork to another
> > Group, but I'd take the time for the core team to find itself.
> > Also @changecamp on Twitter for anything you might want retweeting the
> > whole ChangeCamp community on Twitter.
> > Thanks for taking the initiative!
> > Mark.
> > On Feb 20, 10:34 am, Thody <adam.th...@gmail.com> wrote:
> > > Hey Mark,
> > > Was writing my post while you were writing yours...Would you prefer
> > > that we start a new GoogleGroup for ChangeEngine to keep the clutter
> > > out of the main ChangeCamp group?
> > > Adam
> > > On Feb 20, 10:08 am, Mark Kuznicki <mark.kuzni...@gmail.com> wrote:
> > > > Patrick,
> > > > I am encouraging people who are interested in leading ChangeCamp
> > > > projects to use this list and the wiki to find one another and
> > > > organize. I'm having moderate success with live-streaming and
> > > > recording meetings with ustream.tv.
> > > > So, the ChangeEngine folks should really start to think about who's
> > > > got a real passion for the project and want to form a tight little
> > > > crew. I see my role as one of providing support, context and
> > > > connections as needed.
> > > > We have the technology, all we need is people to step up and lead.
> > > > What's next??
> > > > Mark.
> > > > On Feb 19, 2:33 pm, pkeenan <interfa...@gmail.com> wrote:
> > > > > And I quote Mr. Thody:
> > > > > "Can we just meet up whenever most people can, videotape it and others
> > > > > can watch to catch up and participate next time? Finding consensus on
> > > > > meet times for this many people will probably never happen. Thoughts?"
> Can you add some evening times to see when people are available as
> well? I could probably swing early morning but my brain doesn't
> usually start working creatively until at least 10/11.
> On Feb 20, 12:36 pm, Thody <adam.th...@gmail.com> wrote:
> > FYI all, I'm happy to offer up The Blog Studio as a venue for these
> > meets. We're at Queen & Spadina, so it's fairly central location.
> > '
> > Adam
> > On Feb 20, 10:42 am, Mark Kuznicki <mark.kuzni...@gmail.com> wrote:
> > > Adam,
> > > I would use this main Group to find one another, engage stakeholders,
> > > solicit feedback. Once things get going, you can fork to another
> > > Group, but I'd take the time for the core team to find itself.
> > > Also @changecamp on Twitter for anything you might want retweeting the
> > > whole ChangeCamp community on Twitter.
> > > Thanks for taking the initiative!
> > > Mark.
> > > On Feb 20, 10:34 am, Thody <adam.th...@gmail.com> wrote:
> > > > Hey Mark,
> > > > Was writing my post while you were writing yours...Would you prefer
> > > > that we start a new GoogleGroup for ChangeEngine to keep the clutter
> > > > out of the main ChangeCamp group?
> > > > Adam
> > > > On Feb 20, 10:08 am, Mark Kuznicki <mark.kuzni...@gmail.com> wrote:
> > > > > Patrick,
> > > > > I am encouraging people who are interested in leading ChangeCamp
> > > > > projects to use this list and the wiki to find one another and
> > > > > organize. I'm having moderate success with live-streaming and
> > > > > recording meetings with ustream.tv.
> > > > > So, the ChangeEngine folks should really start to think about who's
> > > > > got a real passion for the project and want to form a tight little
> > > > > crew. I see my role as one of providing support, context and
> > > > > connections as needed.
> > > > > We have the technology, all we need is people to step up and lead.
> > > > > What's next??
> > > > > Mark.
> > > > > On Feb 19, 2:33 pm, pkeenan <interfa...@gmail.com> wrote:
> > > > > > And I quote Mr. Thody:
> > > > > > "Can we just meet up whenever most people can, videotape it and others
> > > > > > can watch to catch up and participate next time? Finding consensus on
> > > > > > meet times for this many people will probably never happen. Thoughts?"
> Can you add some evening times to see when people are available as
> well? I could probably swing early morning but my brain doesn't
> usually start working creatively until at least 10/11.
> On Feb 20, 12:36 pm, Thody <adam.th...@gmail.com> wrote:
> > FYI all, I'm happy to offer up The Blog Studio as a venue for these
> > meets. We're at Queen & Spadina, so it's fairly central location.
> > '
> > Adam
> > On Feb 20, 10:42 am, Mark Kuznicki <mark.kuzni...@gmail.com> wrote:
> > > Adam,
> > > I would use this main Group to find one another, engage stakeholders,
> > > solicit feedback. Once things get going, you can fork to another
> > > Group, but I'd take the time for the core team to find itself.
> > > Also @changecamp on Twitter for anything you might want retweeting the
> > > whole ChangeCamp community on Twitter.
> > > Thanks for taking the initiative!
> > > Mark.
> > > On Feb 20, 10:34 am, Thody <adam.th...@gmail.com> wrote:
> > > > Hey Mark,
> > > > Was writing my post while you were writing yours...Would you prefer
> > > > that we start a new GoogleGroup for ChangeEngine to keep the clutter
> > > > out of the main ChangeCamp group?
> > > > Adam
> > > > On Feb 20, 10:08 am, Mark Kuznicki <mark.kuzni...@gmail.com> wrote:
> > > > > Patrick,
> > > > > I am encouraging people who are interested in leading ChangeCamp
> > > > > projects to use this list and the wiki to find one another and
> > > > > organize. I'm having moderate success with live-streaming and
> > > > > recording meetings with ustream.tv.
> > > > > So, the ChangeEngine folks should really start to think about who's
> > > > > got a real passion for the project and want to form a tight little
> > > > > crew. I see my role as one of providing support, context and
> > > > > connections as needed.
> > > > > We have the technology, all we need is people to step up and lead.
> > > > > What's next??
> > > > > Mark.
> > > > > On Feb 19, 2:33 pm, pkeenan <interfa...@gmail.com> wrote:
> > > > > > And I quote Mr. Thody:
> > > > > > "Can we just meet up whenever most people can, videotape it and others
> > > > > > can watch to catch up and participate next time? Finding consensus on
> > > > > > meet times for this many people will probably never happen. Thoughts?"
Thody wrote: > Was writing my post while you were writing yours...Would you prefer > that we start a new GoogleGroup for ChangeEngine to keep the clutter > out of the main ChangeCamp group?
Is ChangeEngine another name for the Shame Engine?
Perhaps we can divide out into 3 teams like we did at Changelab...
Technical, UI/UX, marketing (or whatever makes sense at this stage).
Each team can meet separately and when we hold combined meetings,
there need only be some people representing each team.
Focusing might also stimulate our creativity and productivity, and if
some people can't make it one day we still move ahead.
There needs to be a definite scope for the project first, but we can
do that at the next meeting.
> Perhaps we can divide out into 3 teams like we did at Changelab...
> Technical, UI/UX, marketing (or whatever makes sense at this stage).
> Each team can meet separately and when we hold combined meetings,
> there need only be some people representing each team.
> Focusing might also stimulate our creativity and productivity, and if
> some people can't make it one day we still move ahead.
> There needs to be a definite scope for the project first, but we can
> do that at the next meeting.
I think there's a movement away "Shame Engine" as the public moniker
for the project because it makes the concept a little too negative.
The tool will do more than shame people/gov, it can also be a way to
map solutions and constructive dialogue.
> Yes, Shame Engine is now Change Engine. I can't recall how/why/when
> that transition actually took place. Anyone?
> On Feb 21, 5:42 pm, Michael Allan <m...@zelea.com> wrote:
>> MarkRabo wrote:
>>> There needs to be a definite scope for the project first, but we can
>>> do that at the next meeting.
>> But do tell us *roughly* what it's all about, since we are
>> confused. :-)
>> Is ChangeEngine just another name for the Shame Engine?
I suggested to Ryan that ChangeEngine will engage stakeholders, which
of course includes public servants at the City and politicos. The
cheekiness of "ShameEngine" is pretty funny when you get the tone of
it, but it's just lost in text and online on its own, so I say dump it.
We're getting some good ideas for self-organization principles from
Tonya Surman's Constellation Model and from Gerry Kirk's Agile
coaching expertise. Have a look at Tonya's paper on the Constellation
Model, and watch the (114 minute long) live-stream capture of the
future of ChangeCamp strat session. She explains the model at 30:00 or
so.
> Yes, Shame Engine is now Change Engine. I can't recall how/why/when
> that transition actually took place. Anyone?
> On Feb 21, 5:42 pm, Michael Allan <m...@zelea.com> wrote:
>> MarkRabo wrote:
>>> There needs to be a definite scope for the project first, but we can
>>> do that at the next meeting.
>> But do tell us *roughly* what it's all about, since we are
>> confused. :-)
>> Is ChangeEngine just another name for the Shame Engine?
> I think there's a movement away "Shame Engine" as the public moniker > for the project because it makes the concept a little too negative. > The tool will do more than shame people/gov, it can also be a way to > map solutions and constructive dialogue.
Nice. And in parallel with that - measuring people's *agreement* to those solutions - that's my own domain. The two domains (problem transparency and solution consensus) are orthogonal. But I suspect there'll be some important cross-domain relations, and some public APIs to support them. In general, there's going to be an open ecosystem of all this stuff... Which leads me to ask Mark for advice:
Mark Kuznicki wrote: > So, the ChangeEngine folks should really start to think about who's > got a real passion for the project and want to form a tight little > crew. I see my role as one of providing support, context and > connections as needed.
> We have the technology, all we need is people to step up and lead.
Re context: Is it too early to start thinking about the framework for developing those public APIs? It's not a technical question, at this point. It goes beyond any specific relations between Shamen and Votorola, too. I'm guessing it's more a question of transparency - of having an open and trustworthy process of standards development. My thinking is explained here:
The reason why I think it's *not* too early, is because it would be a huge boost for all of us change projects, if we had a way to come together (technically), and show that we're bigger than the sum of our parts. Do you get me? Imagine that tomorrow a gaggle of us projects - some competitive, some cooperative - managed to reach a rough agreement on some common technical standard (it doesn't matter what, it could be quite trivial). Just the fact of it, the signal it would send - you understand the significance - it would take us to a new level.
Is it too early? You see how simple a transparency framework I proposed in that thread - just some RDF and scripts. But you also see what I'm up against - a wall of head-butting competitors, each looking out for their own turf, and intent on ruling the world.
On Sat, Feb 21, 2009 at 9:54 PM, Michael Allan <m...@zelea.com> wrote:
> Re context: Is it too early to start thinking about the framework for > developing those public APIs? It's not a technical question, at this > point. It goes beyond any specific relations between Shamen and > Votorola, too. I'm guessing it's more a question of transparency - of > having an open and trustworthy process of standards development. My > thinking is explained here:
> The reason why I think it's *not* too early, is because it would be a > huge boost for all of us change projects, if we had a way to come > together (technically), and show that we're bigger than the sum of our > parts. Do you get me? Imagine that tomorrow a gaggle of us projects > - some competitive, some cooperative - managed to reach a rough > agreement on some common technical standard (it doesn't matter what, > it could be quite trivial). Just the fact of it, the signal it would > send - you understand the significance - it would take us to a new > level.
> Is it too early? You see how simple a transparency framework I > proposed in that thread - just some RDF and scripts. But you also see > what I'm up against - a wall of head-butting competitors, each looking > out for their own turf, and intent on ruling the world.
There's a real danger of premature optimization here, of specifying standards before the problem is really understood. However, here is a stab at how I've seen successful APIs and data sharing develop on the web in the mashup world.
The core "frameworks" are POSH, REST and JSON. POSH [1] is "Plain Old Semantic HTML", meaning websites should be developed using modern web standards, pages should valid, pages use HTML elements correctly and presentation is coded using CSS. REST [2] can have deeper implications, but amongst the simplest implications is that pages can be returned using simple GET statements against a URL. JSON [3] has emerged as the defacto standard for returning API results, amogst the reasons for is simplicity of creating mashups and embeddability.
Atom and/or RSS provide the framework for update notifications. There are emerging technologies for real-time delivery, but it's too early to worry about that.
Microformats [4] provide a framework for embedding well-understood objects in HTML, are based on popular and well-understood standards, are easy(-ish) to implement, and a "consumer" ecosystem exists. In particular, people can be represented by hCard [5], events by hCalendar [6], tagged data by rel-tag [7] and microcontent (articles within a page) by hAtom [8]. Note that no "parallel" infrastructure need exist to do microformats: they are served within HTML pages.
Identify should use OAuth [9] and OpenID [10]; pragmatism says Facebook Connect and Google Friend Connect should be in the mix too, though I have a number of reservations about those.
I am very non-bullish about RDF [11]. IMHO it has missed almost the entirely the mashup wave of the last few years, and successes seem to be scattered at best. RDFa is competing in microformat's "space" and may see success yet if it starts proving concrete solutions rather than "here's a format that can do anything".
Instead of worrying about JSON vs. XML vs. RDL, why not just say
'machine readable API' and make the policy forward compatable? The
best technology solution(s) will depend on the application. Sites
that want to use the data can adapt easily enough.
For reference, at VisibleGovernment.ca we've been kicking around
technology constraints for software we fund. The most recent version
is:
* Software developed with VisibleGovernment.ca grants must be
released under an open source liscense. The MIT liscense is
preferred.
* Non-user related data must be exposed via machine readable
APIs.
* Sites requiring a user login must support OpenID.
* Sites requiring a friend list should use OpenSocial.
Also, there is a requirement to cross-promote VisibleGovernment.ca,
and other funded sites, during seasonal drives.
> The core "frameworks" are POSH, REST and JSON. POSH [1] is "Plain Old
> Semantic HTML", meaning websites should be developed using modern web
> standards, pages should valid, pages use HTML elements correctly and
> presentation is coded using CSS. REST [2] can have deeper implications, but
> amongst the simplest implications is that pages can be returned using simple
> GET statements against a URL. JSON [3] has emerged as the defacto standard
> for returning API results, amogst the reasons for is simplicity of creating
> mashups and embeddability.
> Atom and/or RSS provide the framework for update notifications. There are
> emerging technologies for real-time delivery, but it's too early to worry
> about that.
> Microformats [4] provide a framework for embedding well-understood objects
> in HTML, are based on popular and well-understood standards, are easy(-ish)
> to implement, and a "consumer" ecosystem exists. In particular, people can
> be represented by hCard [5], events by hCalendar [6], tagged data by rel-tag
> [7] and microcontent (articles within a page) by hAtom [8]. Note that no
> "parallel" infrastructure need exist to do microformats: they are served
> within HTML pages.
> Identify should use OAuth [9] and OpenID [10]; pragmatism says Facebook
> Connect and Google Friend Connect should be in the mix too, though I have a
> number of reservations about those.
> I am very non-bullish about RDF [11]. IMHO it has missed almost the entirely
> the mashup wave of the last few years, and successes seem to be scattered at
> best. RDFa is competing in microformat's "space" and may see success yet if
> it starts proving concrete solutions rather than "here's a format that can
> do anything".
On Sun, Feb 22, 2009 at 1:16 PM, Jennifer Bell <visiblegovernm...@gmail.com>wrote:
> Instead of worrying about JSON vs. XML vs. RDL, why not just say > 'machine readable API' and make the policy forward compatable? The > best technology solution(s) will depend on the application. Sites > that want to use the data can adapt easily enough.
I don't think that can be stressed enough that producing standards compliant, accessible, semantic HTML delivered via HTTP GET is the first step in web openness.
Just for a concrete example, to show that I'm not so much concerned with standards of transparency, but the reverse - transparency of standards:
1. Project Votorola has an idea for a public standard S (for storage/transmission of social data, or whatever). So we use the transparency facility to say, "Hello, here is standard S! Votorola will support S."
2. Project Shamen learns of S through the transparency facility (transparent, because it makes S visible). They think S could be useful, so they say, "Shamen will support S." (Meanwhile, the two projects are talking together, and making improvements to S.)
3. Other projects learn that both Votorola and Shamen have agreed (tentatively) to S. So they're thinking about it, too. They each decide for themselves, and they say, "we will/will not support S."
And so on, for all the people, projects, firms, organizations, etc., and all the standards they propose.
That's it - just transparency. (But that's everything, IMHO.)
David Janes wrote: > There's a real danger of premature optimization here, of specifying > standards before the problem is really understood...
It's possible, the domain might get hide-bound from premature standardization. (Mind, that's always a problem, even in a mature domain.)
Then again, if we have a standards process that's transparent, maybe it'll be proof against rigidity? I mean, engineers are always coming up with ideas on how to escape from constraints - pushing the envelope - right? So there's always grassroots initiative from that side. But it's rarely made *visible* in public. Usually it's only the organizations (like standards consortia) that have a sufficient public presence. But they have a different dynamic, and often a different motivation. And often (but not always), it's *they* who are hide-bound.
> ... However, here is a stab > at how I've seen successful APIs and data sharing develop on the web in the > mashup world.
> The core "frameworks" are POSH, REST and JSON. POSH [1] is "Plain Old > Semantic HTML", meaning websites should be developed using modern web > standards, pages should valid, pages use HTML elements correctly and > presentation is coded using CSS. REST [2] can have deeper implications, but > amongst the simplest implications is that pages can be returned using simple > GET statements against a URL. JSON [3] has emerged as the defacto standard > for returning API results, amogst the reasons for is simplicity of creating > mashups and embeddability.
> Atom and/or RSS provide the framework for update notifications. There are > emerging technologies for real-time delivery, but it's too early to worry > about that.
> Microformats [4] provide a framework for embedding well-understood objects > in HTML, are based on popular and well-understood standards, are easy(-ish) > to implement, and a "consumer" ecosystem exists. In particular, people can > be represented by hCard [5], events by hCalendar [6], tagged data by rel-tag > [7] and microcontent (articles within a page) by hAtom [8]. Note that no > "parallel" infrastructure need exist to do microformats: they are served > within HTML pages.
> Identify should use OAuth [9] and OpenID [10]; pragmatism says Facebook > Connect and Google Friend Connect should be in the mix too, though I have a > number of reservations about those.
> I am very non-bullish about RDF [11]. IMHO it has missed almost the entirely > the mashup wave of the last few years, and successes seem to be scattered at > best. RDFa is competing in microformat's "space" and may see success yet if > it starts proving concrete solutions rather than "here's a format that can > do anything".
(Interesting. I'm just learning RDF. I'll look at Microformats, before I commit to it.)
Maybe Microformats is an exception, but the rest are mostly general-purpose standards. As such, they'll definitely be in the "foundation mix" of whatever specialized standards emerge in the political domain.
But it's that emergence - the seeding and growth process - that I want to spotlight. In the case of the above standards, it was shrouded in darkness. (Otherwise, maybe the ridiculousness of SOAP wouldn't have been foisted on us. Maybe we'd have chosen REST, right from the start. If only we knew that a choice was being called for - if only there was sufficient transparency.)
Jennifer Bell wrote: > Instead of worrying about JSON vs. XML vs. RDL, why not just say > 'machine readable API' and make the policy forward compatable? The > best technology solution(s) will depend on the application. Sites > that want to use the data can adapt easily enough.
> For reference, at VisibleGovernment.ca we've been kicking around > technology constraints for software we fund. The most recent version > is:
> * Software developed with VisibleGovernment.ca grants must be > released under an open source liscense. The MIT liscense is > preferred. > * Non-user related data must be exposed via machine readable > APIs. > * Sites requiring a user login must support OpenID. > * Sites requiring a friend list should use OpenSocial.
> Also, there is a requirement to cross-promote VisibleGovernment.ca, > and other funded sites, during seasonal drives.
I'll leave out the last item (cross-promo), because it's a contractual obligation between two parties. What's left is a kind of umbrella, or composite, standard. Call it U. It requires:
* compliance with certain other standards, namely ...
* following additional practices, namely ...
Now, assume we already have a transparent process of standards proposal. Then your own change project (VisibleGovernment.ca) could use it to propose U as a standard, and make it visible to the other projects. You'd then learn which of them was, in principle, happy with it. Would that information be useful to you?
On the other hand, would U's visibility be useful to the other projects? I guess they'd learn what it takes to obtain a Seal of Approval from VisibleGovernment.ca. (That sounds useful.)
If we just let in a little light, the changes will grow. No? Or is it too early?
This discussion is good, some very valid points that should be kept in
mind moving forward(formats, process, public face)
I don't want to get off track with actually getting some people
together in a room. Understandably this is difficult for some in other
places(Jennifer), but some people are quite close, and in-person is
more bandwidth.
Here's what I hear:
-Meet this week
-define clear share objectives & scenarios (postal code to edistrict,
edistrict to MP, ...)
-Form a couple small teams around core areas: UX, API(REST/GET),
Documentation(public facing explanation & promotion, ...)
-Commit to a process (weekly chat or wiki or another google group)
-Grab a pitcher(this one was an executive decision)
On Feb 22, 7:57 pm, Michael Allan <m...@zelea.com> wrote:
> Just for a concrete example, to show that I'm not so much concerned
> with standards of transparency, but the reverse - transparency of
> standards:
> 1. Project Votorola has an idea for a public standard S (for
> storage/transmission of social data, or whatever). So we use the
> transparency facility to say, "Hello, here is standard S!
> Votorola will support S."
> 2. Project Shamen learns of S through the transparency facility
> (transparent, because it makes S visible). They think S could be
> useful, so they say, "Shamen will support S." (Meanwhile, the
> two projects are talking together, and making improvements to S.)
> 3. Other projects learn that both Votorola and Shamen have agreed
> (tentatively) to S. So they're thinking about it, too. They
> each decide for themselves, and they say, "we will/will not
> support S."
> And so on, for all the people, projects, firms, organizations,
> etc., and all the standards they propose.
> That's it - just transparency. (But that's everything, IMHO.)
> David Janes wrote:
> > There's a real danger of premature optimization here, of specifying
> > standards before the problem is really understood...
> It's possible, the domain might get hide-bound from premature
> standardization. (Mind, that's always a problem, even in a mature
> domain.)
> Then again, if we have a standards process that's transparent, maybe
> it'll be proof against rigidity? I mean, engineers are always coming
> up with ideas on how to escape from constraints - pushing the envelope
> - right? So there's always grassroots initiative from that side. But
> it's rarely made *visible* in public. Usually it's only the
> organizations (like standards consortia) that have a sufficient public
> presence. But they have a different dynamic, and often a different
> motivation. And often (but not always), it's *they* who are
> hide-bound.
> > ... However, here is a stab
> > at how I've seen successful APIs and data sharing develop on the web in the
> > mashup world.
> > The core "frameworks" are POSH, REST and JSON. POSH [1] is "Plain Old
> > Semantic HTML", meaning websites should be developed using modern web
> > standards, pages should valid, pages use HTML elements correctly and
> > presentation is coded using CSS. REST [2] can have deeper implications, but
> > amongst the simplest implications is that pages can be returned using simple
> > GET statements against a URL. JSON [3] has emerged as the defacto standard
> > for returning API results, amogst the reasons for is simplicity of creating
> > mashups and embeddability.
> > Atom and/or RSS provide the framework for update notifications. There are
> > emerging technologies for real-time delivery, but it's too early to worry
> > about that.
> > Microformats [4] provide a framework for embedding well-understood objects
> > in HTML, are based on popular and well-understood standards, are easy(-ish)
> > to implement, and a "consumer" ecosystem exists. In particular, people can
> > be represented by hCard [5], events by hCalendar [6], tagged data by rel-tag
> > [7] and microcontent (articles within a page) by hAtom [8]. Note that no
> > "parallel" infrastructure need exist to do microformats: they are served
> > within HTML pages.
> > Identify should use OAuth [9] and OpenID [10]; pragmatism says Facebook
> > Connect and Google Friend Connect should be in the mix too, though I have a
> > number of reservations about those.
> > I am very non-bullish about RDF [11]. IMHO it has missed almost the entirely
> > the mashup wave of the last few years, and successes seem to be scattered at
> > best. RDFa is competing in microformat's "space" and may see success yet if
> > it starts proving concrete solutions rather than "here's a format that can
> > do anything".
> (Interesting. I'm just learning RDF. I'll look at Microformats,
> before I commit to it.)
> Maybe Microformats is an exception, but the rest are mostly
> general-purpose standards. As such, they'll definitely be in the
> "foundation mix" of whatever specialized standards emerge in the
> political domain.
> But it's that emergence - the seeding and growth process - that I want
> to spotlight. In the case of the above standards, it was shrouded in
> darkness. (Otherwise, maybe the ridiculousness of SOAP wouldn't have
> been foisted on us. Maybe we'd have chosen REST, right from the
> start. If only we knew that a choice was being called for - if only
> there was sufficient transparency.)
> Jennifer Bell wrote:
> > Instead of worrying about JSON vs. XML vs. RDL, why not just say
> > 'machine readable API' and make the policy forward compatable? The
> > best technology solution(s) will depend on the application. Sites
> > that want to use the data can adapt easily enough.
> > For reference, at VisibleGovernment.ca we've been kicking around
> > technology constraints for software we fund. The most recent version
> > is:
> > * Software developed with VisibleGovernment.ca grants must be
> > released under an open source liscense. The MIT liscense is
> > preferred.
> > * Non-user related data must be exposed via machine readable
> > APIs.
> > * Sites requiring a user login must support OpenID.
> > * Sites requiring a friend list should use OpenSocial.
> > Also, there is a requirement to cross-promote VisibleGovernment.ca,
> > and other funded sites, during seasonal drives.
> I'll leave out the last item (cross-promo), because it's a contractual
> obligation between two parties. What's left is a kind of umbrella, or
> composite, standard. Call it U. It requires:
> * compliance with certain other standards, namely ...
> * following additional practices, namely ...
> Now, assume we already have a transparent process of standards
> proposal. Then your own change project (VisibleGovernment.ca) could
> use it to propose U as a standard, and make it visible to the other
> projects. You'd then learn which of them was, in principle, happy
> with it. Would that information be useful to you?
> On the other hand, would U's visibility be useful to the other
> projects? I guess they'd learn what it takes to obtain a Seal of
> Approval from VisibleGovernment.ca. (That sounds useful.)
> If we just let in a little light, the changes will grow. No? Or is
> it too early?
Right on Patrick, that's what I'm hearing as well.
Based on the Doodle poll, I think Tuesday at 6pm looks good. Let's
meet here at 192 Spadina Ave, Suite 404 unless someone has a better
location in mind.
On Feb 23, 9:28 am, interfaced <interfa...@gmail.com> wrote:
> This discussion is good, some very valid points that should be kept in
> mind moving forward(formats, process, public face)
> I don't want to get off track with actually getting some people
> together in a room. Understandably this is difficult for some in other
> places(Jennifer), but some people are quite close, and in-person is
> more bandwidth.
> Here's what I hear:
> -Meet this week
> -define clear share objectives & scenarios (postal code to edistrict,
> edistrict to MP, ...)
> -Form a couple small teams around core areas: UX, API(REST/GET),
> Documentation(public facing explanation & promotion, ...)
> -Commit to a process (weekly chat or wiki or another google group)
> -Grab a pitcher(this one was an executive decision)
> On Feb 22, 7:57 pm, Michael Allan <m...@zelea.com> wrote:
> > Replying to David Janes and Jennifer Bell
> > Just for a concrete example, to show that I'm not so much concerned
> > with standards of transparency, but the reverse - transparency of
> > standards:
> > 1. Project Votorola has an idea for a public standard S (for
> > storage/transmission of social data, or whatever). So we use the
> > transparency facility to say, "Hello, here is standard S!
> > Votorola will support S."
> > 2. Project Shamen learns of S through the transparency facility
> > (transparent, because it makes S visible). They think S could be
> > useful, so they say, "Shamen will support S." (Meanwhile, the
> > two projects are talking together, and making improvements to S.)
> > 3. Other projects learn that both Votorola and Shamen have agreed
> > (tentatively) to S. So they're thinking about it, too. They
> > each decide for themselves, and they say, "we will/will not
> > support S."
> > And so on, for all the people, projects, firms, organizations,
> > etc., and all the standards they propose.
> > That's it - just transparency. (But that's everything, IMHO.)
> > David Janes wrote:
> > > There's a real danger of premature optimization here, of specifying
> > > standards before the problem is really understood...
> > It's possible, the domain might get hide-bound from premature
> > standardization. (Mind, that's always a problem, even in a mature
> > domain.)
> > Then again, if we have a standards process that's transparent, maybe
> > it'll be proof against rigidity? I mean, engineers are always coming
> > up with ideas on how to escape from constraints - pushing the envelope
> > - right? So there's always grassroots initiative from that side. But
> > it's rarely made *visible* in public. Usually it's only the
> > organizations (like standards consortia) that have a sufficient public
> > presence. But they have a different dynamic, and often a different
> > motivation. And often (but not always), it's *they* who are
> > hide-bound.
> > > ... However, here is a stab
> > > at how I've seen successful APIs and data sharing develop on the web in the
> > > mashup world.
> > > The core "frameworks" are POSH, REST and JSON. POSH [1] is "Plain Old
> > > Semantic HTML", meaning websites should be developed using modern web
> > > standards, pages should valid, pages use HTML elements correctly and
> > > presentation is coded using CSS. REST [2] can have deeper implications, but
> > > amongst the simplest implications is that pages can be returned using simple
> > > GET statements against a URL. JSON [3] has emerged as the defacto standard
> > > for returning API results, amogst the reasons for is simplicity of creating
> > > mashups and embeddability.
> > > Atom and/or RSS provide the framework for update notifications. There are
> > > emerging technologies for real-time delivery, but it's too early to worry
> > > about that.
> > > Microformats [4] provide a framework for embedding well-understood objects
> > > in HTML, are based on popular and well-understood standards, are easy(-ish)
> > > to implement, and a "consumer" ecosystem exists. In particular, people can
> > > be represented by hCard [5], events by hCalendar [6], tagged data by rel-tag
> > > [7] and microcontent (articles within a page) by hAtom [8]. Note that no
> > > "parallel" infrastructure need exist to do microformats: they are served
> > > within HTML pages.
> > > Identify should use OAuth [9] and OpenID [10]; pragmatism says Facebook
> > > Connect and Google Friend Connect should be in the mix too, though I have a
> > > number of reservations about those.
> > > I am very non-bullish about RDF [11]. IMHO it has missed almost the entirely
> > > the mashup wave of the last few years, and successes seem to be scattered at
> > > best. RDFa is competing in microformat's "space" and may see success yet if
> > > it starts proving concrete solutions rather than "here's a format that can
> > > do anything".
> > (Interesting. I'm just learning RDF. I'll look at Microformats,
> > before I commit to it.)
> > Maybe Microformats is an exception, but the rest are mostly
> > general-purpose standards. As such, they'll definitely be in the
> > "foundation mix" of whatever specialized standards emerge in the
> > political domain.
> > But it's that emergence - the seeding and growth process - that I want
> > to spotlight. In the case of the above standards, it was shrouded in
> > darkness. (Otherwise, maybe the ridiculousness of SOAP wouldn't have
> > been foisted on us. Maybe we'd have chosen REST, right from the
> > start. If only we knew that a choice was being called for - if only
> > there was sufficient transparency.)
> > Jennifer Bell wrote:
> > > Instead of worrying about JSON vs. XML vs. RDL, why not just say
> > > 'machine readable API' and make the policy forward compatable? The
> > > best technology solution(s) will depend on the application. Sites
> > > that want to use the data can adapt easily enough.
> > > For reference, at VisibleGovernment.ca we've been kicking around
> > > technology constraints for software we fund. The most recent version
> > > is:
> > > * Software developed with VisibleGovernment.ca grants must be
> > > released under an open source liscense. The MIT liscense is
> > > preferred.
> > > * Non-user related data must be exposed via machine readable
> > > APIs.
> > > * Sites requiring a user login must support OpenID.
> > > * Sites requiring a friend list should use OpenSocial.
> > > Also, there is a requirement to cross-promote VisibleGovernment.ca,
> > > and other funded sites, during seasonal drives.
> > I'll leave out the last item (cross-promo), because it's a contractual
> > obligation between two parties. What's left is a kind of umbrella, or
> > composite, standard. Call it U. It requires:
> > * compliance with certain other standards, namely ...
> > * following additional practices, namely ...
> > Now, assume we already have a transparent process of standards
> > proposal. Then your own change project (VisibleGovernment.ca) could
> > use it to propose U as a standard, and make it visible to the other
> > projects. You'd then learn which of them was, in principle, happy
> > with it. Would that information be useful to you?
> > On the other hand, would U's visibility be useful to the other
> > projects? I guess they'd learn what it takes to obtain a Seal of
> > Approval from VisibleGovernment.ca. (That sounds useful.)
> > If we just let in a little light, the changes will grow. No? Or is
> > it too early?
> Right on Patrick, that's what I'm hearing as well.
> Based on the Doodle poll, I think Tuesday at 6pm looks good. Let's
> meet here at 192 Spadina Ave, Suite 404 unless someone has a better
> location in mind.
> On Feb 23, 9:28 am, interfaced <interfa...@gmail.com> wrote:
> > Hi Guys,
> > This discussion is good, some very valid points that should be kept in
> > mind moving forward(formats, process, public face)
> > I don't want to get off track with actually getting some people
> > together in a room. Understandably this is difficult for some in other
> > places(Jennifer), but some people are quite close, and in-person is
> > more bandwidth.
> > Here's what I hear:
> > -Meet this week
> > -define clear share objectives & scenarios (postal code to edistrict,
> > edistrict to MP, ...)
> > -Form a couple small teams around core areas: UX, API(REST/GET),
> > Documentation(public facing explanation & promotion, ...)
> > -Commit to a process (weekly chat or wiki or another google group)
> > -Grab a pitcher(this one was an executive decision)
> > On Feb 22, 7:57 pm, Michael Allan <m...@zelea.com> wrote:
> > > Replying to David Janes and Jennifer Bell
> > > Just for a concrete example, to show that I'm not so much concerned
> > > with standards of transparency, but the reverse - transparency of
> > > standards:
> > > 1. Project Votorola has an idea for a public standard S (for
> > > storage/transmission of social data, or whatever). So we use the
> > > transparency facility to say, "Hello, here is standard S!
> > > Votorola will support S."
> > > 2. Project Shamen learns of S through the transparency facility
> > > (transparent, because it makes S visible). They think S could be
> > > useful, so they say, "Shamen will support S." (Meanwhile, the
> > > two projects are talking together, and making improvements to S.)
> > > 3. Other projects learn that both Votorola and Shamen have agreed
> > > (tentatively) to S. So they're thinking about it, too. They
> > > each decide for themselves, and they say, "we will/will not
> > > support S."
> > > And so on, for all the people, projects, firms, organizations,
> > > etc., and all the standards they propose.
> > > That's it - just transparency. (But that's everything, IMHO.)
> > > David Janes wrote:
> > > > There's a real danger of premature optimization here, of specifying
> > > > standards before the problem is really understood...
> > > It's possible, the domain might get hide-bound from premature
> > > standardization. (Mind, that's always a problem, even in a mature
> > > domain.)
> > > Then again, if we have a standards process that's transparent, maybe
> > > it'll be proof against rigidity? I mean, engineers are always coming
> > > up with ideas on how to escape from constraints - pushing the envelope
> > > - right? So there's always grassroots initiative from that side. But
> > > it's rarely made *visible* in public. Usually it's only the
> > > organizations (like standards consortia) that have a sufficient public
> > > presence. But they have a different dynamic, and often a different
> > > motivation. And often (but not always), it's *they* who are
> > > hide-bound.
> > > > ... However, here is a stab
> > > > at how I've seen successful APIs and data sharing develop on the web in the
> > > > mashup world.
> > > > The core "frameworks" are POSH, REST and JSON. POSH [1] is "Plain Old
> > > > Semantic HTML", meaning websites should be developed using modern web
> > > > standards, pages should valid, pages use HTML elements correctly and
> > > > presentation is coded using CSS. REST [2] can have deeper implications, but
> > > > amongst the simplest implications is that pages can be returned using simple
> > > > GET statements against a URL. JSON [3] has emerged as the defacto standard
> > > > for returning API results, amogst the reasons for is simplicity of creating
> > > > mashups and embeddability.
> > > > Atom and/or RSS provide the framework for update notifications. There are
> > > > emerging technologies for real-time delivery, but it's too early to worry
> > > > about that.
> > > > Microformats [4] provide a framework for embedding well-understood objects
> > > > in HTML, are based on popular and well-understood standards, are easy(-ish)
> > > > to implement, and a "consumer" ecosystem exists. In particular, people can
> > > > be represented by hCard [5], events by hCalendar [6], tagged data by rel-tag
> > > > [7] and microcontent (articles within a page) by hAtom [8]. Note that no
> > > > "parallel" infrastructure need exist to do microformats: they are served
> > > > within HTML pages.
> > > > Identify should use OAuth [9] and OpenID [10]; pragmatism says Facebook
> > > > Connect and Google Friend Connect should be in the mix too, though I have a
> > > > number of reservations about those.
> > > > I am very non-bullish about RDF [11]. IMHO it has missed almost the entirely
> > > > the mashup wave of the last few years, and successes seem to be scattered at
> > > > best. RDFa is competing in microformat's "space" and may see success yet if
> > > > it starts proving concrete solutions rather than "here's a format that can
> > > > do anything".
> > > (Interesting. I'm just learning RDF. I'll look at Microformats,
> > > before I commit to it.)
> > > Maybe Microformats is an exception, but the rest are mostly
> > > general-purpose standards. As such, they'll definitely be in the
> > > "foundation mix" of whatever specialized standards emerge in the
> > > political domain.
> > > But it's that emergence - the seeding and growth process - that I want
> > > to spotlight. In the case of the above standards, it was shrouded in
> > > darkness. (Otherwise, maybe the ridiculousness of SOAP wouldn't have
> > > been foisted on us. Maybe we'd have chosen REST, right from the
> > > start. If only we knew that a choice was being called for - if only
> > > there was sufficient transparency.)
> > > Jennifer Bell wrote:
> > > > Instead of worrying about JSON vs. XML vs. RDL, why not just say
> > > > 'machine readable API' and make the policy forward compatable? The
> > > > best technology solution(s) will depend on the application. Sites
> > > > that want to use the data can adapt easily enough.
> > > > For reference, at VisibleGovernment.ca we've been kicking around
> > > > technology constraints for software we fund. The most recent version
> > > > is:
> > > > * Software developed with VisibleGovernment.ca grants must be
> > > > released under an open source liscense. The MIT liscense is
> > > > preferred.
> > > > * Non-user related data must be exposed via machine readable
> > > > APIs.
> > > > * Sites requiring a user login must support OpenID.
> > > > * Sites requiring a friend list should use OpenSocial.
> > > > Also, there is a requirement to cross-promote VisibleGovernment.ca,
> > > > and other funded sites, during seasonal drives.
> > > I'll leave out the last item (cross-promo), because it's a contractual
> > > obligation between two parties. What's left is a kind of umbrella, or
> > > composite, standard. Call it U. It requires:
> > > * compliance with certain other standards, namely ...
> > > * following additional practices, namely ...
> > > Now, assume we already have a transparent process of standards
> > > proposal. Then your own change project (VisibleGovernment.ca) could
> > > use it to propose U as a standard, and make it visible to the other
> > > projects. You'd then learn which of them was, in principle, happy
> > > with it. Would that information be useful to you?
> > > On the other hand, would U's visibility be useful to the other
> > > projects? I guess they'd learn what it takes to obtain a Seal of
> > > Approval from VisibleGovernment.ca. (That sounds useful.)
> > > If we just let in a little light, the changes will grow. No? Or is
> > > it too early?
We can push it back. I'm actually at MaRS for the "New Models of Web
Application Development" lecture until 5:30, so I'm not against a
little padding time.
Does moving it back to 8 work?
On Feb 23, 3:47 pm, interfaced <interfa...@gmail.com> wrote:
> I can't make tomorrow, just realized alex steffen from world changing
> is speaking...http://www.360series.com/
> Also, I could book a room here at the CSI if we could do it later. Or,
> you guys could just meet and take notes. Either works!
> On Feb 23, 10:21 am, Thody <adam.th...@gmail.com> wrote:
> > Right on Patrick, that's what I'm hearing as well.
> > Based on the Doodle poll, I think Tuesday at 6pm looks good. Let's
> > meet here at 192 Spadina Ave, Suite 404 unless someone has a better
> > location in mind.
> > On Feb 23, 9:28 am, interfaced <interfa...@gmail.com> wrote:
> > > Hi Guys,
> > > This discussion is good, some very valid points that should be kept in
> > > mind moving forward(formats, process, public face)
> > > I don't want to get off track with actually getting some people
> > > together in a room. Understandably this is difficult for some in other
> > > places(Jennifer), but some people are quite close, and in-person is
> > > more bandwidth.
> > > Here's what I hear:
> > > -Meet this week
> > > -define clear share objectives & scenarios (postal code to edistrict,
> > > edistrict to MP, ...)
> > > -Form a couple small teams around core areas: UX, API(REST/GET),
> > > Documentation(public facing explanation & promotion, ...)
> > > -Commit to a process (weekly chat or wiki or another google group)
> > > -Grab a pitcher(this one was an executive decision)
> > > On Feb 22, 7:57 pm, Michael Allan <m...@zelea.com> wrote:
> > > > Replying to David Janes and Jennifer Bell
> > > > Just for a concrete example, to show that I'm not so much concerned
> > > > with standards of transparency, but the reverse - transparency of
> > > > standards:
> > > > 1. Project Votorola has an idea for a public standard S (for
> > > > storage/transmission of social data, or whatever). So we use the
> > > > transparency facility to say, "Hello, here is standard S!
> > > > Votorola will support S."
> > > > 2. Project Shamen learns of S through the transparency facility
> > > > (transparent, because it makes S visible). They think S could be
> > > > useful, so they say, "Shamen will support S." (Meanwhile, the
> > > > two projects are talking together, and making improvements to S.)
> > > > 3. Other projects learn that both Votorola and Shamen have agreed
> > > > (tentatively) to S. So they're thinking about it, too. They
> > > > each decide for themselves, and they say, "we will/will not
> > > > support S."
> > > > And so on, for all the people, projects, firms, organizations,
> > > > etc., and all the standards they propose.
> > > > That's it - just transparency. (But that's everything, IMHO.)
> > > > David Janes wrote:
> > > > > There's a real danger of premature optimization here, of specifying
> > > > > standards before the problem is really understood...
> > > > It's possible, the domain might get hide-bound from premature
> > > > standardization. (Mind, that's always a problem, even in a mature
> > > > domain.)
> > > > Then again, if we have a standards process that's transparent, maybe
> > > > it'll be proof against rigidity? I mean, engineers are always coming
> > > > up with ideas on how to escape from constraints - pushing the envelope
> > > > - right? So there's always grassroots initiative from that side. But
> > > > it's rarely made *visible* in public. Usually it's only the
> > > > organizations (like standards consortia) that have a sufficient public
> > > > presence. But they have a different dynamic, and often a different
> > > > motivation. And often (but not always), it's *they* who are
> > > > hide-bound.
> > > > > ... However, here is a stab
> > > > > at how I've seen successful APIs and data sharing develop on the web in the
> > > > > mashup world.
> > > > > The core "frameworks" are POSH, REST and JSON. POSH [1] is "Plain Old
> > > > > Semantic HTML", meaning websites should be developed using modern web
> > > > > standards, pages should valid, pages use HTML elements correctly and
> > > > > presentation is coded using CSS. REST [2] can have deeper implications, but
> > > > > amongst the simplest implications is that pages can be returned using simple
> > > > > GET statements against a URL. JSON [3] has emerged as the defacto standard
> > > > > for returning API results, amogst the reasons for is simplicity of creating
> > > > > mashups and embeddability.
> > > > > Atom and/or RSS provide the framework for update notifications. There are
> > > > > emerging technologies for real-time delivery, but it's too early to worry
> > > > > about that.
> > > > > Microformats [4] provide a framework for embedding well-understood objects
> > > > > in HTML, are based on popular and well-understood standards, are easy(-ish)
> > > > > to implement, and a "consumer" ecosystem exists. In particular, people can
> > > > > be represented by hCard [5], events by hCalendar [6], tagged data by rel-tag
> > > > > [7] and microcontent (articles within a page) by hAtom [8]. Note that no
> > > > > "parallel" infrastructure need exist to do microformats: they are served
> > > > > within HTML pages.
> > > > > Identify should use OAuth [9] and OpenID [10]; pragmatism says Facebook
> > > > > Connect and Google Friend Connect should be in the mix too, though I have a
> > > > > number of reservations about those.
> > > > > I am very non-bullish about RDF [11]. IMHO it has missed almost the entirely
> > > > > the mashup wave of the last few years, and successes seem to be scattered at
> > > > > best. RDFa is competing in microformat's "space" and may see success yet if
> > > > > it starts proving concrete solutions rather than "here's a format that can
> > > > > do anything".
> > > > (Interesting. I'm just learning RDF. I'll look at Microformats,
> > > > before I commit to it.)
> > > > Maybe Microformats is an exception, but the rest are mostly
> > > > general-purpose standards. As such, they'll definitely be in the
> > > > "foundation mix" of whatever specialized standards emerge in the
> > > > political domain.
> > > > But it's that emergence - the seeding and growth process - that I want
> > > > to spotlight. In the case of the above standards, it was shrouded in
> > > > darkness. (Otherwise, maybe the ridiculousness of SOAP wouldn't have
> > > > been foisted on us. Maybe we'd have chosen REST, right from the
> > > > start. If only we knew that a choice was being called for - if only
> > > > there was sufficient transparency.)
> > > > Jennifer Bell wrote:
> > > > > Instead of worrying about JSON vs. XML vs. RDL, why not just say
> > > > > 'machine readable API' and make the policy forward compatable? The
> > > > > best technology solution(s) will depend on the application. Sites
> > > > > that want to use the data can adapt easily enough.
> > > > > For reference, at VisibleGovernment.ca we've been kicking around
> > > > > technology constraints for software we fund. The most recent version
> > > > > is:
> > > > > * Software developed with VisibleGovernment.ca grants must be
> > > > > released under an open source liscense. The MIT liscense is
> > > > > preferred.
> > > > > * Non-user related data must be exposed via machine readable
> > > > > APIs.
> > > > > * Sites requiring a user login must support OpenID.
> > > > > * Sites requiring a friend list should use OpenSocial.
> > > > > Also, there is a requirement to cross-promote VisibleGovernment.ca,
> > > > > and other funded sites, during seasonal drives.
> > > > I'll leave out the last item (cross-promo), because it's a contractual
> > > > obligation between two parties. What's left is a kind of umbrella, or
> > > > composite, standard. Call it U. It requires:
> > > > * compliance with certain other standards, namely ...
> > > > * following additional practices, namely ...
> > > > Now, assume we already have a transparent process of standards
> > > > proposal. Then your own change project (VisibleGovernment.ca) could
> > > > use it to propose U as a standard, and make it visible to the other
> > > > projects. You'd then learn which of them was, in principle, happy
> > > > with it. Would that information be useful to you?
> > > > On the other hand, would U's visibility be useful to the other
> > > > projects? I guess they'd learn what it takes to obtain a Seal of
> > > > Approval from VisibleGovernment.ca. (That sounds useful.)
> > > > If we just let in a little light, the changes will grow. No? Or is
> > > > it too early?
