Social Web Working Group Teleconference

07 Apr 2015

Attendees

Present
Regrets
Chair: Arnaud
Scribe: rhiaro

Summary of Action Items

[NEW] ACTION: hhalpin to discuss with wseltzer to make sure this [microformats/micropub referencing] is fine [recorded in http://www.w3.org/2015/04/07-social-irc]

Summary of Resolutions

Open raised issues ISSUE-26-36
Close the following issues: ISSUE-7, ISSUE-12, ISSUE-20

Approval of minutes

Arnaud: any objections?

<tantek> they're not there?

<tantek> no minutes!

Arnaud: Hearing none, minutes approved March 31st
... Still missing minutes from f2f and March 10th

<tantek> on n.m. found https://www.w3.org/wiki/Socialwg/2015-03-31-minutes

Arnaud: Saw a note from aaronpk about the bot failing to generate the minutes to get started
... we need harry's help

harry: I'll look at it, will do by end of call

Arnaud: f2f minutes are back together?

harry: wil double check, need to reprocess everything

<harry> we have all the IRC logs - don't nothing is missing

harry: we have all the irc logs, just needs formatting

<tantek> we are doing 1.5hrs today right?

<harry> don't worry there, but I'll try to format by end of the call.

Arnaud: Next telecon is next week
... Today we have 1.5 hours, we can see how that goes and see if we should do it more often or every week, or keep it as a one off
... Next week default is to go back to an hour

<tantek> Arnaud, back to me chairing next week?

Arnaud: There is a f2f meeting, only 8 people reigstered as participants

<harry> tsk tsk that's not enough

Arnaud: Not many people have registered as regrets or remote, please take a moment to answer one way or another

<tantek> (telcon)

Arnaud: Also a question about TPAC 2015

<melvster> could someone provide a pointer to the f2f?

Arnaud: We agreed we'd meet at TPAC, Sapporo, Japan end of October, but it's a whole week event. Which days of the week do we want to meet?

<aaronpk> f2f meeting https://www.w3.org/wiki/Socialwg/2015-05-04

<ShaneHudson> I might be able to make it, but no company is financing me so not sure if I will be able to afford it yet.

Arnaud: tantek has a conflict M/T
... Proposal is for us to meet Th/F

<Arnaud> PROPOSAL: Meet 2015-10-29…30 (ThF) at TPAC2015

<harry> Thursday and Friday is fine with me. Anyone have another WG conflicts?

<elf-pavlik> melvster https://www.w3.org/wiki/Socialwg/2015-05-04

Arnaud: The earlier we set the date, the better
... Then other groups can work around us
... Any objections to Th/F?

<elf-pavlik> +0 I will not come to TPAC

Arnaud: No objects, approved!

APPROVED: Meet 2015-10-29…30 (ThF) at TPAC2015

Arnaud: We'll set up a wiki page for registration again

<aaronpk> I probably won't be able to go to TPAC

Arnaud: Be aware that you have to register at TPAC itself
... and ther'es a small fee for food etc
... Anything else?

Tracking of actions and issues

Arnaud: not going to spend too much time
... Open actions

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

Arnaud: Anyone wnat to declare victory on anything?

<harry> I would not iterate through them by name, that takes up a lot of time

<Loqi> Shudson made 1 edit to Socialwg/2015-05-04 https://www.w3.org/wiki/index.php?diff=83394&oldid=83378

<Loqi> Pelf made 1 edit to Socialwg/2015-04-07 https://www.w3.org/wiki/index.php?diff=83395&oldid=83390

<Loqi> Benthatmustbeme made 1 edit to Socialwg/2015-05-04 https://www.w3.org/wiki/index.php?diff=83396&oldid=83394

Arnaud: Don't want to go through, just let us know if anyone has anything to close

<aaronpk> rhiaro: did you hear back about the opensocial database yet?

jasnell: Don't have completed, do have progress

<elf-pavlik> I updated deadlines for my overdue actions

jasnell: Hopefully we'll have basic test (?) to show off by next week

<harry> ACTION-51: Rigo does not want to fund my travel despite there being a 5K travel budget from the EC for this WG.

<trackbot> Notes added to ACTION-51 Discuss with rigo travel budget to see if more funding can be found for a paris event.

Arnaud: harry: could we have a repo set up for that?

harry: shouldn't be a big deal. elf-pavlik created a large number of documents, want to migrate everything?

<harry> My question - migrate the somewhat excessive number of documents in elf's repo aren't standards track

<tantek> URLs for what people are talking about?

harry: Some of the documents aren't standards track

<tantek> "large documents" ?!?

<harry> Do we just restrict the repo to standards-track?

<harry> Or do we add everything in there?

<harry> I'm OK either way

Arnaud: I don't think we should just make it an open dump for anyone with any document

harry: maybe the clear division of labour is that we use the w3c repo for rec track stuff, and for everything else we use elf's repo

<tantek> harry++

Arnaud: reasonable

<Loqi> harry has 8 karma

harry: I'll do it by the end of the day
... Anyone disagree?

<Zakim> elf-pavlik, you wanted to discuss 1 repo or many repos

elf-pavlik: want to clarify that we have team in w3c organisation, and we have social organisation separately, so should we have 1 repo or multiple repos? 1 in w3c organisation or multiple repos in w3c? So it's not a question about dumping everything in one repo
... and it's not 'elf's repo' it's an organisation with multiple repos

<harry> Repos that are standards-track or related to standards-track documents goes to W3C repo

harry: repos that are standards track or related to standards track documents go to w3c repo

<tantek> or *required* for standards track documents - e.g. test suite is required

harry: and everything else goes to social group of repos

<tantek> lots of things could be "related"

harry: the repos in the w3c group are structured so other wgs can see what's going on

<elf-pavlik> sure

<harry> and everything else, goes to w3c-social group of repos set-up by Elf

Arnaud: Anyone else? reports on progress/completion?

<harry> So, when experimental stuff goes Rec-track, we move to W3C repo

<elf-pavlik> github orga https://github.com/w3c-social

Arnaud: Otherwise, we have a bunch of raise issued later on agenda

Activity Streams 2.0

<harry> The main thing is also to make sure the rest of the WGs can distinguish between experimental and Rec-track stuff

Arnaud: issues on the agenda..
... elf-pavlik will talk about issue 16 to get started

issue-16

<trackbot> issue-16 -- better separate grammar/vocabulary and improved spec structure -- open

<trackbot> http://www.w3.org/Social/track/issues/16

elf-pavlik: this issue is raised by dret who is on the call, and talk about how we talk about how we separate the core grammar, and extended vocab terms, which fits the vocabulary task force in social ig
... which is why we should discuss this before, because some other issues are very specific to vocabulary issues
... we can delegate between IG and WG to reduce pressure
... We don't have to answer some issues if we have clear extensibility mechanisms
... issue-36, json-ld context helps allow people see the rdf view
... maybe erik can explain

dret: the idea was basically that it would be helpful if there was a strict separation between the AS grammar, fundamental mechanisms, and the specific vocabulary you're using in some application
... I think there's consensus that there should be some kind of base vocabulary
... the issue is saying there should be better separation
... in the end I think the goal of that would be to force ourselves to have a well-defined extension model in the core spec
... that says 'this is what vocabularies can do' and to use our own vocabularies as just one way of using that extension model
... to say here are activities and object types etc, as a blue print, so if someone comes up with more vocabularies they can start with the base and use the same mechanism how to define their own vocabularies
... the big question is 'how do we define vocabularies'?
... do you have to do it in rdf/owl form, or can you do it in rdf/owl, or what's the expectation for someone working on vocabularies
... we will force ourselves to answer that question if we have a separation between activitystreams core and vocabularies used in core to serialize concepts

<elf-pavlik> dret++

<Loqi> dret has 2 karma

Arnaud: okay, jasnell?

jasnell: going back to the original restructuring that happened; it was decided before we published the 1pwd, to simplify the document

<Loqi> Aboyet made 1 edit to Socialwg/2015-05-04 https://www.w3.org/wiki/index.php?diff=83397&oldid=83396

jasnell: we don't have the extended vocabulary stuff there yet
... it would simplify it if it was split into two where the vocab was in one and the syntax was in another

<akuckartz> dret++

<Loqi> dret has 3 karma

jasnell: the extended vocabulary was added because it was felt that we needed the base schema
... in AS1 we had a base schema that defined all the verbs and object types that were used commonly with 1.0
... It was felt that we needed to have those concepts brought into the vocabulary for interop purposes

<melvster> let me just note that a base social web vocab exists ... SIOC and SIOCT ... means "Socially Inter connected communities" -- and it's in use

<dret> i think ideally we should have one RDF-based vocabulary as a demo, and one non-RDF-based one, to demonstrate how those two ways of defining vocabularies are working.

<akuckartz> rhiaro++ for scribing

<Loqi> rhiaro has 50 karma

jasnell: THe idea of having the extended vocabulary is to take the most commonly used verbs and object types and have a common understanding and definition of what those are, so they are consisten between implementations
... It makes sense ot have a definition in the core vocab of those commonly used things
... What has not happened is a reconciliation of the objects in there from 1.0 base schema, and use cases
... have not been reconciled with critical user stories

<tantek> melvster - what sites use SIOC on the public web? URLs? Permalinks?

jasnell: So I imagine that there are some set of activity types and object types that we can remove
... because the aren't as critical as others
... or widely used
... And a couple of the issues I've opened suggest removing some of those

<dret> jasnell, i am not at all saying we shouldn't have a core. we absolutely should. but the question is how to define them, and how to cleanly separate the core, and the base vocabulary. i really liked the way AS1 did it.

jasnell: What we really need are proposals ot remove specific ones
... I have no problem removing items, just need to know which and make sure there's consensus

<tantek> I encourage jasnell to remove terms at his editor's discretion and just note it as FYI in the changes section in the spec

jasnell: We've talked about this a number of times, but haven't been any concrete proposals for changes to make to document

<harry> Agreed concrete set of chagnes would be good

<Zakim> elf-pavlik, you wanted to discuss how people define new domain specific terms and how they discover existing one already defined by others?

jasnell: instead of having a high level discussion, be great to propose changes

<dret> http://localhost/github/W3C/SocialWG/AS1-in-AS2.html was a first attempt to start with the AS1 base schema, and move it over to the AS2 world.

elf-pavlik: of course we can't capture all terms in default vocabulary, some people want to add domain specific terms, at this moment I understand we have a default vocab that doesn't need rdf

<dret> i think we should strictly separate the dsicussion on *how* we better separate core and the base vocabulary, and *what* the base vocabulary should be. very different issues.

elf-pavlik: If you want to use your own, you're on your own
... It would be better to have a clear pattern to define domain-specific vocabularies
... IG can help with coordinating
... And also a way to discover what other people have defined
... eg. xAPI
... Can create extensions
... There is also a schema.org extension mechanism
... I think we need more guideance about how to extend with domian specific terms

<melvster> tantek: implementations and applications of SIOC (though there's a few more now such as cimba.co from this group) http://en.wikipedia.org/wiki/Semantically-Interlinked_Online_Communities#Implementations_and_applications

dret: All I want to add is that I think we should strictly separate what the core terms should be. The issue right now is not what those terms should be, but how we separate them and how we should go forward to rec track indepedant of base terms which then maybe should be managed by the IG

<elf-pavlik> melvster John Breslin (SIOC) wants to coordinate work with us

<tantek> melvster: was looking for specific URLs I could view source on - should I just go down that list?

dret: And also this interface between the WG and the IG is that our job is to create an extension model, and the IG doesn't want to use it, we have to do a better job of defining it so the IG can use it to deifne the base vocab

<tantek> melvster: wikipedia "social web" or "social network" documentation is horribly out of date

dret: We should separate issues about how to define base schema

<tantek> e.g. sites with feeds, feed readers etc.

harry: From w3c perspective we would prefer a cleanly defined base schema
... And the IG had control over extension mechanisms

<tantek> melvster: I have had some good online back/forth with John Breslin - perhaps we can invite him as an invited expert?

harry: But I do agree the WG can define extension mechaism

<melvster> tantek++

<Loqi> tantek has 174 karma

<AnnB> tantek++

<Loqi> tantek has 175 karma

harry: Some people say don't worry, it's rdf it has extension, but some people want to use json. Just going to be delicate figuring it out technically but I'm sure we can find consensus

<AnnB> can he come to F2F in Paris?

harry: There's probably not massive overlap with schema.org (?)

<harry> We would prefer not to have overlap

jasnell: there is a fairly basic extensibility model already defined

<tantek> how can you NOT overlap with schema.org? it has nearly the whole world in it ;)

<harry> with schema.org at this point

jasnell: not fleshed out
... not clear how it will be used
... we need to go through the AS document itself and define the extensibility model from applications using it

<melvster> tantek: best asking john, but take a look at boards.ie, cimba.co, http://sioc.me/ ... all my work also uses sioc

jasnell: but if w3c wants to write a note saying this is how we define extended vocab for specific domains

<tantek> melvster - thanks! will do.

<dret> proposal: write up two short "extension vocabularies", one in RDF, one in non-RDF, and take those as test cases for how well AS2 defines its own extensibility.

jasnell: I don't think we sohuld put that in AS doc itself
... Happy to take things out
... Happy to put things in external vocab, and let IG do it

Arnaud: let's see if we can converge
... we need to figure out how to close issue-16

<tantek> I'd like to encourage jasnell to drop non-core terms in his opinion

Arnaud: A notion of core vocabulary and what falls into it is a separate issue
... Question is whether spec provides for extension mechanism that is well defined to allow people to define vocabs elsewhere or not
... james says we should wait to see what that would mean

<dret> from my perspective to close ISSUE-16 is to cleanly separate, on a document level, the core spec, and the base schema.

Arnaud: erik says we should define it now
... so we have a well established framework
... these are the two opposing positions
... is that right?

<cwebber2> I'm not sure, doesn't json-ld already provide the extension framework?

<cwebber2> I'm confused as to what other extension framework is needed?

dret: yes that's right. From my pov I have a hard time imagining how we can define AS without defining extension model

<wilkie> yes, AS would be rather perfect if it were a base core + extension/extensible-discovery mechanism

dret: It's not something we can do later and say by the way this is how you extend it

<sandro> +1 dret: I have a hard time seeing how we can define AS without an extension model

dret: Implementations need to be aware of the extension model so they know how to deal with data that uses it
... So we need to tackle it somehow
... I cannot imagine how you would do it without

<akuckartz> A good extension model/architecture/framework is more important than a large core.

<jasnell> there is an extension model. you can add new things to it, if you see something you don't understand, you can choose to ignore it

<Zakim> tantek, you wanted to note that dropping terms is important too and to also note that being forward-compat only requires a "must ignore" rule

<dret> akuckartz++

<Loqi> akuckartz has 1 karma

<melvster> yes, json ld is extensible by design

tantek: two pieces of issue. one is what can we drop from core?
... Heard james call for concrete prposoals of things to drop
... I want to encourage james as editor to go ahead and start dropping some terms that in his opinion are not core
... And document that he has dropped them
... And wait to see who objects, and if they have implementations using those terms
... Otherwise, we can trust him to drop terms and shrink the spec

<jasnell> I have no problem dropping terms and handling those off to the IG to work on if they want

tantek: I want james to optimistically drop terms and wait for reaction rather than wait for consensus on every drop

<dret> yes, tantek, slimming down the base schema is good; http://localhost/github/W3C/SocialWG/AS1-in-AS2.html was the first step towards that. let's continue with that.

<dret> sorry: http://dret.github.io/W3C/SocialWG/AS1-in-AS2.html

tantek: The second point is regarding extensibility mode. I think at a high level I agree with dret that we need some form of extending the vocabulary. As far as what's needed for a v1 sepc, all we need to not paint ourselves into a corner is forward compatibility rules
... Typically includes some form of must-ignore
... That is, if an AS process encounters something not in spec, it must ignore it
... That gives us ability to include ability to define extension mechanism either in first version, or later

<dret> not really sure that's true, tantek. we also need to say what we expect implementations to expose, and what they can safely drop.

tantek: That buys us some time
... As to whether v1 needs a well defined extension model, I'm on the fence
... I don't think it actually needs it, but then again I'm not opposed if people come up with one

<cwebber2> +q

tantek: i wouldn't strongly object to that
... It would provide an opportunity for people to experiment with their own activities

<dret> that's why i was championing extended activities in the test cases, so that we say if/how they are expected to be reported to applications.

<sandro> +0.5 (not sure this is all we need) tantek: all we really need is a forward compatibility rule, saying implementations MUST IGNORE certain things (extensions).

tantek: and that kind of live experimentaiton with implementations would be useful

<jasnell> RSS and Atom used must-ignore without defining a more complete extension model without much difficulty

Arnaud: Thanks. I'd like to separate the two issues
... What's in core is different to whether we have extension mechanism

<Zakim> elf-pavlik, you wanted to discuss WG focuses on how to extend and IG focuses on vocabulary details

Arnaud: Tantek says the minimum is say implmeenations must ignore

<jasnell> must ignore is already documented in the spec

<cwebber2> elf-pavlik: ++

elf-pavlik: if we agree we need clear way to extend with custom terms, eg. aaronpk demo'd during face to face drink/eat, not in core spec but already in use, less pressure choosing what we want to include or not, because it's more relaxed to say it's not super important so it can go in extension

<tantek> jasnell - then you're done with the minimum :)

elf-pavlik: So unless we have clear way to extend, people might want to push things into core

<dret> concretely: if our AS broker drops everything i does not recognize, is it allowed to do that?

Arnaud: good point

<melvster> extensibility and forward compatibility are baked into the architecture of the web, and into RDF, need a new term, just add a vocab or version, and dont change existing terms (cool URIs dont change)

<tantek> melvster, that sounds like you're saying we actually don't need to provide an explicit extensibility mechanism ourselves

cwebber2: I was going to ask what's missing that json-ld doesn't provide, if we're using json-ld as extension, doesn't that provide a way forward to using new/additional terms?

<cwebber2> -q

<melvster> tantek++

<Loqi> tantek has 176 karma

<akuckartz> dropped terms can be used to test extension mechanism

<akuckartz> melvster++

<Loqi> melvster has 11 karma

<dret> didn't we say JSON-LD is optional?

<Tsyesika> cwebber2++

<Loqi> cwebber2 has 25 karma

<Zakim> elf-pavlik, you wanted to discuss cwebber2 q

<dret> or did that change? sorry if it did...

<tantek> JSON itself has a custom / history of people adding new terms as needed (extending) anybody else's JSON structure

elf-pavlik: didn't we say json-ld optional? So that's why we have extensibility problem. If we say we use this for extensions, people will want to push to core for people who aren't using rdf

<cwebber2> ah right I forget that it's optional ;p

elf-pavlik: issue 36
... relates to that

<cwebber2> could we say "optional, unless you add extensions"? :)

