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
<KevinMarks> hm, did I dial in too early?
<eprodrom> Apparently by like 30 seconds
<Arnaud> hi there
<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> 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
<jasnell> aw, I was just starting to dance around a little
<mattl> wilkie: https://twitter.com/Barbijaputa
do we have a scribe? I can scribe.
<mattl> eprodrom: thanks man :)
<KevinMarks> we need adactio to come along and play us some folk
<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
<Loqi> Arnaud has 2 karma
<eprodrom> PROPOSED: Alec Le Hors becomes youngest honorary member
<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
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: http://www.w3.org/Social/track
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 pump.io, 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
<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)... https://www.w3.org/wiki/Socialwg/Social_API/Requirements/Implementations
<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: https://www.w3.org/wiki/Socialig/Use_Case_TF
<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: https://www.w3.org/wiki/Socialig/Use_Case_TF/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: https://www.w3.org/wiki/Socialig/Use_Case_TF/Profile_Scenarios
<sandro> ben_thatmust, yes, confirmed
<elf-pavlik> +1 harry
<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" https://www.w3.org/wiki/Socialwg/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
<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: http://goo.gl/801jqU
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: http://www.w3.org/2005/Incubator/federatedsocialweb/wiki/SWAT0#The_use_case
<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"
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"
<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
<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 http://indiewebcamp.com/collection
<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! https://lists.w3.org/Archives/Public/public-socialweb/2015Jan/0053.html
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
<elf-pavlik> thanks eprodrom wilkie !
<aaronpk> wilkie++ for scribing!
<Loqi> wilkie has 5 karma
<Loqi> eprodrom has 1 karma
<Loqi> wilkie has 6 karma
<Arnaud> don't forget to get rrsagent to create the minutes
<eprodrom> trackbot, end meeting
Summary of Action Items