Social Web Working Group Teleconference

07 Jul 2015

Agenda

Attendees

Present: elf-pavlik, wilkie, ShaneHudson, Arnaud, aaronpk, cwebber2, sandro, eprodrom, tantek, jasnell, rhiaro
Regrets Chair: Arnaud
Scribe: wilkie

<trackbot> Date: 07 July 2015

<eprodrom> Hello all!

<elf-pavlik> wilkie++

<Loqi> wilkie has 16 karma

<Arnaud> scribe: wilkie

<jasnell> running late, will be right there

<Loqi> jasnell: elf-pavlik left you a message 5 days, 6 hours ago: could you please consider disabling mailing list notifications for PR while eprodrom works on editorial improvements? thx! http://socialwg.indiewebcamp.com/irc/social/2015-07-02/line/1435834198178

<Arnaud> PROPOSED: Approve minutes of 30 June https://www.w3.org/wiki/Socialwg/2015-06-30-minutes

<elf-pavlik> +1

Approval of Minutes

<wilkie> +1

<eprodrom> +1

<Arnaud> RESOLVED: Approve minutes of 30 June https://www.w3.org/wiki/Socialwg/2015-06-30-minutes

Arnaud: we'll call it resolved
... we can move to the main item of the agenda: Activity streams 2.0
... Last week we decided to publish the specification as a regular working draft. it would be good to know where we are. it would be nice to know when the draft WD will happen?

jasnell: I presented documents to harry last week and haven't heard back

Arnaud: harry is on vacation.

jasnell: sandro I copied you on note and got a failure to deliver. I'll attempt to resend. if harry can't do it, maybe we can work on it

Arnaud: can we get set up to do publication with a new tool

jasnell: I've not had the opportunity. maybe this week

Arnaud: this would solve this problem. once we have the tool, it will just be a click of a button and the editor will have the control/credentials. worth the investment.
... we'll have to wait for harry to come back
... otherwise, last week, we finished the call discussing a set of issues on github and everyone was meant to come prepared to discuss them.
... I would like us to proceed with this. on github and not on the WG tracker. jasnell: you have the lead on how to discuss this. there's no set order.

<jasnell> https://github.com/jasnell/w3c-socialwg-activitystreams/issues/134

<tantek> jasnell++ for providing just in time URLs

<Loqi> jasnell has 24 karma

Github Issue 134: "require explicit @vocab or define prefix if custom terms used, to remove current "@vocab": "_:" hack"

jasnell: we'll start with 134. "require specific vocab" because of the way json-ld works if things aren't in the context they get silently dropped

<elf-pavlik> "@vocab": "_:" - https://github.com/jasnell/w3c-socialwg-activitystreams/blob/master/activitystreams2-context.jsonld#L3

jasnell: to avoid this, the as context document uses the @vocab to declare the default vocabulary to be "_:"
... doing this any types undeclared are preserved but their meaning is document specific. if two documents have a 'foo' and they are not defined, they both have distinct 'foo' types that aren't comparable.

<elf-pavlik> foo property example https://github.com/jasnell/w3c-socialwg-activitystreams/issues/134#issuecomment-108255400

jasnell: therefore, you have to make sure for interop that you don't use terms that are ambiguous/undefined
... so: do we want a common prefix for unknown things? the benefits would be it would give more assumed interoperability for documents with undeclared extensions. however, could lead to a false sense that two similarly named extensions are the same.

elf-pavlik: I wanted to clarify that my issue does not propose a common prefix. if somebody uses properties outside of the context that person would have to define their namespace.
... that way they would have unique uri to identify them.

<Zakim> sandro, you wanted to say we should not have a default @vocab; accidental term collision is bad; bnodes are bad.

sandro: I think you can frame this as "what should happen when one publishes activity streams and don't do what they are supposed to do"
... they published things outside of the context basically. options: they are ignored, they map to a blank node, and a common namespace.

<elf-pavlik> -1 mapping to common namespace

sandro: common namespace can still conflict. blank nodes aren't a great idea either because they have some issues and strange behavior with RDF systems.

<tantek> +1 to silently ignoring

<elf-pavlik> my issue title starts with: "require explicit @vocab or define prefix if custom terms used"

<cwebber2> 0 to anything :)

sandro: I think silently ignoring them is a nice clear behavior. and people can understand "oh yeah, I'm not supposed to do that. they need to map to a url"

<tantek> has anyone come up with pragmatic extension examples for AS2?

eprodrom: seems to me that this is what people do with blank nodes: ignore them.

<eprodrom> SHOULD

<tantek> bnodes--

<Loqi> bnodes has -1 karma

<tantek> mustignore++

<Loqi> mustignore has 1 karma

eprodrom: can we say in the extension area of the draft that they would be ignored if they do not specify things clearly

<elf-pavlik> +1 SHOULD + silently ignore