elf-pavlik: problem is that if we don't require json-ld processing, then we cannot recommend directly json-ld as extension

<dret> cwebber2, optional unless it's not? that's a weird interpretation of optional.

jasnell: as far as extensions are concerned, syntax is currently json with json-ld @context. If somebody throws something into that document, if it's not defined in @context, the jsonld expansion mechanism drops it
... without throwing any errors

<wilkie> people are *going* to extend it. ostatus was extended immediately, even by identi.ca, to add things not in the spec proper

jasnell: which is consisten with what our existing document does
... if an implementation feels that additional bits of information are important, it will do the work necessarily to support those

<dret> but can intermediaries do that? drop unsupported things because they parse/reserialize?

jasnell: either by adding an extended version of its own context, or doing some preprocessing
... it still fits within the existing definition in the spec that says ignore anything you do not understand

<tantek> wilkie, agreed. I think the difference is that perhaps we're ok with unofficial / undefined forms of extension

jasnell: if someone comes up with a new activity type, our exisitng model allows that with no problem

<tantek> rather than a formal extension mechanism

<dret> we need clear rules for intermediaries.

<tantek> what is an intermediary?

jasnell: it's specififed with a URI in json or json-ld, and the processing can pick it up, if you odn't understand you ignore, if you understand, great
... We agreed weeks ago that rdf reasoning is not required
... You don't need to know that a Like is a kind of Response

