From W3C Wiki

27 Jan 2015

See also: IRC log


eprodrom, jasnell, KevinMarks, aaronpk, Arnaud, Ann, wilkie, bblfish, bret, rhiaro, Sandro, Lloyd_Fassett, ShaneHudson, hhalpin, tantek, elf-pavlik, Harry


<trackbot> Date: 27 January 2015

<eprodrom> Hmm

<KevinMarks> hm, did I dial in too early?

<eprodrom> Apparently by like 30 seconds

<Arnaud> hi there

<eprodrom> Hmm

<eprodrom> Did I miss something in my incantation?

<eprodrom> I have 13:01 on my clock

<mattl> hey... not calling in, but GNU social got a ton more users thanks to Twitter banning a user.

<KevinMarks> hm. hearing beeps on the call

<eprodrom> AH

<eprodrom> There we go

<eprodrom> Thanks Arnaud

<mattl> eprodrom: if you have the db of the old StatusNet wiki, it would be great to get a copy :)

mattl: ... what user?

<Arnaud> it should have been unnecessary

<eprodrom> mattl: OK, I can try and get that to you

<aaronpk> whoa now there's music

<Arnaud> but for some reason it doesn't happen automatically

<Arnaud> already reported to sysreq

<eprodrom> Great

<jasnell> aw, I was just starting to dance around a little

<mattl> wilkie:

do we have a scribe? I can scribe.

<mattl> eprodrom: thanks man :)

<KevinMarks> we need adactio to come along and play us some folk

<wilkie> yay

<aaronpk> wilkie wins by 3 seconds

<Arnaud> fyi: I'm officially on paternity leave for 2 weeks :-)

<eprodrom> scribe: wilkie

<ShaneHudson> I can't even hear ringing

<Arnaud> yes, really!

<wilkie> rude: (

<ShaneHudson> Arnaud: Congrats! :)

<AnnB> holy smokes

<jasnell> Arnaud++

<Loqi> Arnaud has 2 karma

<bret> +1

<jasnell> +1

<eprodrom> PROPOSED: Alec Le Hors becomes youngest honorary member

<bblfish> :-)

<wilkie> :)

<wilkie> +1

<KevinMarks> +1

<bblfish> +1

<bblfish> we have a girl here

<bblfish> she is 4 months old

<eprodrom> RESOLVED: extend honorary membership to youngest ever member

eprodrom: if we are ready to go, unless we are waiting for somebody in particular. tantek will be joining shortly


eprodrom: first step: approval of our minutes from last week

Approval of Minutes From Last Week

eprodrom: any objections to approving these minutes?

resolved: minutes approved from last week

eprodrom: next meeting is Feb. 3rd, there's no reason to not have this meeting unless any objections?

Actions and Issues

eprodrom: we have a few that have sitting on the queue for a while
... one that came up last week was the json-ld context for the activity streams namespace. not sure where that landed
... don't see harry on the call

jasnell: there is some magic incantation that needs to be done to serve the json-ld properly. sandro may offer some insight.
... it is queued up and part of the publication of the draft, but I need to follow up with the team

eprodrom: can harry help out?

jasnell: harry doesn't know the incantation

eprodrom: another action on the list is to look at social apis

<Arnaud> he said he would do it next week

eprodrom: we should add talking about this to next week so we can mark that one off

jasnell: tantek is going to go through the microformat examples, there's a lot, he may not have done all of them

eprodrom: we'll leave it open

jasnell: (wrt speaking out to people) still getting a list and reaching out to people, some may need IE status

eprodrom: other open actions... "archiving osf blog posts" that may be open for some time

jasnell: the archives are available, we just need to have someone volunteer to do that work and have a place set up to put it

eprodrom: I went to the social IG call last week to discuss the process and present social apis to the IG. it went well

<harry> Note that the archives are available as a SQL dump from drupal

eprodrom: a very open discussion about the process that seemed helpful and there was a general agreement and approval of what we've done by the IG

<harry> so someone would have to 1) reset-up drupal and 2) snapshot the blogs as HTML.

eprodrom: one thing that did come up is that most of the APIs we reviewed were primarily US focused and it was noted we should look at networks in other parts of the world

<KevinMarks> vkontakte?

