From W3C Wiki
Jump to: navigation, search

Derived from RRSAgent minutes


See also: IRC log


jasnell, Arnaud, dret, evanpro, elf-pavlik, AdamB, MarkCrawford, Sandro, wilkie, claudio, aaronpk, KevinMarks, cwebber2, Harry_Halpin, oshepherd


RESOLUTION: approved minutes from October 21st

RESOLUTION: we will open all issues raised during TPAC


<Arnaud> trackbot, start meeting

<trackbot> Date: 04 November 2014

<jasnell> howdy

<jasnell> of course, as soon as I dial in, a guy starts tearing up the road outside with a jackhammer

<bret> My regrets! I have to miss the meeting this week.

<cwebber2> calling in

<AdamB> alternating weeks seems reasonable

<jasnell> alternating seems reasonable

<AdamB> but there was a lot of time spent picking the current time

<wilkie> it seems fair

<KevinMarks> 408.335 is me

<cwebber2> I sure am

<evanpro> SOCL

I could do it

<cwebber2> thanks elf-pavlik :D

<scribe> scribe: elf-pavlik

<scribe> scribenick: elf-pavlik

<evanpro> Thanks elf-pavlik !

<KevinMarks> where is agenda? on wiki?

<evanpro> KevinMarks: see topic

<wilkie> KevinMarks: irc topic

<almereyda> How long would spectating such a call as right now take?


approval of minutes for 21 october

<harry> I’ll be working on minutes, but we had some errors that require special processing due to the day shift

<harry> So we’ll have to approve them next meeting

<harry> re TPAC minutes

<jasnell> no objection

<evanpro> no objection

RESOLUTION: approved mintues from October 21st

tracking actions and issues

Arnaud, we collected many ISSUES and ACTIONS during TPAC

<Arnaud> raised issues:

scribe: i would like to propose that we all agree to open them all

<evanpro> Sandro

<harry> Mght be useful just to review issues to make sure we’re all on same pages for folks who missed TPAC

sandro: to Arnaud you can decide as group chair to open those issues

<jasnell> sadly unable to view that page at the moment

evanpro: unless someone objects lets move them to open

RESOLUTION: we will open all raised issues

<Arnaud> Open actions:

evanpro: will close ACTION-10, requests reveiw

<jasnell> yes saw it

Arnaud, claims victory on ACTION-7

<jasnell> evan: dret and I are reviewing

<evanpro> jasnell: great

<evanpro> Can you mark that as closed, then?

<cwebber2> congrats Arnaud :)

Arnaud, initially suggested his availability for early february but needed to change due to expecting a child toward the end of january

<harry> In terms of timing we have lots of deliverables it would be good to get out by end of Q1 2015, so I’d be happy to meet


<harry> anytime before end of March.

elf-pavlik, i can’t minute because of some noise on line

thanks for muting!

jasnell, ACTION-8 in progress, email sent to mailing lists

Arnaud, let’s leave it open for now

jasnell: on ACTION-9 having progress with dret

<dromasca> aaee is dromasca

harry: little back and forth with ???, looks positive so far

TPAC Debriefing

minutes needs cleanup and make logs public

<KevinMarks> the irc logs are html

harry, working on it, will take a little

harry: working on it, will take a little

<harry> progress being made with Google and Actions, don’t publish an alternative FPWD

<harry> We have Loqi catching all the minutes as well.

Arnaud, 3 versions of minutes, IRC log, another autogenerated by irc bot, next one manually copied to wiki

scribe: asked system team for suggestions, they could make irc log writeable by HTTP PUT, which would allow us to edit log and regenerate minutes
… will follow up on that and let’s hop we can have it working and documented

elf-pavlik: thanks Arnaud!

harry: pandoc does the conversion very well, we could try to automate it with it

<AdamB> harry: any link to information on pandoc ?

Arnaud: also commonscribe developed by sandro, but system teams has some issues with it

evanpro: just use the automaticaly generated minutes, if we need to make changes we just add errarta on wiki page

Arnaud: problem with autogenerated minutes - very bad quality

<aaronpk> we do have a list of nicknames to real names and websites

Arnaud: we should capture attendance, who stays present, we need to translate nicknames to real names

<wilkie> who of you are complaining about this? haha

Arnaud: elf missed out that one needs to use : and can’t use , after nick of person speaking


<aaronpk> and it’s even machine-readable

<harry> State of the art in W3C systems seems to have frozen in late 90s, but that’s where we are.

<harry> If a funder wants to show up and help us, that would be great!

Arnaud: TPAC, I don’t want to take people through the whole minutes but happy to answer questions

<KevinMarks> hm, aaronpk, most of those don’t have full names

<aaronpk> coudl be easily added