<melvster> FYI: @context is optional in JSON LD, it is just a short hand or those that dont wish to type out full URIs

jasnell: If someone wants to come up with a new kind of response, they can do high level reasoning if they want, or ignore it

<dret> tantek, it's something that consumes AS and republishes it to other consumers. same as in RSS/Atom scenarios.

<wilkie> it would be nice, then, to have at least a recommendation to help identify extensions that are useful

jasnell: Extensibility in there now is the same as in AS1.0, and in Atom and RSS - very successful
... Not sure what the problem is

<cwebber2> this is why I think we should have a good core, then most people don't need extensions

<cwebber2> then if they do, hey!

jasnell: If you find something you don't support, ignore it

<cwebber2> json-ld!

<dret> problem is RDF-based implementation that may drop things in the middle. can they?

jasnell: If you think you have to understand, write your implementation to handle it

<tantek> I agree with jasnell

Arnaud: So we could close issue-16 without doing anything?

<tantek> we don't need need any more of a defined extensibility model

jasnell: IMO we don't need anything else unless we get into reasoning
... If the IG wants to say here's how we do higher level reasoning, the we can have anote

<melvster> jasnell++

<AnnB> the IG will need some additional folks, with diff skills ...

jasnell: as far as the base is concerned, nothing more

<Loqi> jasnell has 10 karma