eprodrom: I took that as an action. my ability to navigate documentation in Russian and Chinese is slim, but I'll give it a good effort.
... the idea was to see if there were significant patterns in these APIs not found in Western social networks

<harry> Note that Jeff is going to discuss Social with Weibo in two weeks

AnnB: yes, I wondered if there is a difference between these networks. We do have members who are in China, only a few in Russia, but some may be recommended [to help]

<KevinMarks> historically, several of them adopted opensocial and had some mapping; the differences were often about payment

eprodrom: between a few members, most of these countries are covered. I feel like I can look at the bottom and read through the documentation so I could collaborate


<ShaneHudson> Worth looking at Orkut?

<ShaneHudson> (defunct I know)

eprodrom: here is the list. part of this may be to reach out to these organizations.
... any other issues we have not captured? any actions we should cover?

<harry> Note that minor HTML issues have delayed publication of AS 2.0 till Thursday.

eprodrom: new stuff for the tracker?

<tantek> Tracker:

eprodrom: time to move on to the next agenda item

<KevinMarks> orkut's api was opensocial

Review List of Requirements

<AnnB> hmm, Harry .. re: Weibo .. that's interesting

eprodrom: we are tasked with coming up with a social api. the process we are following to do so is the following


<harry> yes, its a f2f meeting, we'll see what happens

eprodrom: we identified a number of APIs throughout the web and we've looked at what they do
... we've looked at twitter, facebook, etc and open source, etc and some from non-specific standardization e.g. linked data platform
... we've covered quite a bit and our next step is gathering from these multiple apis and coming up with a set of requirements for our API
... we've talked about them a lot and documenting them online, but the time is rapidly arriving when we need to decide what these requirements are to move forward with a candidate proposal
... the idea is if we can approve a list of requirements, then we can start soliciting proposals and can measure the quality of the proposals based on those requirements


eprodrom: we had a list of requirements earlier and should be updated and we should discuss if these requirements are good for upcoming proposals
... one thing we can do is say "great, these are fine" and move on, or we can look at these and rewrite or elaborate on them further
... my goal is to move the process further

<Zakim> tantek, you wanted to suggest a simpler approach to API *requirements*, based on a previous group resolution, vs. "nice to haves"

eprodrom: it would be fantastic to have looked at proposals before the face to face
... tantek?

<harry> yes can hear you

<bblfish> +1 can hear you

tantek: there are many ways to pick features and requirements.
... on the lower end of the spectrum to just decide politically: go through a list and vote on each point
... we've taken a slightly better approach so far; we've researched existing APIs

<bret> drowed out by static

tantek: what would be better than that would be to annotate which requirements belong to what existing examples and what don't
... right now we don't know which requirements are based on an example or not
... there is still a better method: basing requirements on use cases

<bblfish> ah where are the use cases?


tantek: looking at use cases we have already chosen to adopt there are only one so far. the only one we have resolved to adopt is SWAT0
... therefore, all requirements should be adopted to follow ONLY what SWAT0 needs and all else is pushed to nice-to-have

eprodrom: I understand the point, but that is not the procedure we agreed upon and have been doing for the last many weeks
... we have done reviews to take requirements from those reviews. if SWAT0 is all we want, we could have saved ourselves a lot of work
... SWAT0 is not intended to be a social API usecase, it is a federation usecase.

<wilkie> where are the usecases from the IG??

<bblfish> was there not an IG doing use cases?

tantek: it's the only usecase we have
... there is nothing wrong with research and documentation, but the current set of requirements is too big for a first draft

<wilkie> The IG though... they are doing use-cases. that was the point of us NOT DOING THEM

bblfish: I like swat0, but don't we have an IG that builds up use cases? some kind of community group?

<tantek> no the point is we only one have use case WE HAVE APPROVED

bblfish: I don't really think, if I look at the requirements, I don't think they are difficult to do.

<AnnB> yes, socialIG ... has lots of use cases, just not in common template format

<harry> The IG had a slowdown due to chair changing.

<tantek> there are lots of use-cases. there is only one use case that Social Web WG has formally adopted.

<tantek> and that is SWAT0

<jasnell> running through the list of requirements... I've gone through and checked off the cases that are implemented by IBM's connections product (shipping currently)...

<tantek> I don't believe any claims of "don't think they are difficult" unless you have it already running