Arnaud: we had some good conversation about Actiions, even tantek realized that they match what IndieWeb comunity do with their <indie-action>
… we discussed ‘what we mean by Social API’, we resolved that we talke about HTTP REST API which allows clients to access servers
… we should highlight in in minutes and accept possible objections to such definition of ‘Social API’
… we discussed federation protocol, we don’t have concrete way forward but could clarify a lot about this topic
… we had discussion with Social IG, most folks attended the whole meeting
… they presented overview of what they work on and tried to get feedback if they stay on the right tracks when it comes to usecases
… we setup doodle pool for the dates and location for next F2F meeting
… also interesting cross meeting with Annotation WG, one of the opportunities created by TPAC
… two working groups met together and realized that we don’t have overlap on deliverables, but we have big overlap on the topic, we could provide Social API they need
… we could explain to each other what we work on
… we found that adding annotation to a web page, and adding comment to a blog post have very similar mechanics
… we agreed to take a closer look at it
… also meeting with some of people, aside from WG meeting on wednesday during time for ad-hoc meetings, presen from google side Guha, danbri and Sam Goto

<jasnell> TBL even attended

<AdamB> generally seemed to have a positive vibe to it

Arnaud: we will follow up with them on overlap with Actions

<jasnell> their idea is to submit as a Note

Arnaud: could submit their Action vocab subtree

<jasnell> will be following up with them, however

<KevinMarks> they don’t currently show archival versions, but dan said they would

harry: clarifying 1 or 2 things regarding liason
… Anotations may need to connect to acrivity stream
… they may want to build on our spec
… when it comes to we ‘dance’ with google to possibly join the WG

<evanpro> I believe danbri is on the line, which is great

<evanpro> He’s in the IRC channel

otherwise they can submit Actions and we better hold with publishing alternative

Arnaud: and we have nice group photo
… few people could join remotely over WebRTC based app
… doesn’t require any registration etc. just modern borwser
… we agreed that we acheved goals setup for that meeting and now we just need to continue our work

Activity Streams 2.0

require JSON-LD compacted serialization

jasnell: JSON-LD allows expessing document in various form, which serializes same data in different ways
… the compacted form stays closest to what AS1 has and what most people expect
… it makes sense to require that interchange AS2.0 document in compacted form

<dret> q

<dret> +q

<Arnaud> sandro

<oshepherd> This requirement should only apply to the application/activitystream+json media type

<KevinMarks> processing without a json-ld processor is a goal surely?

sandro: people need to require ‘our’ context or compatibile context

<evanpro> harry: can you mute please?

<cwebber2> +q

sandro: also something about people who don’t have JSON-LD processor

<evanpro> Arnaud: thanks!

<KevinMarks> previously we talked about an implied context to include as1

sandro: we may need concrete schema for compacted version

dret: if we make this statement, we need to tell people what to do if they don’t use JSON-LD toolset
… or say - don’t even try to do that without JSON-LD processing

<oshepherd> If you don’t use a JSON-LD toolset, then its’ just JSON

cwebber2: i think that requiring by default compacted form with default context is good way to go
… i only have limited experience with implementing JSON-LD in GNU Media Goblin

<KevinMarks> the value of the @context is confirming the assumptions of the processor

Arnaud: how do people know which is which ?

<cwebber2> it seems like if you want to use extensions that aren’t default in there, then you expand the document

<cmhobbs> harry, any word on my application?

jasnell: way exists to define profile but we may not need it

<harry> It was sent to chairs, not sure where it is

<harry> in their pipeline

<harry> Folks were a bit busy at TPAC

<cmhobbs> thanks

<cmhobbs> i figured as much

jasnell: we have JSON-LD context which could serve as default for compacting

<oshepherd> I’m in favor of implicit context for AS mediatype

<cwebber2> having it compacted by default with default context gives best of both worlds: ability to write quick scripts, but also the ability to extend and not have things get totally vague

harry: my intuition, that if we normativly specify it and people don’t do it it puts W3C in bad light

<KevinMarks> you can always expand JSON by adding keys; you can also add more contexts to explain them

harry: we know that tons of JSON exists out there and not so much JSON-LD, let’s recommend default context and see how people use it or use other contexts
… does anyone know if JSON-LD processings spreads in a wild?

<harry> We’re doing another chairs call Monday so I’ll try to make sure they get to it

Arnaud: I think we don’t have enough information to make this decision now

<Arnaud> Proposed: Require JSON-LD compacted serialization and close Github Issue-48

<Arnaud> Proposed: Require JSON-LD compacted serialization with a default context and close Github Issue-48

<jasnell> +1

<harry> I’d like our specs to be conformant, but we also have to realize we don’t have much data on how JSON-LD is being used in the wild

<elf-pavlik> +1

<wilkie> +1

<evanpro> +0

<dret> i am not sure this is well-defined as it is stated. so -1

<oshepherd> +1 (implied concept)

<cwebber2> +1

<AdamB> +0

<MarkCrawford> +0

<claudio> +1

<aaronpk> +0

<harry> I’d be interested if anyone has any idea if people tend to make explicit @context or not in the wild.

<KevinMarks> this reminds me of profile

dret: it worries me that we need to think about various aspecs if people use extensions and model vs. syntax

<jasnell> I’m sorry, that objection is not very clear to me

dret: doesn’t see it well defined as it stands now