eprodrom: I don't feel this is a MUST situation

Arnaud: I see elf-pavlik say that things shouldn't be mapped to a common namespace. I believe your proposal suggests people must define a namespace, but what if they don't? we still need to handle cases where people don't do it.

jasnell: the use of blank nodes here (the point that people ignore them is totally valid) just ensure that undeclared pieces make it through the json-ld expansion and letting the application decide what to do with these nodes later.
... if people do RDF processing then yes, some strange behaviors surface
... at least in json-ld expansion it does let the application decide what to do next.
... I do believe that it should suggest that these might be ignored, but we should allow applications to do this if they want to do so

elf-pavlik: I think silently ignoring in the case where people do the wrong thing is valid.
... in the case of blank nodes, I think people understand that blank nodes from two documents are not comparable, but how will people understand that two documents have the same extension property with json-ld?

<sandro> +1 elf-pavlik how do people NOT using json-ld work with extensions?

jasnell: you really need to declare a json-ld context. if multiple implementations are using the same term without declaring it, the spec already says they will have interop issues.

<tantek> sandro - well, in microformats2 we use CSS style -vendor- prefixes for extending h-* object names, as well as p-* property names.

<Zakim> sandro, you wanted to ask for the use case for this bnode mapping

<tantek> works reasonably well enough in practice for CSS, and so far in microformats2 as well. no URLs needed.

jasnell: if an implementation is not using json-ld expansion in this case, it would be undefined behavior

<elf-pavlik> in plain JSON we also don't have # fragment URI support ...

sandro: jasnell, you seem to have a use-case for this? in some cases they do want to look at this stuff and know what to do, and in that case we are telling them to use blank nodes, maybe? I don't understand the use-case.

jasnell: it comes down to allowing applications to do what they want to do but providing the guidance. if an application is closed-network then they can do whatever. if they care, the spec provides the guidance to do it well. it's about being prescriptive about what SHOULD be done, not normative about what must be done.

sandro: why tell them about blank nodes, then?

jasnell: the spec itself doesn't mention blank nodes, it is just that the processing puts them in by default in this case.

sandro: it seems weird to have a standard context have a hack for when people break the rules.

jasnell: noted

<Zakim> elf-pavlik, you wanted to ask again about strategy of integrating data from multiple sources without expanding terms to full URIs

Arnaud: seems like the status quo in the spec is what people are agreeing with so we should try to close this

elf-pavlik: from my perspective, if you want interoperability, people have to expand these terms.

<sandro> +1 elf-pavlik if you want interoperability + extenisibility, you have to use full URIs

jasnell: I don't think we need to keep hammering on. I don't think we need changes to the spec, but rather the json-ld context. whether we keep vocab to the blank node or we remove that specific item. the difference is when somebody uses json-ld expansion on a document with an undeclared term without the default vocab, those undeclared terms are dropped and the application WILL NOT SEE THEM. the application will see the blank nodes but does not (can not?) define meaning.

<Zakim> sandro, you wanted to say I'm convinced

Arnaud: thank you jasnell

sandro: I lean towards keeping it

<jasnell> sandro: I agree it's a bit weird

<Arnaud> PROPOSED: Keep the spec as is: namespaces SHOULD be declared, unknown terms are ignored but passed onto the application as blank nodes

Arnaud: let's see if we can close on this. I'll try to summarize.
... this is the status quo

<jasnell> +1

Arnaud: votes?

<wilkie> +1

<ShaneHudson> +1

<cwebber2> +0

<elf-pavlik> -0 possibly encourage 'bad practice'

<sandro> +1 this closes https://github.com/jasnell/w3c-socialwg-activitystreams/issues/134

<eprodrom> +1

Arnaud: I'll wait for elf-pavlik's vote. ok.

jasnell: I'll say to elf-pavlik, one of the things we can do is strengthen the language in the spec about why it is important these extensions are declared in the context.
... if people are not doing json-ld processing, it is worth noting it will not help them in any case.

<sandro> +1 jasnell strengthen language in the spec about why you should give URLs to extension terms!

<elf-pavlik> sounds good to me jasnell thx!

<cwebber2> ok adding that languages changes my vote to

<cwebber2> +1

jasnell: but I can write in the spec about what are the good practices