<tantek> e.g. on your own website

bblfish: the idea is to have an API that has all of them, and it may not be necessary for the WG to list all cases, but seeing all features together would be nice

<jasnell> would recommend that others match the requirements up against their existing implementations as well

bblfish: you can add audio, video, all kinds of things, in similar fashion

<tantek> with all due respect, I don't think anyone is qualified to say something is "easy" unless they've already *SHIPPED* it, e.g. on their own website

<sandro> wilkie, this is harry

<Loqi> sandro: ben_thatmustbeme left you a message on 1/20 at 12:26pm: i'll be co-organizing IWC Cambridge 2015, can you confirm that we have a venue for those dates? 2015-03-19/20?

<jasnell> the requirements list can be simplified and achieve the same result

harry: tantek is saying take the minimal use case agreed upon and add to that, and evan is about developing the list of potental requirements that we can shave down
... the real issue is that we don't have a draft and it is really hard to whiteboard an API draft from scratch, which is why we have done that research

<AnnB> Social IG use cases:

<KevinMarks> instead of the superset, choose the interesection

<bblfish> tantek. You can ask 9 implementations from the LDP group, to work out what easy is . I have built one by myself, so if one person can get implement it, that makes it easy. That's what I am basing my statement on.

harry: it, as a superset, is quite big. to resolve the tension, if somebody wants to whiteboard the draft and looks at the requirements we have made progress and we can say "this is not necessary for swat0" or "hey I'll need this for X"

<AnnB> with most focus so far on Profile use cases:

<tantek> bblfish - you were going to make all that work on your own site? have you?

<tantek> I don't believe the 9 implementations report in the context of Social Web WG

harry: my proposal is to let evan or whomever else to work on this, do a draft of it, and let tantek criticise it

<AnnB> mostly only defined in "scenarios" thus far:

<sandro> ben_thatmust, yes, confirmed

<elf-pavlik> +1 harry

<bblfish> yes

<harry> They in other words, let's just whiteboard something, as driven by SWAT0 and Evan's empirical work

<Zakim> tantek, you wanted to point out the process we agreed on does not specify *HOW* to "Assemble functional requirements of a social API"

<bblfish> there are pieces not implemented, but that does not make them difficult tantek to implement. It just requires agreeement

<harry> and then we can add use-cases as needed.

tantek: a point to harry's claim the requirements are easy: I'm going to say if you haven't shipped the requirements, you can't say it is easy
... I won't believe you if you haven't shipped


<jasnell> getting echo

tantek: if you look at the process we agreed on (pasted the url) the first step is the requirements of the social api, and I am suggesting a concrete way of doing that:

<harry> KevinMarks, ping or just type "Zakim, unmute me"

<KevinMarks> I'm already muted on my end

<KevinMarks> hm

<aaronpk> KevinMarks: that happened to me too. not sure how.

eprodrom: another mechanism we could use is to formalize

<KevinMarks> maybe gvoice is using the wrong mic

eprodrom: if we ask the IG to do it, what kind of timeframe would it take
... if we cannot go forward without the IG making those use cases, we'll need to ask them what their timeframe is or we do them internally in the WG
... another option is to take what we have and then look just at what is needed for SWAT0 and everything else is nice-to-have
... to be frank, SWAT0 is not a social api use-case
... for me, I don't think it is sufficient social api nor reaches the minimum social networking we expect from a social api

<jasnell> Here's an example of a comprehensive existing social api that implements quite a lot of these requirements:

AnnB: in regard to the usecases in the IG, which I am chairing, we have many scenarios and we have maybe too much.
... question I have for the WG is "what would you want to see and what format would it be in" what would be the most useful way to give you [the usecases]?

<elf-pavlik> +1 AnnB

<bblfish> AnnB: need to read this now :-) Looks good.

eprodrom: I think the use cases you posted are very detailed and there's a lot in here, but I think what we want is a checklist we can compare a proposal against
... "this proposal doesn't have a way to post content, so this isn't good for this use case"

<tantek> I actually don't want a checklist - because that's again likely political rather than user-based

AnnB: checklist of what

<tantek> AnnB, for each use-case, we need a BRIEF summary of the user-interactions.

AnnB: I think the IG needs guidance on what is useful