harry: we could put the question back to dret, we're clear that rdfs reasoning isn't required, what is jasnell not specify that needs to be clarified?
... is it the extension of the name?

dret: one scenario is that we have activites that are published, consumed, republished, aggregated, filtered
... a whole ecosystem of activities, not just end ot end

<melvster> dret++

<Loqi> too much karma!

<harry> maybe you should write that down and email the list

<tantek> does AS2 spec says what intermediaries must or should implement?

dret: question is that is someone sees an activity that has extensions they dont' recognise are they allowed to drop those because they're not translated. Can implmeentations silently drop stuff?
... Or maybe if you don't understand stuff, you need to make sure you don't drop them if you need to republish

<Zakim> elf-pavlik, you wanted to discuss why we don't use our extension mechanism for AS Extended Vocabulary?

dret: things could get lost in the middle

<harry> The dropping stuff is a good question.

<jasnell_> yes, extensions can be dropped. just like we have in RSS and Atom

<tantek> I will note that there are no user-stories about intermediaries

elf-pavlik: if we concede our current mechanism useful, I prose we publish our extended vocabulary ..?..
... if it works correctly we should use it?

<cwebber2> kind of broke up towards the end

<cwebber2> elf-pavlik: could you type that?

<Zakim> tantek, you wanted to propose intermediaries out of scope for this version

<jasnell_> if someone wants to create an additional spec that describes how extensions can be supported beyond the core, more power to them. it doesn't need to be in the spec

<jasnell_> in the core spec that is

<harry> I recommend we take this to the mailing list...

<elf-pavlik> PROPOSAL: use our extension mechanism for AS Extended Vocabulary

<harry> or IRC :)

<elf-pavlik> similar to sioc: sioct:

tantek: we didn't come up with these scenarios in any users stories. it's a useful concept, but for current version of the spec out of scope

<harry> I have no idea what that proposal means elf.

tantek: [intermediate publishing]
... reassess including in next version of spec

<harry> An extension mechanism is different than a vocabulary

<jasnell_> tantek: +1

<elf-pavlik> harry don't include extended vocabulary in AS vocab

Arnaud: what proposal to close issue 16?

<harry> I would agree with that.

<elf-pavlik> but publish it and use it as extension

Arnaud: James said do nothing

<tantek> agree with jasnell_ proposal +1

<jasnell_> Proposal: Close Issue-16, we already deal with extensibility in the spec

Arnaud: others say we need to do more
... someone would have to draft that

<harry> Why not dret draft somethng?

<ben_thatmustbeme> +1 for do nothing

<elf-pavlik> dret let's do it together for next week?

<harry> +1 dret drafting

Arnaud: burden on you dret, to propose what you want to see in spec

<tantek> additionally

<tantek> PROPOSAL: explicitly declare intermediaries out of scope for this version of the spec

dret: I think I've done that often enough. What I think we should have is a processing model that clearly lays out rules for how implementaitons are supposed to behave

<tantek> +1 jasnell_ proposal

dret: And have base schema as test case for ourselves

<jasnell_> An implementation guide that deals with extensibility would be great for the IG to produce

<elf-pavlik> dret base schema == extended vocabulary ?

dret: I have written that often on mailing list
... If nobody agrees, then so it is

harry: what is the concerete problem?
... whether to drop vocab items? There is a list of questions of this sort. Be good if you turned them into possible changes to spec

<AdamB> could the intermediaries come in to play during federation conversation

harry: See if group accepts

Arnaud: agree

<jasnell_> agree

<dret> the problem also is: how do i define i vocabulary? how will this work in an implementation?

<elf-pavlik> dret let's work on PR together!

harry: I can imagine there are many different subsets of question 'what is processing model'

<cwebber2> I think an extension model on top of json that tries to be pretty clear is going to look a lot like json-ld :)

<harry> AdamB, I think it could be

Arnaud: proposal from tantek declaring it out of scope for this version

<elf-pavlik> intermediaries?

<harry> I'm not comfortable with it being out of scope quite yet

<dret> elf-pavlik, sounds good!

<jasnell_> I don't think we need to declare them out of scope explicitly

<harry> However, a concrete proposal is needed.

Arnaud: we'll leave it at this

<wilkie> an extension mechanism could be an extension that somebody just does haha

<cwebber2> I also think if we cut down the vocabulary as much as possible and leave no room for extending the vocabulary simultaneously

<cwebber2> that's going to be

Arnaud: I want to give erik a chance. Do you want to kee pissue 16 open?

<cwebber2> a fraught situation

<elf-pavlik> yes, let's keep it open

Arnaud: You're always free to come up with a proposal anyway

<harry> I think the 'dropping stuff' issue is interesting