<Arnaud> RESOLVED: Keep the spec as is: namespaces SHOULD be declared, unknown terms are ignored but passed onto the application as blank nodes (closes https://github.com/jasnell/w3c-socialwg-activitystreams/issues/134)

<Arnaud> https://github.com/jasnell/w3c-socialwg-activitystreams/issues/133

Github Issue 133: "Create Examples With input and output of Common Posts"

jasnell: this is about looking at common services and creating examples (fictional, as they don't already use Activity Streams) for how to accomplish their use cases with activity streams
... the proposal would be to add these to the specification in some way

<tantek> frankly, I think all examples should have to be this pragmatic

eprodrom: would it be useful to use example.org etc for these instead of specific services and anonymizing the services such as "uploading a photo" etc

<tantek> and if any existing examples don't make sense in this kind of context (or in the context of existing approved user stories), then we should drop those examples

<sandro> +1 eprodrom use .example not facebook.com, etc

jasnell: that seems reasonable. it is just a matter of who will do it. pull requests are welcome.

<tantek> wait what did I hear ".example" ?!?

<elf-pavlik> +1 .example

<tantek> why not ".eg" ?

sandro: it is now .example instead of example.org etc

<sandro> https://en.wikipedia.org/wiki/.example

<cwebber2> tantek: is .eg set up for examples the way .example is?

<eprodrom> Sorry, lost my connection in the middle of speaking

<tantek> cwebber2: it should be!

Arnaud: let's not get hung up about the domain. jasnell is saying it is just about Doing It. do we have a volunteer?

<tantek> where is ben_thatmustbeme ? he's been fixing a ton of the examples

<jasnell> ben_thatmustbemee++

<Loqi> ben_thatmustbemee has 1 karma

<jasnell> ben_thatmustbeme++

<Loqi> ben_thatmustbeme has 86 karma

<tantek> argh muted

<eprodrom> I'm back!

tantek: ben_thatmustbeme has been doing a lot of work on improving examples in the spec. maybe file this as a separate issue for the spec and cc ben_thatmustbeme. I'm not volunteering him, but just saying you might find a volunteer here.

Arnaud: we already have an issue

tantek: this is a general issue. we would need a specific issue for the draft to say "examples should use .example"
... is 'abigdreamer' a member of the WG?

jasnell: no, but they are a user of activity streams giving useful input.

eprodrom: the next step here is to break up this issue into 8ish issues and do them one at a time

jasnell: that would be helpful

<elf-pavlik> eprodrom++

<Loqi> eprodrom has 21 karma

Arnaud: well, once that happens we can close this issue and refer to the other ones

eprodrom: correct

<melvster> jasnell: +1 keep @vocab, suggest urn: (sorry for late reply)

<Arnaud> ACTION: eprodrom to break up github issue 133 into several ones, and close 133 [recorded in [[1]|http://www.w3.org/2015/07/07-social-minutes.html#action01]]]

<trackbot> Created ACTION-71 - Break up github issue 133 into several ones, and close 133 [on Evan Prodromou - due 2015-07-14].

Arnaud: let's move on!
... we can tackle one more issue and then switch topic

<Arnaud> https://github.com/jasnell/w3c-socialwg-activitystreams/issues/131

Github Issue 131: Iconsistency wrt indirect object (target) and multiple actors

<elf-pavlik> +1 instrument (i plan to attribute both app and the device i use for creating content)

jasnell: with respect to 131, this one is largely resolved

<jasnell> https://github.com/jasnell/w3c-socialwg-activitystreams/issues/86

Github Issue 86: Add `application/ld+json` as requirement for servers

<tantek> -1 require servers to support ld+json

<tantek> better to put requirements on consuming code than publishers

jasnell: even though it has a type json-ld uses its own type "application/ld+json" and this issue suggests we add a requirement for servers to provide this type in addition to 'application/activity+json'
... if we see the json-ld type we can't make the same assumptions about what we will see

<tantek> propose rejecting this issue as being bad for publishers, and bad for interop

jasnell: therefore it is an important distinction
... the question is here: for the api, do we want to require (aka MUST) supporting the json-ld type

Arnaud: tantek is already rejecting

tantek: I think that the issue is frankly ill-conceived and doesn't understand supporting interoperability
... two types when you are publishing something makes it worse for consuming applications that have to suddenly support both and mitigating any issues in differences
... making publishers work where consumers could do that work is bad design
... the bottleneck is publishers and helping them get their data quality right

Arnaud: anybody else?

<ShaneHudson> I agree with tantek, my view isn't quite as strong but it doesn't feel like a good idea

<aaronpk> +1 to what tantek said

Arnaud: otherwise we should let that sink in for today

<eprodrom> +1

eprodrom: I agree with tantek. I don't think it is a good idea to prescribe server behavior in this case.

<tantek> can we resolve to reject?

<tantek> so close!

<tantek> straw poll?

<melvster> +1

Arnaud: let's switch topic. we can close this next week if we agree.
... social api?

<melvster> SoLID requires the correct mime type, most of the web does

<Zakim> elf-pavlik, you wanted to discuss experiments with auht and shared spaces

elf-pavlik: I didn't get to a write-up but I will get to writing up about SoLID authentication.
... about authorization and group-spaces

Arnaud: anyone else?

<cwebber2> amy said she was having a laptop crisis

<cwebber2> not sure how long it will take for that brb to resolve :)

Arnaud: we didn't hear from bblfish about his write ups on SoLID stuff either.
... for now, that will be it.

Charter License Update

<tantek> sandro has an update

Arnaud: last week we updated the license for the charter to one that is more permissable.

sandro: I have nothing to share about it right now. so let's move on

<tantek> I put it on the agenda, for a reminder to ask sandro for an update

Arnaud: Who put that on the agenda? *laughs* sorry, everybody. no update for now.

<tantek> no miscommunication, this is what we wanted. no update, no problem (yet) :)

Tracking of Actions and Issues

Arnaud: any actions to declare victory upon? it would be nice to see progress on some of these old issues.

<Arnaud> http://www.w3.org/Social/track/actions/open

jasnell: I would say action 26 is underway. ben_thatmustbeme has been doing a fantastic job on this.

http://www.w3.org/Social/track/actions/26

<tantek> ben_thatmustbeme++ agreed!

<Loqi> ben_thatmustbeme has 87 karma

jasnell: I would be ok with closing this in respect of it being underway.

Arnaud: any objections to close 26?

<elf-pavlik> ben_thatmustbeme++

<Loqi> ben_thatmustbeme has 88 karma

Arnaud: hearing none, we will close it. any others?

jasnell: I don't see much value in keeping 32 open. we've already reviewed many apis.

http://www.w3.org/Social/track/actions/32

<eprodrom> +1

Arnaud: let's ask evan [who opened the issue] are you ok with closing?
... ok. let's close that.

<eprodrom> Yes please

<eprodrom> Sorry, disconnected

<elf-pavlik> ok to close 34

http://www.w3.org/Social/track/actions/34

jasnell: we can close 34

Arnaud: elf-pavlik, you had the action. ok to close? ok. let's close.

<tantek> yes on keeping 35

jasnell: 35, tantek in february. haven't see any movement on it. are you going to move on this?

<tantek> I've heard more requests for "what is the type of x?"

Arnaud: yeah, this is one I would not be happy with closing as is.

http://www.w3.org/Social/track/actions/35

<elf-pavlik> 50 & 57 hopefully i could sart on it in a week or so

<tantek> rhiaro: was going to look into the opensocial posts

http://www.w3.org/Social/track/actions/47

jasnell: do we need 47?

<tantek> these are for the whole wg right? not as2 specifically?

<jasnell> we can likely close http://www.w3.org/Social/track/actions/52

<rhiaro> I sent several messages to different email addresses and twitter for the guy about opens ocial posts, no reply. Spoke to harry a couple of weeks ago, he sort of handwaved about it a bit, wasn't sure who else we could contact

Arnaud: if there is any action you are assigned to where you have an issue that blocks you, this is the time to speak up and we can try to solve it

<elf-pavlik> tantek, each action has "Associated with" and a product e.g. AS2

jasnell: 52 can likely close, but we don't have harry here

Arnaud: yeah, this one is bizarre.
... anybody else?

<ShaneHudson> https://github.com/jasnell/w3c-socialwg-activitystreams/issues/86

<tantek> let's 86 #86

<AnnB> see ya

<Arnaud> PROPOSED: Close https://github.com/jasnell/w3c-socialwg-activitystreams/issues/86 with a no

<eprodrom> Bye AnnB

<jasnell> +1

<tantek> +1

<ShaneHudson> +1

<eprodrom> +1

<cwebber2> +1

Arnaud: so we have 2 minutes. maybe we can go back to issue 86

<wilkie> +1

<elf-pavlik> +0 moving to API issues

<aaronpk> +1

<Arnaud> RESOLVED: Close https://github.com/jasnell/w3c-socialwg-activitystreams/issues/86 with a no

Arnaud: doesn't seem that controversial *laughs* then let's close that.

<tantek> shall we cancel next week?

<tantek> for Bastille day?

Arnaud: we are out of time. if you have any more topics, they need to be on the agenda for next week.

<tantek> up to eprodrom

Arnaud: not sure I will be on the next call

<eprodrom> tantek: I'm open

<tantek> ok cool

<cwebber2> wilkie++

<Loqi> wilkie has 17 karma

<tantek> wilkie++ for scribing!!!

Arnaud: thank you wilkie for scribing!

<Loqi> wilkie has 18 karma

<ShaneHudson> I will not be able to make next week. But will be up for scribing the week after :)

<cwebber2> and Arnaud++ for running

<eprodrom> Thanks all

Arnaud: thank you all for joining. take care!

<cwebber2> later

<elf-pavlik> Arnaud++

<eprodrom> Arnaud++

<Loqi> too much karma!

Arnaud++

<Arnaud> trackbot, end meeting

Summary of Action Items

[NEW] ACTION: eprodrom to break up github issue 133 into several ones, and close 133 [recorded in http://www.w3.org/2015/07/07-social-minutes.html#action01]