<tantek> just like SWAT0 has



<tantek> AnnB look at how brief the summary is here:

<tantek> so that's the request back to the IG

<tantek> all use-cases should have a *brief* user-scenario at the top

eprodrom: my concern is if we do these whole user scenarios for this kind of API requirements I think that is months of work

<tantek> just like that

AnnB: I agree. I think that's where we are stuck and need a new direction

eprodrom: not sure if we can do briefer ones or if there is another way to do this. if we hold out for full user scenarios it is unlikely we can do things promptly.

<KevinMarks> that's backwards, evan

<AnnB> thanks Tantek

<Zakim> tantek, you wanted to note that IG function is to *provide* use-cases, not *approve*. The Social Web WG must approve use-cases explicitly. and to also note that I specifically said

<KevinMarks> defining and implementing things with no use is months of work

tantek: I think I answered Ann's question on what to provide. I do agree that IG use cases are detailed and lengthy, which is good, they need a summary of steps. much like SWAT0 that fits in a tweet
... goes back to the IG: a summary of steps is what we want

<ShaneHudson> I do really like how simple SWAT0 is

tantek: I also agree with concerns about not a complete API and that it may take months of work to come up with usecases.
... this is why we should not wait for the IG usecases but just immediately go forward with even just a small draft with the usecases we have and extend with new cases later

<KevinMarks> the assumption that completeness is necessary is how we end in the weeds

tantek: so when people come and say "I need this feature" they can make a claim upon the draft we have

<elf-pavlik> i'll try to write something on importance of *extensibility* for this API, this way we just provide clear path to add support for all kind of requirements which will come up down the road!

tantek: my point is that I do believe we can come up with small incremental usecases if we need to. we don't need to wait.
... the IG does the work, but does not approve them. the WG approves and accepts them one at a time.

<tantek> zakim, mute me

sandro: one more vote for tweetable scenarios

<tantek> sandro: definitely a vote for tweetable scenarios

sandro: even if we start small with SWAT0, it is hard to go from something that expresses SWAT0 to something larger.

<KevinMarks> if it's in your head, you should be abel to write use cases for it

sandro: I think it is valuable to have a larger roadmap in mind.

<AnnB> distilling info to small bits IS necessary (re: suggestions for Social IG) .... and takes time to do! :-)

<tantek> sandro: "maybe we don't all build that all at once"

<tantek> agreed

sandro: evan, what process do you want for editing

<tantek> "don't build that all at once" = minimal requirements at first, and grow (build) more incrementally

eprodrom: the wiki is the next step

<AnnB> time better spend, though, than moving our scenarios to common template format

<tantek> I think I'm agreed with sandro

<jasnell> I am muted. no idea why it's saying me

eprodrom: look at each of the apis we reviewed and pull out relevant parts. lots of work and hopefully we have volunteers.
... I think adding questions on discussion page or mailing list are good

<bret> jasnell, local mute dosnt get everything, only trust Zakim mute

eprodrom: I'd like to point out that maybe 60% of these requirements are covered by the open social activity streams api

<tantek> I greatly prefer "collection" or "set" for a user-facing "thing" that users put other things into

<tantek> rather than "container"

<AnnB> why?

<tantek> "container" sounds too abstract / programmery

<harry> I think my proposal is we let Evan and whoever else is interested draft an API that fits at least SWAT0

eprodrom: it's really when we get down to endpoints that aren't those 5 major endpoints that it gets strange

<AnnB> aha

<bret> collection is a flickr term

harry: we are at an impasse. tantek's fear is legitimate and we shouldn't have a monster api with no implementors.

<KevinMarks> container is also an opensocial term of art

<tantek> jasnell - and I say users do care, and thus it matters

harry: at the same time, evan's fear that SWAT0 is not sufficient is legitimate

<jasnell> tantek: and I'm saying that right now's it's not critically important that we decide what to call it.

<tantek> jasnell - if you don't care, then change it to "collection"

harry: so, let's make a draft with requirements, and mark those that are good for swat0, mark the others as such, and use that as a place for discussion

<tantek> jasnell from our experience in indiewebcamp - that term resonates / explains much better

harry: we need a place to add/subtract features and discuss these features

<tantek> jasnell: see

<KevinMarks> i think the noise is on your end , elf-pavlik