Arnaud: Most people say we should just close it as is

<harry> and could have ramifications down the road

dret: if that's what the majority wants to do, sure

<tantek> cwebber2: it's a way to get dependable interop - not fraught!

<tantek> opposite of fraught

dret: from my pov it's not good implementaiton guidence

<Arnaud> PROPOSED: Close Issue-16, doing nothing - we already deal with extensibility in the spec

<tantek> +1

<ben_thatmustbeme> +1

<jasnell_> +1

<dret> -1

<cwebber2> I'm too confused to vote :)

<elf-pavlik> -1 unless we use current model for publishing extended vocabulary itself

<harry> +0 (would prefer to see dret write a concrete change, but am against pointless discussion until we have a change-set)

<wilkie> I'm a little confused as well. haha. is this about extensible vocabulary or extensible actions??

AnnB: I don't follow very well. Seems like vocal people against not vocal people

<ShaneHudson> +0 I also don't follow it too well but sounds like a good proposal.

AnnB: Somebody said it seemed premature to close it

<bret> +1 close the issue, reopen with concrete changes

Arnaud: we have objections, we're not going to close it

<tantek> did we make any progress in this discussion?

Arnaud: People who object have concrete proposals about how to change the spec

<cwebber2> I will agree that this conversation is probably not very helpful

Arnaud: Say 'this is the text i want to add to spec'

<elf-pavlik> we will work on PR :)

<cwebber2> and I guess since I thought it was implied that you use json-ld for extensions as it is anyway

<elf-pavlik> PR - Pull Request

<cwebber2> I guess I'm for closing it????

jasnell: whatever change in this area, that should also try to detail why the existing text does not work

<tantek> jasnell++

<Loqi> jasnell has 11 karma

<Tsyesika> cwebber2: but dind't people say JSON-LD shouldn't be required (even for extensability????)

<harry> Yep, but I think dret had that use-case - i.e. what if stuff gets dropped?

<Tsyesika> *didn't

jasnell: Put a use case on the table and describe why the existing spec fails, and why the new proposed text passes

<cwebber2> Tsyesika: I didn't realize it was said "dont' use it *even for* extensibility"

<harry> in between serializations

<cwebber2> I misread that whole thing as

jasnell: At this point, I'm failing to see why the must ignore rule doesn't work

<cwebber2> "you don't need it probably because the core context will be good enough"

<cwebber2> "for most people"

Arnaud: fair, let's move on

<cwebber2> but oh well

<dret> use case: how am i expected to define extended vocabularies in a way that makes implementation behavior predictable. that's my only concern.

<cwebber2> apparently I didn't understand

<harry> The use-case is: Ship AS2 to node, process, [MAYBE drop optional stuff], ship back out.

<Arnaud> PROPOSAL: Open raised issues ISSUE-26-36

Arnaud: Some propsals to get through

<harry> That will likely happen in federation

<Tsyesika> cwebber2: i'm not sure i do either given what has been said

<cwebber2> one thing's for sure, people are confused!

<tantek> I'm ok with opening issues that James raised without analyzing them in detail.

Arnaud: By opening raised issues, we accept burden of having to close them for CR

<jasnell_> +1 to opening 26-36

<wilkie> I don't mind dropping explicit conversation about extensibility as long as extensibility is intuitively obvious and possible

<tantek> (even if I don't agree with some of them on first glance)

<elf-pavlik> -1 since issues can start popping up like mushrooms after rain

Arnaud: just issues 26-36
... Instead of going through one by one, lets open them all

<tantek> elf-pavlik: come now, you've raised more issues than anyone else ;)

<KevinMarks> nice thing about html classes and json keys is that they are intrinsically extensible by adding new ones

<elf-pavlik> -0

elf-pavlik: concerned about too many issues... maybe worrying too much ahead

<jasnell_> are you going to capture the proposal so we can vote?

Arnaud: we're just discussing these raised issues

<aaronpk> +1 to opening 26-36

Arnaud: Please vote

<ben_thatmustbeme> +0, i'm concerned it will take too long to close them all again

<wilkie> I'm reading them!! looks ok

<wilkie> +1

<jasnell_> oh.. missed it, you already did :-)

<bret> +1

Arnaud: Closing them is a concern, but we can't ignore them

<jasnell_> most of the issues should be quick

<elf-pavlik> we can create them more carefully

<jasnell_> most of this particular set

<tantek> jasnell_: re: "ISSUE-4 - Explicit typing or support implicit typing - Already

<tantek> addressed in current draft" - could you provide URL to place in the draft that addresses it?

Arnaud: The other option is go to them one at a time

<harry> I recommend that these are all minor issues that the editor can dela with

<elf-pavlik> tantek++

<Loqi> tantek has 177 karma

<harry> except for 'profiles' i.e. 26-27 issue

Arnaud: If there is a specific one you don't want to open, you can say

<harry> that we punt to the IG

Arnaud: Not taking any action is not a good option

<jasnell_> the draft currently uses explicit typing... that's how it addresses it ;-) ... if you want to add implicit typing, I'd need a proposal

<tantek> I object to closing an issue with "draft addresses it" without a URL to the specific fragment that addresses it.

<harry> unmute Zakim

<harry> unmute me

<tantek> so that any such issues can at least be turned into an FAQ!

harry: looking at these I'm happy for issues of minor status for editor to handle all of them, except 26-27 should go to IG
... many ways to represent profiles
... either use vcard or keep it out of base schema

Arnaud: in terms of things we can use, all raised by jasnell because he wants input, if we tell him to go ahead and fix it himself, but he needs backing from wg

<ben_thatmustbeme> 27 looks more like an issue of activities, not profile

<harry> My feeling is issue 26-27 re profile means either vCard (the only normative standard in the space) or nothing.

<tantek> harry, yes - vCard is the only spec here from IETF, however h-card is also an open spec, and based on vCard so h-card is also citable (which maintains vCard compat)

Arnaud: if we open them, james can make a proposal, and we can decide whether to close

<ben_thatmustbeme> +1 to open them all

Arnaud: but people always seem to hesitate and we get stuck
... we can not just have all the edits happen undocumented without WG input

<harry> The rest of these are rather minor at best but if James wants to open them, go for it.

jasnell: The profile ones: the point of raising them is that we need a WG decision on how to handle profiles. I don't want to not raise the issue just because someone thinks we should just use vcard, that short circuits process

<harry> vCard is the only normative spec here.

jasnell: User stories have profiles, but spec doesn't
... I need WG decision on this matter

<harry> It's a separate vocabulary that is well-specified already.

<tantek> harry - what do you mean by normative spec? per normative reference policy?

