Social Web Working Group Teleconference -- 19 Jul 2016

<rhiaro> scribenick: rhiaro

<cwebber2> oops

<cwebber2> :)

<eprodrom> Arnaud, are you here? We're about to start. I'm going to take over as chair.

Approval of minutes from 2016-07-12

<eprodrom> PROPOSED approve https://www.w3.org/wiki/Socialwg/2016-07-12-minutes as minutes for 2016-07-12 meeting

<eprodrom> +1

<annbass> +1

<cwebber2> +1

<aaronpk> +1

<ben_thatmustbeme> +1

<sandro> +1

<melvster> +1

<eprodrom> RESOLVED approve https://www.w3.org/wiki/Socialwg/2016-07-12-minutes as minutes for 2016-07-12 meeting

eprodrom: I don't think we have any other admin besides minutes

LDN to FPWD

eprodrom: Best process is to have sarven and amy give us an update on status of the document so far and sounds like they want to move to FPWD, we discussed last week and decided to give people time to review

<aaronpk> scribenick: aaronpk

<sandro> https://rawgit.com/csarven/ldn/master/index.html

rhiaro: last week we sent an email saying we want to go to FPWD this week and asked for people to raise major issues by this week
... we resolved a lot of issues up to last week
... a lot of the changes to the document were explainig things better, editorial and stuff
... we still have some ongoing threads with people from various linked data communities participating
... some of the issues we've called out in the spec itself
... since the editor's draft, we've clarified a bunch of stuff and we think it's in a stable enough state and we have a more iplementations since last week
... we think it's in a good enough state to move it to FPWD

eprodrom: I realized that LDN is more general than activitypub but there is a close relationship. has there been a discussion between amy and sarven and jessica and chris about the overlap?

rhiaro: we've had a little bit of discussion, we've also got some ongoing stuff on github about that
... we should have a call to tlak about that
... i've started adding stuff to SWP to explain things
... there's an issue on SWP where i detailed all the alignment between the two to either bridge or align them

<rhiaro> https://github.com/w3c-social/social-web-protocols/issues/36

rhiaro: we need to work through these with chris and jessica to see which are major and which we can rough out

eprodrom: i think that we've had mixed theories about what FPWD means, whether it's putting something on rec track or just putting it out for discussion, i'm leaning towards the second
... we have the microformats stack which is very different from activitystreams, and we're saying they're two totally different things
... but here we're talking about more similar stacks so i'd want to see us come to a convergence on that

rhiaro: i'm working on that in SWP, where the brainstorming and working things out is taking place

<sandro> +1 converging activitysub and LDN would be really, really good

eprodrom: okay that makes sense

cwebber2: i agree that there's a lot of similarities. amy and i have been talking, trying to figure out how to bridge things, because we'd like to make them as compatible as possible
... the fundamental difference between the two is LDN is a lot more general, in that it doesn't assume as much about vocabulary used, which is nice in some ways
... but also there's a tradeoff, it does assume that you're probably working with Linked Data toolkit.
... currently the main convergence is that activitypub is kind of linked data under the hood but you don't need to know
... hopefully we can find out how to hit the intersection

rhiaro: things we can do if you're an LDN implementation and you want to support activitypub, then you have to serve your JSON as compacted JSON-LD so any consumer can read it as plain JSON
... so either it's activitystreams, or if it has other vocab then it's like dealing with an extended activitystreams object
... which might happen anyway. so things like that we can align on i think we can work things out so that LDN can serve stuff that plain activitypub implementations can handle and vice versa

<sandro> +1 activity sub as a restriction on ldn, so you can just use an ldn inbox for activitysub

rhiaro: that also means you can use an LDN inbox to receive stuff from your friends

eprodrom: okay that sounds reasonable to me
... i'm going to be pretty concerned if these two specs go very far into the REC world without having some level of integration between them

<cwebber2> I agree, it would be worrying if we ggot there without integration

<Zakim> tantek, you wanted to ask about prescriptive (spec first) vs descriptive (code first) approaches

tantek: the biggest concern i have is that it's a methodological difference between descriptive vs prescriptive approaches

<annbass> mind

<eprodrom> I think!

