Socialwg/2016-08-16

socialwg Informal Editors' meeting 2016-08-16

Tuesdays at 10am US/Pacific, 1pm US/Eastern time for 60 minutes

Check your timezone

Previous Meeting

2016-08-09

Minutes

IRC ONLY TODAY

Attendees

Present: cwebber2, csarven, tsyesika, rhiaro, annbass, melvster
Regrets Chair: rhiaro

<csarven> cwebber2 If it matters, the LD community 'in general' - and not exclusive LD folks from SWWG are strongly in favour of the profile approach. From the LDN's perspective, we wanted ot at least acknowledge the (dis)advantages to AS2's new mime type. It is part of the reason we thought that SWP may be best place to address that. However, if AP goes ahead with the profile approach, that'd probably be better for implementations since there is only one treatment of the content-type.

<cwebber2> csarven, ACK

<cwebber2> csarven, yes, I followed the tumultuous github threads ;)

<cwebber2> csarven, anyway, yes it's no extra work for us

<cwebber2> so all is well

<rhiaro> For process sake:

<rhiaro> PROPOSAL: Keep AP and ASub as one document, with reference to LDN in ASub

<rhiaro> +1

<cwebber2> +1

<csarven> +1

<tsyesika> +1

<cwebber2> consensus!

<melvster> +1

RESOLUTION: Keep AP and ASub as one document, with reference to LDN in ASub

<cwebber2> haha: D

<Loqi> nice

<cwebber2> so, I'm going to go through https://github.com/w3c-social/activitypub/pull/75 and merge it

<cwebber2> is there anything else to discuss?

<cwebber2> I guess one more thing that needs to be done then is to separate the pub and sub sections in AP

<csarven> cwebber2 ARe you okay to alias inbox to whatever LDN ends up using for ns?

<cwebber2> csarven: yes

<csarven> Great

<cwebber2> csarven, though I think if it *is* possible to get both LDN inbox and rest of AP terms to be added to AS namespace

<cwebber2> that would be ideal

<cwebber2> but I guess that will require policy changes or somethin :)

<rhiaro> cwebbe2: working on it..

<cwebber2> though, whatever

<cwebber2> we can do aliases to anything in the context ;)

<cwebber2> we'll alias to a wiki page. Living namespaces!

<rhiaro> yeah so LDN can talk about ldp:inbox, but if AP implementers use as:inbox and that is aliased to ldp:inbox in the json-ld context, it all works out the same in the end

<rhiaro> So AP implementers don't have to care about ldp:inbox and ldp implementers don't have to care about as:inbox

<rhiaro> but they accidentally interop anyway

<rhiaro> ... I think.

<cwebber2> csarven, rhiaro, so a question about profiles

<cwebber2> one nice thing about the mimetype is that you could then infer a json-ld context

<cwebber2> of the AS2 mimetype that we are no longer using

<cwebber2> is something like that possible with profiles? I'm guessing not?

<cwebber2> I guess we could just set it with profiles

<cwebber2> but what would happen to LDP things that were ignorant of that

<rhiaro> So the scenario is: an AP sender sends a notification without an @context, but with the profile, to an LDP receiver

<rhiaro> Does the LDP receiver handle it correctly?

<rhiaro> Or more generally: if you have a JSON blob without an @context, but with a profile in the media type, can you use that profile as the @context?

<csarven> If no context, I suspect that it is JSON-LD expanded?

<csarven> So, JSON-LD expanded + profile?

<cwebber2> csarven: no :)

<rhiaro> okay, not expanded and no context, but with profile

<cwebber2> csarven: compacted

<rhiaro> I'm not entirely sure if profile is meant for this. I feel like maybe, but we need to consult an expert

<rhiaro> going to re-check what annotations is doing

<csarven> profile can be anything. it is not specified as long as the semantics don't change by including it.

<csarven> if you remove the profile, it should still make sense

<csarven> cwebber2: Sorry, right, compacted. Whatever gives the full URI =)

<cwebber2> csarven, compacted is the human readable, without the full URI :)

<rhiaro> no, the not-full URI

<cwebber2> csarven, so the goal of using the activitystreams mimetype

<rhiaro> we dont' have this problem if it's expanded

<csarven> If you don't have context and there is no full URI, those keys are just arbitrary strings

<csarven> application specific at best

<cwebber2> csarven, was so that if a "dumb" participant sends documents, you know how to infer a context

<rhiaro> that's why we're trying to figure out if profile can tell you how to expand the strings

<csarven> OK, but the semantics shouldn't change is what @profile is saying

<rhiaro> So I figure that if profile == inferred @context, the semantics aren't actually changing

<csarven> What's the "semantics" if there is no context and no full URI?

<rhiaro> there's agreement between sender and receiver, via the profile

<csarven> Without the profile!

<cwebber2> btw I'm running this by manu

<cwebber2> csarven: no this would be *with* the profile

<rhiaro> *with* profile, without @context

<rhiaro> there is always a profile in this scenario

<cwebber2> application/ld+json; profile=http://www.w3.org/ns/activitystreams#

{"type": "Note"}

<cwebber2> implies doing a default context with the document loader :)

<cwebber2> *that's* what the activitystreams mimetype gave us

<cwebber2> so that dummy user who just sent json and had no idea what that @context thing was could still be interpreted

<cwebber2> if this is tricky

<cwebber2> what we could do is one of those "liberal in what you accept but conservative in what you produce" things

<cwebber2> by always providing the "@context" but say "consumers SHOULD process with an implied context" in a non-normative section, giving clarity on how to accept content from people who don't quite do the right thing

<cwebber2> but, producers should do the right thing.

<cwebber2> that way an AP <-> LDP thing will still workl.

<cwebber2> *work

<csarven> My reading of https://tools.ietf.org/html/rfc6906#section-3 is that, if you don't have the profile, it should still make sense as JSON-LD (given 'application/ld+json')

<csarven> And if you don't have context or a full URI in there, I'm not sure if that does. Unless I'm misinterpreting something here.

<cwebber2> alright well

<cwebber2> at the very least, we can switch to providing an @context in all examples....

<rhiaro> like chris said, the liberal-in-what-you-accept thing is probably still good

<rhiaro> but yeah, we should put @context in examples as a good start

<csarven> Just to be clear: I'm not 100% sure about it, so just raising it for caution.

<cwebber2> :)

<cwebber2> ok well anyway

<cwebber2> I think we have enough info to improve that

<csarven> Better ask in #json-ld

<cwebber2> csarven, already doing so :)

<cwebber2> well the freenode one

<csarven> And.. I'm okay with the robustness approach. Is that SWP territory?

<rhiaro> Okay, I think we have enough to be going on with with AP. Anyone else have anything to add?

<rhiaro> csarven: possibly, or it might be some carefully negotiated combination of AP and LDN (or all of the above)

<rhiaro> Okay, then wrapping up. I'll dump this chat on the wiki page.

<rhiaro> trackbot, end meeting

Summary of Resolutions

Keep AP and ASub as one document, with reference to LDN in ASub

Agenda

Chair: Amy

Discussion Items

Next Meeting

2016-08-23 telecon with chair Arnaud

Adjourn

Chair to close the meeting with the following command:

trackbot, end meeting

If you forget, trackbot will close the meeting for you when the activity dies down.

back to socialwg