jasnell: user stories are voted on, we have to have some kind of profile support

<harry> Yep, at current moment.

jasnell: If all we want to do is use vcard, let's open issue, make decision, I'll get it in spec and we'll close issue

<tantek> harry - my understanding is that h-card is also referencable - per discussions at MIT during our f2f

Arnaud: only a few +1s

<harry> However, I'd prefer that profile stuff go to IG since people have different profile vocabularies they like for various idiosyncratic reasons

<cwebber2> +1 sure

Arnaud: Are people confused?

<cwebber2> let's do it and keep going

<aaronpk> this is still the 26-36 proposal right?

+1 from me, busy scribing to vote

<jasnell_> The proposal is only to open the issues NOT to decide on any specific one

<harry> Last time I checked, hCard maps to vCard

Arnaud: proposal is to open issues that have been raised, 26-36

<harry> (I would hope)

<AnnB> +1

<tantek> harry - right, it's actually a more useful subset

<Arnaud> PROPOSAL: Open raised issues ISSUE-26-36

<jasnell_> by opening the issue we open the issues up for discussion

<tantek> h-card is simpler than vCard in that regard

<ben_thatmustbeme> I think people were not willing to vote so quickly until they reviewed them, thats why the slow voting

Arnaud: Proposal again, please vote

<tantek> has less hierarchy

<aaronpk> correct me if i'm wrong but opening them does not mean you're voting on accepting any particular resolution on them right?

<Tsyesika> +1 sure

<harry> Agreed vCard has lots of legacy

<ben_thatmustbeme> but I think we have a pretty good list of +1s

<harry> but I don't want us to roll another vocabulary

+1

<jasnell_> +1

<AdamB> +1

<tantek> harry, by adopting h-card, it's easy to directly map to vCard

<elf-pavlik> aaronpk, correct just formally opening them

Arnaud: communication doesn't seem to be working well here..

RESOLUTION: Open raised issues ISSUE-26-36

Arnaud: No -1, resolved

<Arnaud> PROPOSAL: Close the following issues: ISSUE-4, ISSUE-7, ISSUE-12, ISSUE-14, ISSUE-15, ISSUE-20

Arnaud: James proposed to close some issues with explaination of why

<elf-pavlik> -1 not resolved

<tantek> ok with closing the issues except 4

Arnaud: This doesn't have to take very long if people look at the proposal before the meeting

<tantek> stated my objection above

<cwebber2> +1 on closing

Arnaud: You can object to one, name it and we can remove it from list and close the others

<tantek> +1 on closing all but issue-4

elf-pavlik: issue 14 should not be closed
... not sure about 20

Arnaud: any others?

<Arnaud> PROPOSAL: Close the following issues: ISSUE-7, ISSUE-12, ISSUE-15, ISSUE-20

<ShaneHudson> +1

<jasnell_> +1

<elf-pavlik> issue-12

<trackbot> issue-12 -- Action Types Structure and Processing Model -- open

<trackbot> http://www.w3.org/Social/track/issues/12

<elf-pavlik> dret ?

<ben_thatmustbeme> +1

+1

<jasnell_> for Issue-4, tantek: I'd need a concrete proposal on spec language changes

<tantek> +1

<wilkie> +1

<tantek> jasnell - agreed that's why there's an open action on it! but that keeps the issue open.

Arnaud: anyone else?

<cwebber2> +1

<elf-pavlik> -1 issue-15

<AnnB> abstain

<tantek> to *close* it with the "spec already handles it" claim - you need to provide a URL to that specific "handling" of it

<jasnell_> tantek: it's been open for a while so the idea of closing was to either prompt a proposal to keep it open or close to see if anyone complained :-)

Arnaud: Remove issue 15 and close the rest. Better than none

RESOLUTION: Close the following issues: ISSUE-7, ISSUE-12, ISSUE-20

Arnaud: My hope is we can do this every week
... Some require discussion, which could take place elsewhere
... We can narrow down discussion to what is controversial
... Does require prep work for everyone

<jasnell_> for Issue-14, a concrete proposal on spec language and a clear explanation as to why the current text doesn't work would be most helpful

Arnaud: Let's move on
... 30 minutes
... I bet if you drop of the call now you won't be able to call back
... the way Zakim works

<harry> The reservation is for 2 hours

Social API

<harry> So people should be able to dial back in

elf-pavlik: issue-10 about candidates. Would be useful to clarify if we can use Micropub wiki page as formal dependency

<tantek> aside, jasnell for that issue 4 / action 35 - the best I have so far is working notes on http://indiewebcamp.com/posts#Inferring_post_kinds_from_properties

elf-pavlik: I don't think we can use it

<tantek> why not?

http://indiewebcamp.com/micropub

tantek: What's the issue?

<bret> sounds like a normative reference issue

tantek: We've discussed this, and had this approved with timbl during f2f at Cambridge. If you have a spec with open licensing that's compatible with w3c IP policy, and some statement of stability, we can normatively reference it

<jasnell_> tantek: without a concrete proposal on modified spec language it's going to be difficult for me to come up with a resolution for Issue-4.

tantek: Unless there's a specific reason this can't be done, I understand we can reference micropub or microformats specs

<jasnell_> ben_thatmustbeme++

<Loqi> ben_thatmustbeme has 62 karma

tantek: If there's the question of stability, please raise and editors of specs can improve

<elf-pavlik> harry?

<jasnell_> tantek: would you want to create an official mapping of the AS2 vocabulary to microformats in a note or rec?

elf-pavlik: not about technical feasiblity, just formal. Would like harry to confirm we can safely reference

<tantek> jasnell - I think that would be useful, figuring fixing the examples in AS2 is a good step towards that.

<tantek> hence I was working on fixing the microformats examples in AS2 - hoping that helps

harry: I think it came to resolution that it's okay, I can double check. I don't think it's a problem. The real question is for the API we have a separate - referencing microformats normatively is okay - but as the working group we need a separate spec
... We're expected to produce a w3c rec on this, not just reference something else

<tantek> we could produce a spec that incorporated the necessary parts of micropub and microformats to make a Social API

elf-pavlik: so we can't just spec that has two lines and links to wiki page of micropub

harry: no, ipr is very different
... would appreciate if the working group focused on technical quesitons and stopped wasting time on process questoins

<cwebber2> harry++

<Loqi> harry has 9 karma

harry: Real question is what are technical differences between micropub and LDP and activitystreams

tantek: that was a strawman, no-one proposed that

<harry> From a formal perspective, we need a spec that has the text written out

tantek: the point was that rather than having to fork micropub, we can normatively reference them and pick and choose what this wg needs for our user stories, rather than taking them wholesale
... without having to duplicate everything