tantek: one of the things this group has tried to do is that there's a lot of existing work, running code, how can we find common specs between those
... there's running code with people publishing stuff and running servers and tha'ts helped drive our spec development.
... that's why we've been okay with multiple approaches, is that there's multiple running implementations
... it's great that amy has done some implementations of LDN already. where i start to get concerned is when we talk about how we could converge specs that isn't based on implementation experience. where we start having specs make compromises that break existing impls, but don't have any actual value
... just because we have people on a phone call agree, doesn't actually make someone's code on their website work
... i want to call that out as a concern. while i agree that the general trend towards convergence is good, but premature convergence where people in a room agree on spec-first convergence that isn't followed up with implementation
... if we are proceeding with the assumption that these are rec track, then we'll be implementation testing them. if we want to relax that assumption then we should do so explicitly and up front
... that's one cautionary point i want to make
... we're still waiting on implementations to update on activitypub itself, i'm a little worried about that disconnect

<tantek> s/mythological/methodological

rhiaro: chris said he was working on an activitypub implementaiton, so please post stuff to my inbox
... the implementations we have of LDN are not just me by the way
... getting actual code interop between LDN and activitypub is super important and way more fun than just spec interop

eprodrom: iT sounds like amy and sarven are ready to go to FPWD so i think what i will propose is that we approve this document

<eprodrom> PROPOSED publish https://rawgit.com/csarven/ldn/master/index.html as FPWD of LDN

<melvster> +1

<rhiaro> +1

<sandro> +1

<rhiaro> wait

<csarven> +1

<rhiaro> https://linkedresearch.org/ldn/

<rhiaro> yeah

<ben_thatmustbeme> that was going to be my question, which URL

<eprodrom> +PROPOSED publish https://linkedresearch.org/ldn/ as FPWD of LDN

<melvster> +1

<eprodrom> PROPOSED: publish https://linkedresearch.org/ldn/ as FPWD of LDN

<melvster> +1

<csarven> +1

<rhiaro> +1

<annbass> +1

<tsyesika> +1

<sandro> +1

<dmitriz> +1

<eprodrom> +0

<cwebber2> +1

<tantek> +1 with a link to Social Web Protocols somewhere up top like Status etc. to set context

+1 what tantek said

<ben_thatmustbeme> +1

<sandro> (yes, agreed that link is important)

<annbass> yes on the caveats from tantek and evan

<rhiaro> yep

<ben_thatmustbeme> btw, https://linkedresearch.org/ldn/ and https://rawgit.com/csarven/ldn/master/index.html do have some minor differences

RESOLUTION: publish https://linkedresearch.org/ldn/ as FPWD of LDN

<ben_thatmustbeme> looks to be just editorial

<rhiaro> ben_thatmustbeme: that's weird, they're both reading from github

<csarven> ben_thatmustbeme: You are correct. Apparently I didn't git pull last

<csarven> Should be up to date now.

eprodrom: i would like to move on to our next topic

<ben_thatmustbeme> rhiaro, one is last modified the 17th, the other was the 9th

sure

<rhiaro> scribenick: rhiaro

<ben_thatmustbeme> ahh, okay

AS2

eprodrom: Taking AS2 to CR with a couple of caveats around marking at risk sectionw as agreed. Immeidately afterwards we had i18n input
... We decided to hold of on CR until we had resolved i18n issues
... and largely we did
... As of right now we have for i18n 2 normative issues and 1 editorial
... Which are both interesting
... One is waiting for the original poster to give comment, I believe they were going to bring it up at i18n telecon last Thursday so looking for some feedback on that
... That question is about using markup in the name property
... I guess this has some i18n implications in terms of being able to set character sets and direction using html
... For activitystreams historically that title or displayName or name has not had markup in so that you can show it directly without having to worry about markup
... I think that james and I both want to keep that
... So we're trying to figure out if the fallback of using some other properties is sufficient
... The other issue is around using the map terms
... We had a long discussion about this last week

<eprodrom> https://github.com/w3c/activitystreams/issues/341

eprodrom: I don't want to againt his week. There is a discussion on the github issue
... It's a normative change, roughly about how we format language in the documents
... but as a courtesy last week because jasnell was on vacation we decided not to resolve it without him. He's back but still on vacation and hasn't commented yet
... What we have right now does not have this normative change in it
... The proposed change I think is unnecessary and a bad solution. We're waiting on jasnell for that.
... We also had 3 editorial issues come up since last week
... (not i18n ones)
... One posted by me about how we're using URLs
... At this point I'm getting concerned about where we are with the CR process. I would like to get some guidence from the group about what we do next

