- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Tue, 13 Oct 2015 11:37:03 +0200
- To: Christopher Allan Webber <cwebber@dustycloud.org>
- Cc: "public-socialweb@w3.org" <public-socialweb@w3.org>
- Message-ID: <CAKaEYhLSP2pXF-9vxTseGtbKpekC++=JDw1Dvi2oDE5dgaiNmw@mail.gmail.com>
On 7 October 2015 at 01:06, Christopher Allan Webber <cwebber@dustycloud.org > wrote: > Hello all, > > So I initially wrote a different version of this email, but I thought > today's call was lively enough that it deserved a rewrite. So here > goes! > > I'm glad to hear that there's a general concern in the group that we > really need to get moving for real on the client to server / server to > server APIs. I was also happy to hear that in general people seem eager > to get ActivityStreams to move forward. Great news! Now, can we do it? > Can we fulfill the missions of this group? > > I think we can. ActivityStreams 2.0 is already looking quite polished. > Today we got some good clarity on what an ActivityStreams test suite > would look like, and I can help on this. But the deliverables of social > api and federation api seem stuck in a rut. At minimum, we need to > agree on a format and move forward with it. > > Since it's already a deliverable, the mandatory format might as well be > ActivityStreams + JSON. It's okay to say in the specification that > other formats are optional, and here's how to handle them, but > ActivityStreams should be mandatory. As Evan said on the call today, it > would "look strange" to not have that be part of the official APIs the > group puts forward. But appearing non-strange is just one reason: the > goal of this group should be putting forward a standard that the real > world will probably use. The real world is currently setting up > endpoints that shoot JSON back and forth at each other. Well, we've got > a nice JSON supporting format, we should take that, declare that as a > basis, and start defining how to shoot that across some endpoints. > > By the way, it's my observation (and actually not at all just my > observation, several people external to the group have raised this to > me, even while I was traveling to FSF 30th just this last weekend) that > one of the main causes of this group getting so "stuck in a rut" is that > this group is caught in the crossfire that has been going on for 15 > years: Microformats vs Linked Data. I have massive respect for people > on both sides, and I'd love to see this group serve some purpose of > seeing these sides come together, but more than anything I believe the > opposite has happened: again and again we get caught into age-old > arguments between these camps. > As to why this group is stuck in a rut: 1. *Social*: The group is not as focused on social as it could be. There is a bias towards micro blogging, which is a valuable use case, but does not equal the social web. We need solutions that are people oriented and relationship driven, which is under represented at this point. The group needs to find a good balance. Possible Solution: perhaps document the key points in a social architecture document (a deliverable of the IG) as a guide to implementors. Reflect that the social web is about people, friends and connections. 2: *Participation*. Perhaps related to (1) there is a lack of industry participation. That facebook is a W3C member, and not a member of this group, says a lot. As such the group is scrambling to meet deliverables and implement. Also important groups have left the WG since it's inception e.g. apache, boeing and the opensocial foundation havent really participated either. Possible Solution: since we have few people, we need to work together on something we can all commit to helping with, such as implementations of AS2 with a JSON LD mime type, to solve commonly agreed user stories in an interoperable way (Post a note is a good candidate) 3. *Standards*. It appears that some parts of the group are unfamiliar or uncomfortable with the innovate that the W3C has done in the last decade to prepare for this work. Things like awww, design issues, related W3C RECs should be required reading for participants and experts, but it's unclear that we're building on the work already done. This makes consensus a delicate and slow process. Possible Solution: focus on one aspect, interoperability. Allow namespaces to ensure that everything works with everything else. Dont try and pick one system to rule them all, try and work together by implementing the test suite and successfully sending message diffs from one profile to another. Also realize the pre requisites to this which is to have profiles that interact. I think Amy may be in a position to continue to do good work in this area, but others need to help. 4. *Communication*. Communication is this group is not up to the standard of other W3C groups, as it's split between the mailing list, IRC and telecons. The mailing list it the canonical discussion area but has been largely ignored by some. This has caused a relatively dysfunctional consensus process. One of the W3C staff contacts being, IMHO, relatively inexperienced does not help here. Possible Solution: Like other groups, use the mailing list as the place to get things done, supported by github, wiki etc. Ensure that everyone in telecons is up to date with what's discussed. Not all of this is likely to get done, but could be pointers as to where we went wrong. But even small improvements may help. > > > The Microformats vs Linked Data war has been going on for 15 years. If > it hasn't been solved outside of this group in all this time, there's no > way it can be reconciled inside this group. Take it outside! > > I have more to say on all the above subjects, but in the interest of > keeping this email short, here's a summary: we already have a nice and > dandy serialization format that fits the toolchains of most of the web > frameworks out there. We've spent a lot of time getting it to a state > that the group seems reasonably happy with. We should take advantage of > that and move forward on recommending APIs that people can use. > > So, how about it? > - Chris > >
Received on Tuesday, 13 October 2015 09:37:33 UTC