harry: it is fine formally to take an API from somewhere else and use it as a base for new work
... The question is not can we do this with micropub, but does the group have consensus on the approach

tantek: yes, different question
... would rather have that discussion

harry: will double check
... if wendy said yes and tim said yes, answer is yes

<elf-pavlik> ok!

Arnaud: we need to focus on technical aspects

<harry> *if* the IPR is fine, we can put it in as a candidate

<harry> But we saw no blocks at least on early discussion between Tantek and TimBL on this, I can make sure Wendy Seltzer is fine with the result.

<harry> ACTION: hhalpin to discuss with wseltzer to make sure this is fine [recorded in [[1]|http://www.w3.org/2015/04/07-social-irc]]]

<trackbot> Created ACTION-59 - Discuss with wseltzer to make sure this is fine [on Harry Halpin - due 2015-04-14].

<tantek> thanks harry

jasnell: If we could get a proposal for a draft (note, rec track, whatever) of a microformat binding for AS vocabulary - a normative mapping - if that needs to include some micropub stuff, great, let's have someone produce an initial draft
... that we can use to inform the rest of micropub to w3c discussion
... please somebody write something down

<tantek> totally reasonable request jasnell

<cwebber2> speaking of, next topic is about a candidate :)

<cwebber2> so we can talk about candidates!

<harry> I think some sort of base that we modify is usuall a pretty good method :)

<tantek> I'm just hoping to avoid duplicating spec text

jasnell: Can we get this as a proposal and assign an action?

tantek: at the f2f that was the conclusion

<jasnell_> so who is going to write that

tantek: that was the concrete request for *all* candidate APIs, to produce a draft, even if just minimal, to say here are the pieces for a social API

<jasnell_> then can we table the conversation until those drafts are actually available

tantek: That call for proposal drafts was made at f2f
... We already agree on that

<AnnB> Tantek: check the minutes from F2F ... AnnB adds: we NEED those minutes!

<AnnB> they are still messed up

tantek: That's open right now, we just need people to bring drafts forward

Arnaud: let's move on

ActivityPump call for help

<Tsyesika> mine

<AnnB> Harry -- can you pleaaaase figure out those minutes?

Tsyesika: call for pump.io members of the WG

<cwebber2> oshepherd's original spec: http://oshepherd.github.io/activitypump/ActivityPump.html

Tsyesika: I've forked osheherd's ActivityPump spec and I'm going to use that as a base and look at all the user stories

<ben_thatmustbeme> AnnB, I believe he said he would look at what is going on with those at the beginning of the call

<cwebber2> https://github.com/w3c-social/activitypump new repo

Tsyesika: And try to pull together the people in the WG and come up with a draft that we can propose
... for the Social API and federation API

<AnnB> oh, good .. thanks. I didn't hear that

Tsyesika: I'm just asking people to help
... Unfortunately evan isn't on the call
... that's all I wanted to ask
... And also it's currently hosted on the w3c-social organisation, but I believe harry will set it up so we can have it on the main w3c organisation on github, which I don't have access to at the moment

<cwebber2> +q

<jasnell_> the test suite should go under the same location

<harry> yep, we'll mov everything to github and folks should get invites

Arnaud: So we heard a call for help

<tantek> hey dret do you run @socialwebwg ?

<harry> However, until we get agreement on API, let's keep it in w3c-social github organization

<harry> And we'll just have a blank space in the W3C repo

cwebber2: There are couple of issues we already know we need to go through

<harry> Sound OK?

cwebber2: probably this is for a future call: now that we're not addressing auth in the WG

<harry> Note authentication working group is likely to start in fall if people are interested in that topic

cwebber2: There are issues there for peopel interested

<Tsyesika> harry: that's fine

Arnaud: harry will create repo
... Anything else?

<elf-pavlik> i made PR

Arnaud: Anyone want to volunteer to help?

<tantek> dret, if you've got the keys for @socialwebwg - mind sharing with the chairs (perhaps on a private channel like email ;) ) so they can tweet from it as well?

<cwebber2> thanks elf-pavlik :)

Arnaud: Move on

WG+IG Workflows

<cwebber2> damn phone lacks a proximity workflow

<cwebber2> I apologize about the beeps

<cwebber2> er

Arnaud: elf has been trying to get us to be more organised

<cwebber2> proximity sensor is broken

Arnaud: We already had intiially discussed chairs to produce agenda by friday before the call
... Not always easy

<cwebber2> oh, good AnnB

Arnaud: elf suggests we develop agenda a week before

<tantek> I don't understand - we already develop the agenda in advance

Arnaud: i saw an email from evan objecting to trying to freeze agenda early
... I do agree with elf there is value in people looking at agenda and prepare for call
... If people can look through things like proposals before hand we can be much more effective
... There always are proposals you can't plan ahead of time, but there are some things people can have an answer ready for

<tantek> what's the actual problem? if people always add to the end it's unlikely we'll have problems

Arnaud: I don't know what else to say on this

<tantek> I don't think it discourages anyone

elf-pavlik: just an attempt, comparing to the start, we didn't have so many open issues, but now we have tons of stuff, we have enough to prepare agenda a week before telecon. By freezing them we can add an urgent issue, but it encourages people to look early and follow the links

<tantek> we don't need more structure for this to work

elf-pavlik: Not super strictly freeze it, but enough to give people time to prepare

<wilkie> we need to discuss these issues on the mailing list during the week

<aaronpk> or irc ;)

<cwebber2> at least normatively, I think it's a good idea elf-pavlik

elf-pavlik: We can at least try our best to close on friday to give people time to prepare

<cwebber2> I'm not sure a hard enforcement is good

<Tsyesika> I like the idea

<harry> I'm pretty neutral here

Arnaud: reactions?

<jasnell_> agree with tantek: we don't need more process, we need to people to read the issues and provide *technical* input with as opposed to process discussions

<cwebber2> I agree we don't need more processs though yeah

tantek: I don't see the problem. If people simply add agenda items to the end, if the agenda gets too long we don't get to items that are added late

<harry> +1 no more process

<cwebber2> I feel like there's plenty of process in this group :)

<harry> +1 more practical preparation

tantek: If you read through the agenda by Friday you're probably goign to be ready for it
... In practice it's not a problem

Arnaud: any other opinions?

<ShaneHudson> I agree with harry, preperation over process

<cwebber2> maybe make it into a normative suggestion rather than a workflow

Arnaud: that's it then

<cwebber2> and that's simple :)

<elf-pavlik> nope

<tantek> (~7 minutes left)

<elf-pavlik> Coordination with IG

<cwebber2> nope we can move on it sounds like