tantek: The challenge here with getting to CR is that we're supposed to take things to CR when we don't know any outstanding substantitive issues, that would alter implementations
... And clearly with the i18n issues you're working on making those happen
... Even once the spec enters CR it's still goign to get issues, substantitive ones
... What I've seen groups do is just draw a line at some point and say we think we have resolved our substantitive issues that we understand
... Going to acknowedlge that there may be other ones filed that would cause the spec to change, which may mean there's a new CR, but tha'ts okay
... That's one way to get the spec to CR whilst allowing new issues to show up
... And that's a judgement call of the editors and the group
... To how you keep hitting 0 issues
... So Evan, the issues that you've seen come in that are not i18n related.. how impactful are they to implementations?

eprodrom: Right now they are negligible. Making sure that the list of properties in one section is exactly the same as in another
... Obviously yes if you're using the document for a reference that needs to be accurate, but in terms of normative stuff they're almost entirely editorial

tantek: editorial things we don't need to worry about
... The way that we solve the multiple list of properties problem is typically by making one normative and the others non-normative and point back to where they are normatively defined
... That way if there's a doubt you can say here's the normative list

sandro: issue 341 is not editorial, that's a major imlementation change
... not really major, but..

eprodrom: 341 and 338 are both normative

tantek: these are i18n issues right?

eprodrom: yes

tantek: to handle this properly we should resolve these before CR
... Especially since they came in from horizontal review
... The other option is that if we honestly believe these are not going to affect implementatiosn we have to make a very strong case to the director to say we have these outstanding issues but we still think the document should go to CR and here is our case. Hard but not impossible
... If you decide you want to pursue it it's an option

eprodrom: I think that my main concern is that we went through a process that we resolved all the issues and decided to go to CR and did the transiton request and that from start to finish took about 4-6 weeks
... From the time we finished up the issues and got approval to go to CR
... I'm wondering if we would be restarting the clock ont hat or if we can just say we resolve these issues then go to CR without th emeeting again?

sandro: Ralph said if we resolve them by consensus including with the commentor we don't need another transition meeting
... so if Richard and James and you are all cool with solving these within in the next few days e can publsih at that point

eprodrom: great

sandro: I thought you were cced on an email from Ralph saying that

eprodrom: I may have just missed that
... Is our date still this week?

sandro: whenever you get it done, the next tuesday or thursday

tantek: waiting on the consensus and edits to happen

eprodrom: great. That's good news. I'm going to let james know that we are waiting on publication for him and then also double check with Richard that we've satisfied him on 338
... and we would publish without another meeting of this group

sandro: yep

tantek: Evan I think all you have to do is make sure Richard is happy with the edits
... Once you've got the draft edited to resolve the issue Richard needs to take another look to check those sections align with his understanding
... Once you get that thumbs up you can publish. Assuming we're not making other changes to the draft
... We're responding to a specific issue, nto affecting other issues

eprodrom: I will take care of the editorial issues in the meantime

tantek: if anyone else in the group is concerned about this issue or wants to follow it just go ahead and comment on the issue

<eprodrom> https://github.com/w3c/activitystreams/issues/338

tantek: You'll be notified as evan updates the issue with resolutions and that will be your opportunity to offer your opinion or objection
... To be clear none of this is trying to sidestep the groups ability to participate in this decision. Just tryign to streamline
... So if you do want to keep participating in this particular issue you can comment directly there. We're not taking it back to a resolution vote in the group
... make sense?

eprodrom: if we don't have any further questions on AS2 I'll put my chair hat back on

Document status

cwebber2: I'm working on AP implementation, mostly done but not publicly demonstrable. Should be up by next week
... It's mostly in place now

eprodrom: Any other updates?

<ben_thatmustbeme> JF2 is just waiting for when we decide to publish them all

eprodrom: If no other issues or actions to address time to wrap up
... tantek down for next week's chair
... Thanks everyone

<eprodrom> Thanks all

<annbass> thanks Evan, Amy and Aaron!

<tantek> aaronpk++

<Loqi_> aaronpk has 1068 karma (59 in this channel)

<tantek> rhiaro++

<Loqi_> rhiaro has 230 karma (120 in this channel)

<eprodrom> trackbot, end meeting

- DRAFT -

Social Web Working Group Teleconference

19 Jul 2016

Attendees

Contents

Approval of minutes from 2016-07-12

LDN to FPWD

AS2

Document status

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output