<bret> can we mute Harry?

<AnnB> it's helpful to start with SOMEthing, which gives something to focus on, discuss, edit, improve

bblfish: I think the problem that things that seem complicated may in fact be simple

<tantek> I'll point out that "SWAT0" seeming "light" is flawed, because we don't even have any SWAT0 interop yet.

<tantek> again this is the same problem as the use of "easy"

<harry> Yes, SWAT0 is quite large

<tantek> don't say something is "light" or "simple" unless you've shipped it.

<harry> so we should just clearly demarcate in any API what parts are necessary for SWAT0 and what isn't, as tantek said

bblfish: I think one or many could present how they would do things with a base api and that would allow us to make a case that one way is simpler than another

<tantek> harry - exactly - thus we start the requirements bar at "necessary for SWAT0"

<tantek> and then we list more requirements later

<harry> yes, so I think we agree :)

<tantek> or rather *candidate* requirements

<tantek> they aren't *actual* requirements, because they're not *required*

bblfish: in a usecase we could specify that is the criteria of what should be allowed

<harry> I'm just suggesting that if Evan or someone else is drafting an API, they can go with functional requirements greater than SWAT0, just clearly mark those

<harry> should be pretty straightforward, i.e. contacts are needed for SWAT0

<elf-pavlik> +1 URI opacity!

bblfish: for instance URI opaqueness to work with certain criteria of privacy etc

<tantek> I agree to large extent re: use URLs and follow-your-nose discoverability that bblfish is mentioning

bblfish: this is how we can foster a system that may grow perhaps way beyond the scope of what this group is capable of specifying explicitly

eprodrom: I think that is helpful
... one of the requirements in this list is follow-your-nose semantics
... most of the APIs we reviewed are single implementation APIs which don't have those semantics. but this is a question for another day

<elf-pavlik> most (all) APIs which we reviewed don't aim at interoperability and extensibility

<bblfish> true: but most of the apis are centralised, so are not at that level examples of what the social web should be :-)

eprodrom: I think we need to postpone proposing these requirements at this moment

<Zakim> tantek, you wanted to discuss flaws in existing APIs, lack of URLs, lack of follow-your-nose, too many special APIs just copy/pasted for different types

eprodrom: we need to talk about activity streams a little bit

tantek: I want to make a point to agree with bblfish to use URLs and follow-your-nose ideas and use a more minimal API
... I agree with evan that many services do not have that follow-your-nose idea and it would be horrible to implement a similar system

eprodrom: I'll put APIs and follow-your-nose up for next week

<sandro> +1 tantek avoiding replicating unnecessary complexity

Activity Streams 2.0

eprodrom: I want jasnell and harry to talk about where we are with AS2.0 and the next version of the working draft

jasnell: based on the current process, hopefully draft will be published thursday
... validation errors and such caused delay. should be good though.
... we are trying to get the context documents served up with the magic incantation sometime after

harry: the problem is when there is an html error in a document, no matter how small, the webmaster will push back and we have to fix it before we can publish. that's how the w3c process works.

<KevinMarks> so w3c is less tolerant of html errors than w3c specs?

harry: there may be a process change that would make this process easier, but things should be set for thursday unless the webmaster finds something else

eprodrom: that's good news. very exciting.

<harry> yes, and no broken links :)

<bblfish> btw, we did not cover the testing of the current activities stream 2.0

<harry> jasnell, stay in IRC and I'll check with webmaster to see if everything is OK post-meeting

<jasnell> harry: +1

eprodrom: we will copy the agenda item for requirements to next week's call

<AnnB> thanks for good chairing, Evan!

<AnnB> and for scribing, Wilkie!

<bret> ty bye

eprodrom: thank you. appreciate your time. talk to you next week

<Arnaud> thanks

<elf-pavlik> thanks eprodrom wilkie !

<aaronpk> wilkie++ for scribing!

<Loqi> wilkie has 5 karma

<elf-pavlik> eprodrom++

<Loqi> eprodrom has 1 karma

<elf-pavlik> wilkie++

<Loqi> wilkie has 6 karma

<Arnaud> don't forget to get rrsagent to create the minutes

<eprodrom> trackbot, end meeting

<Arnaud> thanks

Summary of Action Items