<oshepherd> I’m not even sure I understand what the question was there

jasnell: not quite sure about the objection

<KevinMarks> does “default context” mean it has to have an @context key, or that it is implied?

dret: maye i don’t understand fully JSON-LD compacting mechanism

<oshepherd> Whatever you put in there comes out with full URIs

dret: what happens to URIs not mapped in @context
… discussing JSON-LD details with jasnell

<evanpro> I also don’t understand the issue

Arnaud: we should take it offline and come back to this proposal

KevinMarks: tries to clarify what we mean by ‘default context’

<KevinMarks> +1

<harry> I think we’re trying to get out of forcing people to include @context

jasnell: if one not specified one should use one recommended by the spec

<oshepherd> I’m not sure how we can get proper interoperability if we don’t mandate processing via our context

<harry> its one of those things that developers are likely to forget in cut and paste :)

<oshepherd> If you add your own prefixes, then your compact form will NOT be the same as the AS2 context

sandro: or use *compatibile* context (eg. extended with more mappings)

Arnaud: asks dret if that helps

<cwebber2> I agree, avoiding collisions is god

<cwebber2> good

<cwebber2> not bod

<cwebber2> wow, can’t even spell my typo

<KevinMarks> that makes sense -so if a context is supplied it can’t redefine name as age or something

dret: needs to discuss this topic more

<oshepherd> We need to require processing with _our_ context else we will get non-interoprarble results in the wild

<evanpro> cwebber2: do you mind putting the federation discussion on next week’s agenda?

remove “rel” from as:Link

<cwebber2> evanpro: happy to… how do I do that, just add to the wiki?

<evanpro> cwebber2: I’ll get the next agenda page up at the end of the call

elf-pavlik: as:Link can wait!

<cwebber2> evanpro: great :)

<KevinMarks> oshepherd: it doesn’t have to be the same, but it has to be compatible -ie an intersection?

jasnell: starting with rel
… it doesn’t make sense once you expand it

<cwebber2> evanpro: when meeting ends, can you stick around for a couple of minutes for me to PM you? should be very short

jasnell: it should stay property of the subject not the link itself
… in general of questionable value
… recommend to remove it, only one (mine) implementation uses it

Arnaud: do people understand this case?

<KevinMarks> would this mean we’d lose rel’s when mapping to HTML?

jasnell: separate issue from removing as:Link !

<KevinMarks> or have to know to add them?

<wilkie> btw, it is this discussion:

<oshepherd> KevinMarks: If you want to do use your own context, you need to expand using ours then compact using your own. if you add your own prefixes, etc, you’ll produce output with those prefixes which will not be interoperable

<Arnaud> Proposed: remove “rel” from as:Link and close Github Issue-47

<wilkie> I’m not sure where “preview” goes, but it is an odd property

<jasnell> +1

KevinMarks: has consern about value of rel in html and microformats

<jasnell> Kevin: it would change from {“image”: {“rel”: “preview”, “@id”: "http://…“}} to {”preview“: {”@id“: ”http://%22}

KevinMarks: if we remove rel, it may close path to easy mapping to microformats

jasnell: we can still express needed relationships

<wilkie> this “image”: { “type”: “link” } thing is just odd. is should be “links”: { “preview”: { “type”: “image” } } or something like that?

<jasnell> wilkie: that’s a separate issue

KevinMarks: conserned about microformats2 round ???

<wilkie> right

<wilkie> that’s why it is hard to discuss this one haha

<dret> i just tried to write up my concerns at (the requirement of JSON-LD compacted form)

<wilkie> if you get rid of “rel” you’d have to rework links altogether, so, yeah…

<KevinMarks> microformats-2 round-tripping from a published page to as2 bakc to mf2 html

<evanpro> B-)

jasnell: as things currently defined rel doesn’t make sense in processing model

<evanpro> Arnaud, we’re at 2PM

<Loqi> I added a countdown for 11/4 2:00pm (#5540)

KevinMarks: explains some aspects of mf2

<oshepherd> KevinMarks: The problem with Rel as defined is that it binds to the target of the rel - so "; gets a “rel”: “preview” attached to it, which is semantically completely wrong

jasnell: we can just define link relations we want to use in JSON-LD @context

Arnaud: end of official time, people may need little more time to think about it and discuss it

<KevinMarks> they’re defined here: so maybe that can be munged into a @context ?

Arnaud: next time we can try to highlight proposals and get agenda out earlier

<harry> We’ve been trying to have chairs rotate

<harry> which makes things harder.

evanpro: if we run over, should we plan for 2h meeting next week

<harry> We do have the telecon booked for 2 hours just in case :)

<KevinMarks> oshepherd: how does that fit rel=me etc?

Arnaud: happy to extend for 30min next week

<KevinMarks> rel=author

evanpro: 11-11 holiday in canada

Arnaud: we keep regular time

<dret> thanks chairs and everybody!

<wilkie> thank you! thanks elf-pavlik.

<evanpro> Thanks Arnaud ! Good meeting.

<Arnaud> trakcbot, end meeting