<ben_thatmustbeme> i don't think so

<cwebber2> +1 to moving on

<cwebber2> :)

Coordination with IG

<elf-pavlik> o/

Arnaud: who put that on?

tantek: If you put something on the agenda, please add your name on wiki

<cwebber2> good call tantek

<cwebber2> will do in the future

<tantek> thanks cwebber2!

elf-pavlik: I can explain

<tantek> appreciated

elf-pavlik: In IG we have effort to clarify user stories that have minor objections, on github
... Everyone adopts one or two and asks people who objected to discuss further
... I invite everyone to participate, especially people who objected
... Also, Vocabulary TF works on extracting vocab requirements from user stories
... There's a wiki page we tried to map all terms used in user stories

https://www.w3.org/wiki/Socialig/Vocabulary_TF/Mapping_API_User_Stories_to_Vocabulary_terms

scribe: Invite everyone to participate in that
... But especially with use cases, please work with people in IG if you had objections to clarify

Arnaud: any comments?
... If not, we can close the call on this
... One question: extend our weekly calls?

<AnnB> +1

<AnnB> (for extending)

<Arnaud> PROPOSED: extend weekly calls by 1/2h moving forward

<cwebber2> +0 to extending

<elf-pavlik> +1

<wilkie> +0

<harry> +0

<tantek> -1 for extending next week (I'm chairing :P )

<bret> +0

<harry> would prefer not to have lunch

<aaronpk> +0

<Tsyesika> +0

<harry> :)

<jasnell_> +0 to extending. I'd rather extend as necessary

Arnaud: If we end up using an hour it's okay

<akuckartz> +0

<wilkie> rhiaro: aww

<ShaneHudson> +0 I've not been too useful anyway, but it is now half 7pm so 1 hour was a bit nicer.

<Loqi> cute!

AnnB: we need people to sign up to f2f in paris

tantek: do we have minimum count?

harry: we had more people say yes on the poll

<elf-pavlik> https://www.w3.org/wiki/Socialwg/2015-05-04#Participants

harry: it would be nice ot have some kind of quorum

<wilkie> rhiaro: one of the most disappointing things for a grad student to miss

<elf-pavlik> http://doodle.com/8fa27m9ryx6d26rb

<ben_thatmustbeme> 0, i hope it was just needed this week, I likely can't stay the full 90 minuts most weeks

<Tsyesika> i prefer not having an hour and a half meeting as it's evening in europe

Arnaud: can we close call extension

<ShaneHudson> Are there any options for funding for f2f?

Arnaud: It feels like it's been more productive

<Tsyesika> I also wonder if we've just cleared the backlog

<jasnell_> +1

tantek: now we've done 1.5, see if we're okay at 1 hour again

<ben_thatmustbeme> i hope it was 1 hour just to catch up

Arnaud: let's go back to 1 hour for now

<AdamB> what about alternating between 1 hr and 1.5 hrs

Arnaud: We can reconsider

<ben_thatmustbeme> i hope it was 90 minutes just to catch up

tantek: I promise to move things along as quickly as possible next week

jasnell: won't be in Paris

Arnaud: I have made reservation

<AnnB> me too

<aaronpk> same, already got flights and such

Arnaud: Still worthwile even if there are only 8 people
... But people need to sign up

<wilkie> I couldn't even afford to go to boston lol

<akuckartz> Yes, 8 people can be very productive!

<jasnell_> sorry I will not be able to make it. It's a personal conflict, not work. It's not something that I'm able to reschedule.

AnnB: harry you said there are other people in Europe interested, can we arrange for them to be there

harry: maybe one or two would stop by
... I've emailed them
... One has put their name on the wiki

Arnaud: we're out of time

<dret> thanks everybody, especially the chair and the scribe! <harry> Hey

<harry> I just talked to timbl and wseltzer

<harry> I think the answer re microformats is it depends on the stability

<harry> things marked 'stable' are fine

<harry> but some of it isn't.

<elf-pavlik> what about http://indiewebcamp.com/micropub ?

<harry> I think TimBL is thinking mostly re vocabularies

<tantek> harry - right - hence a need for more explicit stability markers - which is fine

<bret> the vocab of micropub is based on mf2, so stable?

<harry> Re micropub, the question is 1) do you want to reference it?

<tantek> especially in specs which include stable, in progress, and proposed stuff

<tantek> harry, re: reference it yes

<harry> or 2) do you want it as the base of the Social API?

<harry> I think for 1) we're fine as long as the vocabularies are stable.

<tantek> and it has the same licenses / stability as microformats specs

<harry> and are marked explicitly as such

<tantek> agreed

<harry> TimBL thought some stuff was unstable in some microformats spec

<tantek> I think we can use some iteration on the stability documentation

<harry> but he was happy as long as its marked clearly what is stable and what isn't.

<harry> Now, it's a mildly different question

<tantek> right - that's my understanding as well

<harry> is OWFa comptable with W3C RF?

<tantek> there are both stable portions of vocabulary, and in-progress / proposed portions

<harry> I think the answer is "in general, it's not as strong, but broadly compatible"

<tantek> that sounds similar to what I believe Moz lawyers said to me too

<tantek> harry, however, my understanding from lawyers is also that OWFa *is* stronger than IETF's fairly vague patent non-asserts.

<harry> yep

<harry> So, WORSE case

<harry> we go forward

<tantek> so as much as W3C is happy to normatively reference IETF, there should be no problems referencing OWFa

<tantek> .. licensed specs

<harry> and we get a non-member licesning agreement from whoever is not a W3C member and not member of the WG

<harry> that has contributed to micropub

<harry> Who has contributed to micropub?

<tantek> harry, from my understanding it is nearly all aaronpk (WG member), and some from others most of whome are also WG members (e.g. ben_thatmustbeme )

<tantek> nice thing is that it's all in the wiki history

<tantek> for anyone to transparently see

<tantek> http://indiewebcamp.com/wiki/index.php?title=Micropub&action=history

<tantek> for any normative additions by anyone who is not in Social Web WG (or some other W3C WG), we can request they commit their changes per the license in the spec CC0+OWFa

<tantek> no need for non-member licensing agreements

<harry> cool that should make it easy

<tantek> in fact I'll add that to the spec right now as a contribution requirement

<harry> yeah, we may have to do that, but that's a pre-CR thing

Socialwg/2015-04-07-minutes

Social Web Working Group Teleconference

07 Apr 2015

Attendees

Contents

Summary of Action Items

Summary of Resolutions

Approval of minutes

Tracking of actions and issues

Activity Streams 2.0

Social API

ActivityPump call for help

WG+IG Workflows

Coordination with IG