2015-04-07 UTC
bengo and tantek joined the channel
# 04:06 aaronpk has the raw IRC log, the problem is I need the IRC log as processed by whatever bot understand scribe and such jaywink joined the channel
AnnB and pfefferle joined the channel
# 07:03 AnnB elf-pavlik, you there? # 07:03 AnnB or anyone else, most likely in European time zones? # 07:04 AnnB I'm going to bed .. but seeking feedback on the user stories I added to GitHub # 07:05 AnnB these are stories which had "minor objections", which we (in the IG) are going to try to resolve # 07:05 AnnB I just want to know if I posted those in the correct format the_frey and almereyda joined the channel
bengo joined the channel
melvster joined the channel
# 12:24 melvster hi folks, I have a use case which might be relevant here : # 12:24 melvster I have a chat system, which can also act as a public room, or single user room, id like to turn that room into a radio station, tv station using a stream of media # 12:25 melvster so I add a play list to the room, which is a list of links (they could be youtube videos, soundcloud songs, slideshow etc.) # 12:25 melvster then the room will play the list to you, one by one, and remember where you are in the stream # 12:26 melvster the stream could be added to by an agent, by a recommender agent, or by a search service # 12:26 melvster anybody anywhere close to solving anything like this? # 12:26 melvster if there's something not too complex, id be happy to reuse it, or I'll just create a play list Object pfefferle and melvster joined the channel
almereyda, AnnB, bengo, dret, eprodrom, tantek and the_frey joined the channel
cwebber2 joined the channel
# 16:35 cwebber2 does that make sense and fit with what you were saying? # 16:36 cwebber2 also tempted to move the "tracking of actions and issues" to the end of the page # 16:38 aaronpk the goal of "supporting static sites" could also be rephrased as "support serving your content from a CDN" # 16:39 aaronpk basically don't put the burden on the user's domain of dealing with anything besides GET requests for content # 16:39 melvster elf-pavlik: user profile management v2 sounds good, I hope you saw Andrei's working proof of concept, of this at the F2F ShaneHudson joined the channel
# 16:41 melvster re: moving profiles, this comes up over and over, and bblfish is right, cool names dont change, in real life how many people change their name, ok elf-pavlik has, but for many or most people the disadvantages outweigh the gains, because you have to inform everyone that called you by one name that you are another, too much of a pain # 16:42 cwebber2 aaronpk: yes, that sounds like what I said in my email, do you agree? # 16:42 melvster like any good parent choose a name carefully in the first place, and realize you could be stuck with it for a while or forever ... # 16:42 cwebber2 I got rhiaro to explain to me what the goals were of the indieweb people after last meeting :) # 16:43 aaronpk yeah using rel tags to point to the various endpoints accomplishes that # 16:44 rhiaro melvster: I know lots of people who have changed their names # 16:45 aaronpk yeah i know plenty of people who changed their names # 16:45 wilkie I know tons of people who changed their names # 16:46 melvster rhiaro: sure, but I also know lots of people that havent # 16:46 rhiaro and I think discounting it based on being a minority is a terrible idea, obviously! # 16:46 wilkie the ability to change one's name is a human right # 16:46 rhiaro the last thing we want to be doing on the social web is excluding minorities.. # 16:46 cwebber2 rhiaro: I'm not sure that it's so easy to incorporate it into the spec, and we might decide it's tough to find a good technical solution # 16:47 rhiaro technical/complexity arguements I can accept, but 'not enough people do this irl' I will argue # 16:47 tantek elf-pavlik, ben_thatmustbeme upon reconsideration, and per discussions last week, I'm not sure *any* profile management is needed for v1 of a social API # 16:47 tantek profile management is more like a recasted VCARDDAV # 16:48 cwebber2 tantek: wouldn't it make sense to have a vocabulary for it though? akuckartz joined the channel
# 16:48 cwebber2 I think it would be strange to not include it, we'll certainly need it # 16:48 tantek cwebber2: that vocabulary is called vCard, hCard, h-cared # 16:48 cwebber2 tantek: yes, you can argue that, and thus wouldn't it make sense to argue that it goes into the default context? # 16:49 tantek cwebber2: I think it's strange to include things that others have shown are not necessary for a social API (e.g. micropub), I also think it's strange to assert "we'll certainly need it" without saying *for what purpose* # 16:49 tantek these kinds of theoretical requirements are why we feature bloat in designs and architectures # 16:49 cwebber2 tantek: I find it really annoying when you say "when we have shown are not necessary", because it excludes those of us who have found it is necessary # 16:49 tantek cwebber2: really? "have found it is necessary" = does that mean you've shipped something that does it? # 16:50 cwebber2 tantek: pump.io has yes, and we're planning on supporting it for mediagoblin, yes # 16:50 tantek cwebber2: everytime someone asserts a requirement that they have not shipped on their own site, I find it annoying, yet I'll still entertain the request as a possibility for the future # 16:50 AnnB melvster, for the record, I too know lots of people who've changed their name. For wide variety of reasons. # 16:50 melvster tantek: you cant have a social web without profiles, and when you have profiles, you need profile management, every social network since friendster and before has this property, i cant think of a single social system that does not # 16:51 tantek melvster - negative reasons never ships anything # 16:51 cwebber2 tantek: good point, that means we should implement it as an extension, and support extensions :) # 16:52 melvster tantek: not sure what you mean by that, I'm just going with web architecture, and "COOL URIs dont change", is that negative? Maybe, but a best practice, is all. The WWW has shipped quite well! Just look at facebook as an example ... # 16:52 AnnB tantek, I hugely appreciate the real-world proofs from indie web and others. But I do not get your demand that you demonstrate the only truths. # 16:52 aaronpk my "profile management" is updating my html file of my home page. i guess that counts as profile management still. # 16:53 tantek AnnB - it's necessary to filter out the infinite demands of the theoretical # 16:53 melvster aaronpk: that's a good way yes, imho, but perhaps requires a degree of web literacy above most normal users at this point in time # 16:53 tantek frankly, without *aggressively* cutting, you never ship # 16:53 tantek my profile management is editing the HTML of my index.html # 16:54 tantek melvster: editing HTML requires less web literacy than learning and making an API call with JSON # 16:54 melvster tantek: I agree, so I think profile management is useful # 16:54 AnnB all good goals .. nonetheless, my reaction is, "I have not written code. Therefore my opinion is for naught. Therefore why do battle with you." # 16:55 tantek cwebber2: here's my evidence, numerous micropub implementations, client and server, have shipped, and users have found great *social* utility in them, and NONE of them have "profile management" of any kind # 16:55 AnnB I realize someone like me -- non-coder -- has less position to argue and etc # 16:55 tantek ergo, profile management is unnecessary for at least some degree of success # 16:55 tantek saying "it is needed" is an assertion without evidence # 16:55 tantek and there is counter-evidence, that utility / usefulness is possible wihtout it # 16:55 aaronpk i don't think tantek is saying profile management is always a terrible idea and should never be built into the spec, it's just a matter of prioritizing # 16:56 tantek thus I think I would change my vote for that user story to a -1 - not needed for v1, based on experience with micropub implementation and adoption # 16:56 elf-pavlik aaronpk so you don't want to have possibility of adding venue to scheduled event? # 16:56 AnnB it's more palatable to speak of priorities than 'my way or the highway' # 16:57 tantek AnnB - hence I said unnecessary for v1, ok to consider for a v2 # 16:57 aaronpk not sure why events have profiles all of a sudden # 16:57 elf-pavlik profile of person, similar as profile of event, or organization, or place etc. # 16:57 tantek aaronpk - no real world examples of events having profiles - I believe that is a made-up hypothetical # 16:57 AnnB I agree .. I'm saying I prefer that style rather than the previous RRSAgent joined the channel
Zakim joined the channel
# 16:58 Zakim ok, trackbot; I see T&S_SOCWG()1:00PM scheduled to start in 2 minutes # 16:59 Zakim saw 7625 (tel:+1.617.761.6200 sip:zakim@voip.w3.org) given for the conference code, elf-pavlik jasnell joined the channel
# 17:00 akuckartz AnnB++ for "I have not written code. Therefore my opinion is for naught. Therefore why do battle with you." AdamB joined the channel
# 17:01 Zakim sees on the phone: aaronpk, Ann, cwebber2, Arnaud, elf-pavlik (muted), rhiaro (muted), tantek (muted), jasnell, AdamB dret, harry and hhalpin joined the channel
# 17:03 Zakim the conference code is 7625 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), harry # 17:03 harry back from dealing with crypto - am going through some open issues # 17:04 Zakim elf-pavlik, listening for 11 seconds I heard sound from the following: aaronpk (25%), Arnaud (60%), ??P15 (30%) # 17:04 rhiaro ... Hearing none, minutes approved March 31st # 17:05 rhiaro ... Still missing minutes from f2f and March 10th # 17:05 rhiaro ... Saw a note from aaronpk about the bot failing to generate the minutes to get started # 17:05 rhiaro harry: I'll look at it, will do by end of call # 17:05 rhiaro harry: wil double check, need to reprocess everything # 17:05 harry we have all the IRC logs - don't nothing is missing # 17:05 rhiaro ... we have all the irc logs, just needs formatting # 17:05 harry don't worry there, but I'll try to format by end of the call. # 17:06 rhiaro ... 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 # 17:06 aaronpk not sure why my line was making noise, the desk phone was on mute here # 17:06 rhiaro ... Next week default is to go back to an hour # 17:06 rhiaro ... There is a f2f meeting, only 8 people reigstered as participants # 17:06 rhiaro ... Not many people have registered as regrets or remote, please take a moment to answer one way or another # 17:07 rhiaro ... 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? # 17:07 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. # 17:07 Arnaud PROPOSAL: Meet 2015-10-29…30 (ThF) at TPAC2015 # 17:07 harry Thursday and Friday is fine with me. Anyone have another WG conflicts? # 17:08 rhiaro APPROVED: Meet 2015-10-29…30 (ThF) at TPAC2015 # 17:08 rhiaro Arnaud: We'll set up a wiki page for registration again # 17:08 rhiaro ... Be aware that you have to register at TPAC itself # 17:09 rhiaro ... Anyone wnat to declare victory on anything? # 17:09 harry I would not iterate through them by name, that takes up a lot of time # 17:10 rhiaro ... Don't want to go through, just let us know if anyone has anything to close # 17:10 aaronpk rhiaro: did you hear back about the opensocial database yet? # 17:10 rhiaro jasnell: Don't have completed, do have progress # 17:10 rhiaro ... Hopefully we'll have basic test (?) to show off by next week # 17:10 harry ACTION-51: Rigo does not want to fund my travel despite there being a 5K travel budget from the EC for this WG. # 17:10 trackbot Notes added to ACTION-51 Discuss with rigo travel budget to see if more funding can be found for a paris event. # 17:11 rhiaro Arnaud: harry: could we have a repo set up for that? # 17:11 rhiaro harry: shouldn't be a big deal. elf-pavlik created a large number of documents, want to migrate everything? KevinMarks joined the channel
# 17:11 harry My question - migrate the somewhat excessive number of documents in elf's repo aren't standards track # 17:11 rhiaro ... Some of the documents aren't standards track # 17:11 harry Do we just restrict the repo to standards-track? # 17:12 rhiaro Arnaud: I don't think we should just make it an open dump for anyone with any document # 17:12 rhiaro 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 # 17:12 Zakim elf-pavlik, you wanted to discuss 1 repo or many repos # 17:13 rhiaro 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 # 17:13 rhiaro ... and it's not 'elf's repo' it's an organisation with multiple repos # 17:14 harry Repos that are standards-track or related to standards-track documents goes to W3C repo # 17:14 rhiaro harry: repos that are standards track or related to standards track documents go to w3c repo # 17:14 tantek or *required* for standards track documents - e.g. test suite is required # 17:14 rhiaro ... and everything else goes to social group of repos # 17:14 rhiaro ... the repos in the w3c group are structured so other wgs can see what's going on # 17:14 harry and everything else, goes to w3c-social group of repos set-up by Elf # 17:14 rhiaro Arnaud: Anyone else? reports on progress/completion? # 17:14 harry So, when experimental stuff goes Rec-track, we move to W3C repo # 17:15 rhiaro ... Otherwise, we have a bunch of raise issued later on agenda # 17:15 harry The main thing is also to make sure the rest of the WGs can distinguish between experimental and Rec-track stuff # 17:15 rhiaro ... elf-pavlik will talk about issue 16 to get started # 17:15 trackbot issue-16 -- better separate grammar/vocabulary and improved spec structure -- open # 17:16 rhiaro 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 # 17:16 rhiaro ... which is why we should discuss this before, because some other issues are very specific to vocabulary issues # 17:16 rhiaro ... we can delegate between IG and WG to reduce pressure # 17:16 rhiaro ... We don't have to answer some issues if we have clear extensibility mechanisms # 17:17 rhiaro ... issue-36, json-ld context helps allow people see the rdf view the_frey joined the channel
# 17:17 Zakim sees on the phone: aaronpk (muted), Ann, cwebber2, Arnaud, elf-pavlik (muted), rhiaro (muted), tantek, jasnell, AdamB, wilkie, ShaneHudson (muted), Harry (muted), ben_thatmustbeme # 17:17 Zakim ... (muted), Sandro, dret, Tsyesika (muted), bret (muted) # 17:17 rhiaro 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 # 17:17 rhiaro ... I think there's consensus that there should be some kind of base vocabulary # 17:17 rhiaro ... the issue is saying there should be better separation # 17:18 rhiaro ... 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 # 17:18 rhiaro ... that says 'this is what vocabularies can do' and to use our own vocabularies as just one way of using that extension model # 17:18 rhiaro ... 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 # 17:18 rhiaro ... the big question is 'how do we define vocabularies'? # 17:19 rhiaro ... 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 # 17:19 rhiaro ... we will force ourselves to answer that question if we have a separation between activitystreams core and vocabularies used in core to serialize concepts # 17:19 rhiaro jasnell: going back to the original restructuring that happened; it was decided before we published the 1pwd, to simplify the document # 17:20 rhiaro ... we don't have the extended vocabulary stuff there yet # 17:20 rhiaro ... it would simplify it if it was split into two where the vocab was in one and the syntax was in another # 17:20 rhiaro ... the extended vocabulary was added because it was felt that we needed the base schema # 17:20 rhiaro ... in AS1 we had a base schema that defined all the verbs and object types that were used commonly with 1.0 # 17:20 rhiaro ... It was felt that we needed to have those concepts brought into the vocabulary for interop purposes # 17:20 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 # 17:20 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. # 17:21 rhiaro ... 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 # 17:21 rhiaro ... It makes sense ot have a definition in the core vocab of those commonly used things # 17:21 rhiaro ... What has not happened is a reconciliation of the objects in there from 1.0 base schema, and use cases # 17:21 rhiaro ... have not been reconciled with critical user stories # 17:21 tantek melvster - what sites use SIOC on the public web? URLs? Permalinks? # 17:21 rhiaro ... So I imagine that there are some set of activity types and object types that we can remove # 17:21 elf-pavlik q+ how people define new domain specific terms and how they discover existing one already defined by others? # 17:21 Zakim elf-pavlik, you typed too many words without commas; I suspect you forgot to start with 'to ...' # 17:22 elf-pavlik q+ re how people define new domain specific terms and how they discover existing one already defined by others? # 17:22 rhiaro ... And a couple of the issues I've opened suggest removing some of those # 17:22 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. # 17:22 rhiaro ... What we really need are proposals ot remove specific ones # 17:22 rhiaro ... I have no problem removing items, just need to know which and make sure there's consensus # 17:22 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 # 17:22 rhiaro ... We've talked about this a number of times, but haven't been any concrete proposals for changes to make to document # 17:22 harry Agreed concrete set of chagnes would be good # 17:22 Zakim elf-pavlik, you wanted to discuss how people define new domain specific terms and how they discover existing one already defined by others? # 17:22 rhiaro ... instead of having a high level discussion, be great to propose changes # 17:23 rhiaro 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 # 17:23 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. # 17:23 rhiaro ... If you want to use your own, you're on your own # 17:23 rhiaro ... It would be better to have a clear pattern to define domain-specific vocabularies # 17:23 rhiaro ... And also a way to discover what other people have defined # 17:24 tantek is not optimistic about extensions or domain specific vocabs # 17:24 rhiaro ... There is also a schema.org extension mechanism # 17:24 rhiaro ... I think we need more guideance about how to extend with domian specific terms # 17:25 rhiaro 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 # 17:25 elf-pavlik melvster John Breslin (SIOC) wants to coordinate work with us # 17:25 tantek melvster: was looking for specific URLs I could view source on - should I just go down that list? # 17:25 rhiaro ... 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 # 17:25 tantek melvster: wikipedia "social web" or "social network" documentation is horribly out of date # 17:25 rhiaro ... We should separate issues about how to define base schema # 17:26 rhiaro harry: From w3c perspective we would prefer a cleanly defined base schema # 17:26 rhiaro ... And the IG had control over extension mechanisms # 17:26 tantek melvster: I have had some good online back/forth with John Breslin - perhaps we can invite him as an invited expert? # 17:26 rhiaro ... But I do agree the WG can define extension mechaism # 17:26 rhiaro ... 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 # 17:26 AnnB can he come to F2F in Paris? # 17:27 rhiaro ... There's probably not massive overlap with schema.org (?) # 17:27 rhiaro jasnell: there is a fairly basic extensibility model already defined # 17:27 tantek how can you NOT overlap with schema.org? it has nearly the whole world in it ;) # 17:27 rhiaro ... we need to go through the AS document itself and define the extensibility model from applications using it # 17:27 rhiaro ... but if w3c wants to write a note saying this is how we define extended vocab for specific domains # 17:28 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. # 17:28 rhiaro ... I don't think we sohuld put that in AS doc itself # 17:28 rhiaro ... Happy to put things in external vocab, and let IG do it # 17:28 rhiaro ... we need to figure out how to close issue-16 # 17:28 tantek I'd like to encourage jasnell to drop non-core terms in his opinion # 17:28 rhiaro ... A notion of core vocabulary and what falls into it is a separate issue # 17:29 rhiaro ... Question is whether spec provides for extension mechanism that is well defined to allow people to define vocabs elsewhere or not # 17:29 rhiaro ... james says we should wait to see what that would mean # 17:29 dret from my perspective to close ISSUE-16 is to cleanly separate, on a document level, the core spec, and the base schema. # 17:29 tantek q+ to note that dropping terms is important too # 17:29 cwebber2 I'm not sure, doesn't json-ld already provide the extension framework? # 17:29 cwebber2 I'm confused as to what other extension framework is needed? # 17:29 rhiaro dret: yes that's right. From my pov I have a hard time imagining how we can define AS without defining extension model # 17:29 wilkie yes, AS would be rather perfect if it were a base core + extension/extensible-discovery mechanism # 17:29 rhiaro ... It's not something we can do later and say by the way this is how you extend it # 17:30 sandro +1 dret: I have a hard time seeing how we can define AS without an extension model # 17:30 rhiaro ... Implementations need to be aware of the extension model so they know how to deal with data that uses it # 17:30 elf-pavlik q+ re WG focuses on how to extend and IG focuses on vocabulary details # 17:30 Zakim sees tantek, elf-pavlik on the speaker queue # 17:30 rhiaro ... I cannot imagine how you would do it without # 17:30 akuckartz A good extension model/architecture/framework is more important than a large core. # 17:30 tantek q+ to also note that being forward-compat only requires a "must ignore" rule # 17:30 Zakim sees tantek, elf-pavlik on the speaker queue # 17:30 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 # 17:30 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 # 17:30 rhiaro tantek: two pieces of issue. one is what can we drop from core? # 17:30 rhiaro ... Heard james call for concrete prposoals of things to drop # 17:31 rhiaro ... I want to encourage james as editor to go ahead and start dropping some terms that in his opinion are not core # 17:31 rhiaro ... And wait to see who objects, and if they have implementations using those terms # 17:31 rhiaro ... Otherwise, we can trust him to drop terms and shrink the spec # 17:31 jasnell I have no problem dropping terms and handling those off to the IG to work on if they want # 17:31 rhiaro ... I want james to optimistically drop terms and wait for reaction rather than wait for consensus on every drop # 17:32 rhiaro ... 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 # 17:32 rhiaro ... Typically includes some form of must-ignore # 17:32 rhiaro ... That is, if an AS process encounters something not in spec, it must ignore it # 17:32 rhiaro ... That gives us ability to include ability to define extension mechanism either in first version, or later # 17:32 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. # 17:33 rhiaro ... As to whether v1 needs a well defined extension model, I'm on the fence # 17:33 rhiaro ... I don't think it actually needs it, but then again I'm not opposed if people come up with one # 17:33 Zakim sees elf-pavlik, cwebber on the speaker queue # 17:33 rhiaro ... It would provide an opportunity for people to experiment with their own activities # 17:33 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. # 17:33 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). # 17:33 rhiaro ... and that kind of live experimentaiton with implementations would be useful # 17:33 jasnell RSS and Atom used must-ignore without defining a more complete extension model without much difficulty # 17:33 rhiaro Arnaud: Thanks. I'd like to separate the two issues # 17:33 rhiaro ... What's in core is different to whether we have extension mechanism # 17:34 Zakim elf-pavlik, you wanted to discuss WG focuses on how to extend and IG focuses on vocabulary details # 17:34 rhiaro ... Tantek says the minimum is say implmeenations must ignore # 17:34 rhiaro 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 # 17:34 tantek jasnell - then you're done with the minimum :) # 17:34 rhiaro ... So unless we have clear way to extend, people might want to push things into core # 17:34 dret concretely: if our AS broker drops everything i does not recognize, is it allowed to do that? # 17:35 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) # 17:35 tantek melvster, that sounds like you're saying we actually don't need to provide an explicit extensibility mechanism ourselves # 17:35 rhiaro 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? # 17:35 Zakim sees elf-pavlik, jasnell on the speaker queue # 17:35 Zakim elf-pavlik, you wanted to discuss cwebber2 q # 17:36 dret or did that change? sorry if it did... # 17:36 tantek JSON itself has a custom / history of people adding new terms as needed (extending) anybody else's JSON structure # 17:36 Zakim sees jasnell, hhalpin on the speaker queue # 17:36 rhiaro 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 # 17:36 cwebber2 could we say "optional, unless you add extensions"? :) # 17:36 rhiaro ... problem is that if we don't require json-ld processing, then we cannot recommend directly json-ld as extension # 17:37 dret cwebber2, optional unless it's not? that's a weird interpretation of optional. # 17:37 rhiaro 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 # 17:37 wilkie people are *going* to extend it. ostatus was extended immediately, even by identi.ca, to add things not in the spec proper # 17:37 rhiaro ... which is consisten with what our existing document does # 17:37 rhiaro ... if an implementation feels that additional bits of information are important, it will do the work necessarily to support those # 17:37 dret but can intermediaries do that? drop unsupported things because they parse/reserialize? # 17:37 rhiaro ... either by adding an extended version of its own context, or doing some preprocessing # 17:38 rhiaro ... it still fits within the existing definition in the spec that says ignore anything you do not understand # 17:38 tantek wilkie, agreed. I think the difference is that perhaps we're ok with unofficial / undefined forms of extension # 17:38 rhiaro ... if someone comes up with a new activity type, our exisitng model allows that with no problem # 17:38 dret we need clear rules for intermediaries. # 17:38 rhiaro ... 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 bengo and jasnell joined the channel
# 17:38 rhiaro ... We agreed weeks ago that rdf reasoning is not required # 17:38 rhiaro ... You don't need to know that a Like is a kind of Response # 17:39 melvster FYI: @context is optional in JSON LD, it is just a short hand or those that dont wish to type out full URIs # 17:39 rhiaro ... If someone wants to come up with a new kind of response, they can do high level reasoning if they want, or ignore it # 17:39 dret tantek, it's something that consumes AS and republishes it to other consumers. same as in RSS/Atom scenarios. # 17:39 wilkie it would be nice, then, to have at least a recommendation to help identify extensions that are useful # 17:39 rhiaro ... Extensibility in there now is the same as in AS1.0, and in Atom and RSS - very successful # 17:39 cwebber2 this is why I think we should have a good core, then most people don't need extensions # 17:39 rhiaro ... If you find something you don't support, ignore it # 17:39 dret problem is RDF-based implementation that may drop things in the middle. can they? # 17:39 rhiaro ... If you think you have to understand, write your implementation to handle it # 17:39 rhiaro Arnaud: So we could close issue-16 without doing anything? # 17:40 tantek we don't need need any more of a defined extensibility model # 17:40 rhiaro jasnell: IMO we don't need anything else unless we get into reasoning jasnell_ joined the channel
# 17:40 rhiaro ... If the IG wants to say here's how we do higher level reasoning, the we can have anote # 17:40 AnnB the IG will need some additional folks, with diff skills ... # 17:40 rhiaro ... as far as the base is concerned, nothing more # 17:40 rhiaro 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? # 17:41 rhiaro dret: one scenario is that we have activites that are published, consumed, republished, aggregated, filtered # 17:41 rhiaro ... a whole ecosystem of activities, not just end ot end # 17:41 elf-pavlik q+ re why we don't use our extension mechanism for AS Extended Vocabulary? # 17:42 harry maybe you should write that down and email the list # 17:42 tantek does AS2 spec says what intermediaries must or should implement? # 17:42 rhiaro ... 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? # 17:42 rhiaro ... Or maybe if you don't understand stuff, you need to make sure you don't drop them if you need to republish # 17:42 Zakim elf-pavlik, you wanted to discuss why we don't use our extension mechanism for AS Extended Vocabulary? # 17:42 jasnell_ yes, extensions can be dropped. just like we have in RSS and Atom # 17:42 tantek I will note that there are no user-stories about intermediaries # 17:42 rhiaro elf-pavlik: if we concede our current mechanism useful, I prose we publish our extended vocabulary ..?.. # 17:42 tantek q+ to propose intermediaries out of scope for this version # 17:43 Zakim tantek, you wanted to propose intermediaries out of scope for this version # 17:43 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 # 17:43 harry I recommend we take this to the mailing list... # 17:43 elf-pavlik PROPOSAL: use our extension mechanism for AS Extended Vocabulary # 17:43 rhiaro 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 # 17:43 harry I have no idea what that proposal means elf. # 17:43 rhiaro ... reassess including in next version of spec # 17:43 harry An extension mechanism is different than a vocabulary # 17:44 jasnell_ Proposal: Close Issue-16, we already deal with extensibility in the spec # 17:44 rhiaro ... burden on you dret, to propose what you want to see in spec # 17:44 tantek PROPOSAL: explicitly declare intermediaries out of scope for this version of the spec # 17:45 rhiaro 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 # 17:45 rhiaro ... And have base schema as test case for ourselves # 17:45 jasnell_ An implementation guide that deals with extensibility would be great for the IG to produce # 17:45 rhiaro ... I have written that often on mailing list # 17:45 rhiaro ... 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 # 17:45 AdamB could the intermediaries come in to play during federation conversation # 17:46 dret the problem also is: how do i define i vocabulary? how will this work in an implementation? # 17:46 rhiaro harry: I can imagine there are many different subsets of question 'what is processing model' # 17:46 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 :) # 17:46 rhiaro Arnaud: proposal from tantek declaring it out of scope for this version # 17:46 harry I'm not comfortable with it being out of scope quite yet # 17:46 jasnell_ I don't think we need to declare them out of scope explicitly # 17:46 wilkie an extension mechanism could be an extension that somebody just does haha # 17:46 cwebber2 I also think if we cut down the vocabulary as much as possible and leave no room for extending the vocabulary simultaneously # 17:47 rhiaro ... I want to give erik a chance. Do you want to kee pissue 16 open? # 17:47 rhiaro ... You're always free to come up with a proposal anyway # 17:47 harry I think the 'dropping stuff' issue is interesting # 17:47 rhiaro ... Most people say we should just close it as is # 17:47 harry and could have ramifications down the road # 17:47 rhiaro dret: if that's what the majority wants to do, sure # 17:47 tantek cwebber2: it's a way to get dependable interop - not fraught! # 17:47 rhiaro ... from my pov it's not good implementaiton guidence # 17:47 Arnaud PROPOSED: Close Issue-16, doing nothing - we already deal with extensibility in the spec # 17:47 elf-pavlik -1 unless we use current model for publishing extended vocabulary itself # 17:48 harry +0 (would prefer to see dret write a concrete change, but am against pointless discussion until we have a change-set) # 17:48 wilkie I'm a little confused as well. haha. is this about extensible vocabulary or extensible actions?? # 17:48 rhiaro AnnB: I don't follow very well. Seems like vocal people against not vocal people # 17:48 ShaneHudson +0 I also don't follow it too well but sounds like a good proposal. # 17:48 rhiaro ... Somebody said it seemed premature to close it # 17:48 bret +1 close the issue, reopen with concrete changes # 17:48 rhiaro Arnaud: we have objections, we're not going to close it # 17:48 rhiaro ... People who object have concrete proposals about how to change the spec the_frey joined the channel
# 17:48 cwebber2 I will agree that this conversation is probably not very helpful # 17:49 rhiaro ... Say 'this is the text i want to add to spec' # 17:49 cwebber2 and I guess since I thought it was implied that you use json-ld for extensions as it is anyway # 17:49 rhiaro jasnell: whatever change in this area, that should also try to detail why the existing text does not work akuckartz_ joined the channel
# 17:49 Tsyesika cwebber2: but dind't people say JSON-LD shouldn't be required (even for extensability????) # 17:49 harry Yep, but I think dret had that use-case - i.e. what if stuff gets dropped? # 17:49 rhiaro ... Put a use case on the table and describe why the existing spec fails, and why the new proposed text passes # 17:49 cwebber2 Tsyesika: I didn't realize it was said "dont' use it *even for* extensibility" # 17:49 rhiaro ... At this point, I'm failing to see why the must ignore rule doesn't work # 17:50 cwebber2 "you don't need it probably because the core context will be good enough" # 17:50 dret use case: how am i expected to define extended vocabularies in a way that makes implementation behavior predictable. that's my only concern. # 17:50 harry The use-case is: Ship AS2 to node, process, [MAYBE drop optional stuff], ship back out. # 17:50 Tsyesika cwebber2: i'm not sure i do either given what has been said # 17:50 Zakim On the phone I see aaronpk (muted), Ann, cwebber2, Arnaud, elf-pavlik (muted), rhiaro (muted), tantek, jasnell, AdamB, wilkie, Harry, ben_thatmustbeme (muted), Sandro, dret, # 17:50 Zakim ... Tsyesika (muted), bret (muted), ShaneHudson (muted), bret.a # 17:50 tantek I'm ok with opening issues that James raised without analyzing them in detail. # 17:50 rhiaro ... By opening raised issues, we accept burden of having to close them for CR # 17:51 wilkie I don't mind dropping explicit conversation about extensibility as long as extensibility is intuitively obvious and possible # 17:51 tantek (even if I don't agree with some of them on first glance) # 17:51 elf-pavlik -1 since issues can start popping up like mushrooms after rain # 17:51 rhiaro ... Instead of going through one by one, lets open them all # 17:51 tantek elf-pavlik: come now, you've raised more issues than anyone else ;) # 17:51 KevinMarks nice thing about html classes and json keys is that they are intrinsically extensible by adding new ones # 17:52 rhiaro elf-pavlik: concerned about too many issues... maybe worrying too much ahead # 17:52 jasnell_ are you going to capture the proposal so we can vote? # 17:52 rhiaro Arnaud: we're just discussing these raised issues # 17:52 rhiaro ... Closing them is a concern, but we can't ignore them # 17:53 tantek jasnell_: re: "ISSUE-4 - Explicit typing or support implicit typing - Already # 17:53 tantek addressed in current draft" - could you provide URL to place in the draft that addresses it? # 17:53 rhiaro ... The other option is go to them one at a time # 17:53 harry I recommend that these are all minor issues that the editor can dela with # 17:53 rhiaro ... If there is a specific one you don't want to open, you can say # 17:53 rhiaro ... Not taking any action is not a good option # 17:53 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 # 17:53 tantek I object to closing an issue with "draft addresses it" without a URL to the specific fragment that addresses it. # 17:54 tantek so that any such issues can at least be turned into an FAQ! # 17:54 rhiaro 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 # 17:54 rhiaro ... either use vcard or keep it out of base schema # 17:55 rhiaro 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 # 17:55 harry My feeling is issue 26-27 re profile means either vCard (the only normative standard in the space) or nothing. # 17:55 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) # 17:55 rhiaro ... if we open them, james can make a proposal, and we can decide whether to close # 17:55 rhiaro ... but people always seem to hesitate and we get stuck # 17:55 rhiaro ... we can not just have all the edits happen undocumented without WG input # 17:55 harry The rest of these are rather minor at best but if James wants to open them, go for it. # 17:56 rhiaro 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 # 17:56 rhiaro ... User stories have profiles, but spec doesn't # 17:56 harry It's a separate vocabulary that is well-specified already. # 17:56 tantek harry - what do you mean by normative spec? per normative reference policy? # 17:56 rhiaro ... user stories are voted on, we have to have some kind of profile support # 17:57 rhiaro ... 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 # 17:57 tantek harry - my understanding is that h-card is also referencable - per discussions at MIT during our f2f # 17:57 harry However, I'd prefer that profile stuff go to IG since people have different profile vocabularies they like for various idiosyncratic reasons # 17:57 jasnell_ The proposal is only to open the issues NOT to decide on any specific one # 17:57 rhiaro Arnaud: proposal is to open issues that have been raised, 26-36 # 17:58 tantek harry - right, it's actually a more useful subset # 17:58 jasnell_ by opening the issue we open the issues up for discussion # 17:58 ben_thatmustbeme I think people were not willing to vote so quickly until they reviewed them, thats why the slow voting # 17:58 aaronpk correct me if i'm wrong but opening them does not mean you're voting on accepting any sort of resolution on them right? # 17:58 harry but I don't want us to roll another vocabulary # 17:58 tantek harry, by adopting h-card, it's easy to directly map to vCard # 17:58 rhiaro Arnaud: communication doesn't seem to be working well here.. # 17:59 Arnaud PROPOSAL: Close the following issues: ISSUE-4, ISSUE-7, ISSUE-12, ISSUE-14, ISSUE-15, ISSUE-20 # 17:59 rhiaro ... James proposed to close some issues with explaination of why # 17:59 rhiaro ... This doesn't have to take very long if people look at the proposal before the meeting # 17:59 rhiaro ... You can object to one, name it and we can remove it from list and close the others bengo joined the channel
# 18:00 Arnaud PROPOSAL: Close the following issues: ISSUE-7, ISSUE-12, ISSUE-15, ISSUE-20 # 18:00 trackbot issue-12 -- Action Types Structure and Processing Model -- open # 18:01 jasnell_ for Issue-4, tantek: I'd need a concrete proposal on spec language changes # 18:01 tantek jasnell - agreed that's why there's an open action on it! but that keeps the issue open. # 18:01 tantek to *close* it with the "spec already handles it" claim - you need to provide a URL to that specific "handling" of it # 18:01 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 :-) # 18:02 rhiaro ... Remove issue 15 and close the rest. Better than none # 18:02 Arnaud RESOLVED: Close the following issues: ISSUE-7, ISSUE-12, ISSUE-20 bengo joined the channel
# 18:02 rhiaro ... Some require discussion, which could take place elsewhere # 18:02 rhiaro ... We can narrow down discussion to what is controversial # 18:02 Zakim elf-pavlik, listening for 11 seconds I heard sound from the following: Arnaud (64%), Harry (17%) # 18:02 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 # 18:03 rhiaro ... I bet if you drop of the call now you won't be able to call back # 18:03 rhiaro elf-pavlik: issue-10 about candidates. Would be useful to clarify if we can use Micropub wiki page as formal dependency # 18:05 bret sounds like a normative reference issue # 18:05 rhiaro ... 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 # 18:05 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. # 18:06 rhiaro ... Unless there's a specific reason this can't be done, I understand we can reference micropub or microformats specs # 18:06 rhiaro ... If there's the question of stability, please raise and editors of specs can improve # 18:06 Arnaud the reservation extends a bit from the hour but probably not 30mn # 18:06 jasnell_ tantek: would you want to create an official mapping of the AS2 vocabulary to microformats in a note or rec? # 18:06 rhiaro elf-pavlik: not about technical feasiblity, just formal. Would like harry to confirm we can safely reference # 18:07 tantek jasnell - I think that would be useful, figuring fixing the examples in AS2 is a good step towards that. # 18:07 tantek hence I was working on fixing the microformats examples in AS2 - hoping that helps the_frey joined the channel
# 18:08 rhiaro 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 # 18:08 rhiaro ... We're expected to produce a w3c rec on this, not just reference something else # 18:08 tantek we could produce a spec that incorporated the necessary parts of micropub and microformats to make a Social API # 18:08 rhiaro elf-pavlik: so we can't just spec that has two lines and links to wiki page of micropub # 18:08 rhiaro ... would appreciate if the working group focused on technical quesitons and stopped wasting time on process questoins # 18:09 rhiaro ... Real question is what are technical differences between micropub and LDP and activitystreams # 18:09 rhiaro tantek: that was a strawman, no-one proposed that # 18:09 harry From a formal perspective, we need a spec that has the text written out # 18:09 rhiaro ... 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 # 18:09 ben_thatmustbeme Didn't we bring this up at F2F, micropub would have to be moved to standardized if it becomes part of socialAPI # 18:10 rhiaro harry: it is fine formally to take an API from somewhere else and use it as a base for new work # 18:10 rhiaro ... The question is not can we do this with micropub, but does the group have consensus on the approach # 18:10 rhiaro ... if wendy said yes and tim said yes, answer is yes # 18:10 rhiaro Arnaud: we need to focus on technical aspects # 18:11 harry *if* the IPR is fine, we can put it in as a candidate # 18:11 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. # 18:11 harry ACTION: hhalpin to discuss with wseltzer to make sure this is fine # 18:11 trackbot Created ACTION-59 - Discuss with wseltzer to make sure this is fine [on Harry Halpin - due 2015-04-14]. # 18:11 rhiaro 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 # 18:11 rhiaro ... that we can use to inform the rest of this discussion # 18:12 harry I think some sort of base that we modify is usuall a pretty good method :) # 18:12 tantek I'm just hoping to avoid duplicating spec text # 18:12 rhiaro jasnell: Can we get this as a proposal and assign an action? # 18:12 rhiaro ... 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 # 18:12 jasnell_ then can we table the conversation until those drafts are actually available # 18:13 rhiaro ... That call for proposal drafts was made at f2f # 18:13 AnnB Tantek: check the minutes from F2F ... AnnB adds: we NEED those minutes! # 18:13 AnnB they are still messed up # 18:13 rhiaro ... That's open right now, we just need people to bring drafts forward # 18:13 AnnB Harry -- can you pleaaaase figure out those minutes? # 18:14 rhiaro ... I've forked osheherd's ActivityPump spec and I'm going to use that as a base and look at all the user stories # 18:14 ben_thatmustbeme AnnB, I believe he said he would look at what is going on with those at the beginning of the call # 18:14 rhiaro ... And try to pull together the people in the WG and come up with a draft that we can propose # 18:14 AnnB oh, good .. thanks. I didn't hear that # 18:15 rhiaro ... 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 # 18:15 harry yep, we'll mov everything to github and folks should get invites # 18:15 Zakim On the phone I see aaronpk (muted), Ann, cwebber2, Arnaud, elf-pavlik (muted), rhiaro (muted), tantek, jasnell, AdamB, wilkie, Harry, ben_thatmustbeme (muted), Sandro, dret, # 18:15 Zakim ... Tsyesika, bret (muted), ShaneHudson (muted), bret.a, elf-pavlik.a # 18:15 harry However, until we get agreement on API, let's keep it in elf's repo # 18:15 harry And we'll just have a blank space in the W3C repo # 18:16 rhiaro cwebber2: There are couple of issues we already know we need to go through # 18:16 rhiaro ... probably this is for a future call: now that we're not addressing auth in the WG # 18:16 harry Note authentication working group is likely to start in fall if people are interested in that topic # 18:16 rhiaro ... There are issues there for peopel interested # 18:17 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? # 18:17 rhiaro Arnaud: elf has been trying to get us to be more organised # 18:17 rhiaro ... We already had intiially discussed chairs to produce agenda by friday before the call # 18:17 AnnB not hearing any beeps cwebber2 # 18:17 AnnB might drive you nuts though! # 18:18 rhiaro ... elf suggests we develop agenda a week before # 18:18 tantek I don't understand - we already develop the agenda in advance # 18:18 rhiaro ... i saw an email from evan objecting to trying to freeze agenda early # 18:18 rhiaro ... I do agree with elf there is value in people looking at agenda and prepare for call # 18:18 rhiaro ... If people can look through things like proposals before hand we can be much more effective # 18:19 rhiaro ... There always are proposals you can't plan ahead of time, but there are some things people can have an answer ready for # 18:19 tantek what's the actual problem? if people always add to the end it's unlikely we'll have problems # 18:19 rhiaro 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 # 18:20 tantek we don't need more structure for this to work # 18:20 rhiaro ... Not super strictly freeze it, but enough to give people time to prepare # 18:20 wilkie we need to discuss these issues on the mailing list during the week # 18:20 cwebber2 at least normatively, I think it's a good idea elf-pavlik # 18:20 rhiaro ... We can at least try our best to close on friday to give people time to prepare # 18:20 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 # 18:21 rhiaro 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 # 18:21 cwebber2 I feel like there's plenty of process in this group :) # 18:21 rhiaro ... If you read through the agenda by Friday you're probably goign to be ready for it # 18:21 cwebber2 maybe make it into a normative suggestion rather than a workflow # 18:23 rhiaro tantek: If you put something on the agenda, please add your name on wiki # 18:23 Zakim On the phone I see aaronpk (muted), Ann, cwebber2, Arnaud, elf-pavlik, rhiaro (muted), tantek, jasnell, AdamB, wilkie, Harry, ben_thatmustbeme (muted), Sandro, dret, Tsyesika # 18:23 Zakim ... (muted), bret (muted), bret.a (muted), elf-pavlik.a, ShaneHudson (muted) # 18:24 rhiaro ... In IG we have effort to clarify user stories that have minor objections, on github # 18:24 rhiaro ... Everyone adopts one or two and asks people who objected to discuss further # 18:24 rhiaro ... I invite everyone to participate, especially people who objected # 18:24 rhiaro ... Also, Vocabulary TF works on extracting vocab requirements from user stories # 18:24 rhiaro ... There's a wiki page we tried to map all terms used in user stories # 18:25 rhiaro ... But especially with use cases, please work with people in IG if you had objections to clarify # 18:26 Arnaud PROPOSED: extend weekly calls by 1/2h moving forward # 18:26 tantek -1 for extending next week (I'm chairing :P ) # 18:26 ShaneHudson +0 I've not been too useful anyway, but it is now half 7pm so 1 hour was a bit nicer. # 18:26 rhiaro AnnB: we need people to sign up to f2f in paris # 18:26 rhiaro harry: we had more people say yes on the poll # 18:26 rhiaro ... it would be nice ot have some kind of quorum # 18:27 wilkie rhiaro: one of the most disappointing things for a grad student to miss # 18:27 ben_thatmustbeme 0, i hope it was just needed this week, I likely can't stay the full 90 minuts most weeks # 18:27 Tsyesika i prefer not having an hour and a half meeting as it's evening in europe # 18:27 rhiaro tantek: now we've done 1.5, see if we're okay at 1 hour again # 18:27 AdamB what about alternating between 1 hr and 1.5 hrs # 18:28 rhiaro tantek: I promise to move things along as quickly as possible next week # 18:28 rhiaro has booked transport and found a place to stay! # 18:28 rhiaro ... Still worthwile even if there are only 8 people # 18:29 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. # 18:29 rhiaro AnnB: harry you said there are other people in Europe interested, can we arrange for them to be there # 18:29 dret thanks everybody, especially the chair and the scribe! # 18:29 jasnell_ I will join remotely as much as possible, even tho the time difference will be painful # 18:29 AdamB i plan to attend remotely # 18:32 Arnaud hey, guys, there is a section for remote participants, regrets are for those who don't plan to participate even remotely bengo and KevinMarks_ joined the channel
# 18:38 ben_thatmustbeme Arnaud: I put myself in regrets as I don't expect to be able to participate, but *might* be able to # 18:44 harry I think the answer re microformats is it depends on the stability # 18:44 harry I think TimBL is thinking mostly re vocabularies # 18:44 tantek harry - right - hence a need for more explicit stability markers - which is fine # 18:44 bret the vocab of micropub is based on mf2, so stable? # 18:44 harry Re micropub, the question is 1) do you want to reference it? # 18:45 tantek especially in specs which include stable, in progress, and proposed stuff # 18:45 harry or 2) do you want it as the base of the Social API? # 18:45 harry I think for 1) we're fine as long as the vocabularies are stable. # 18:45 tantek and it has the same licenses / stability as microformats specs # 18:45 harry TimBL thought some stuff was unstable in some microformats spec # 18:45 tantek I think we can use some iteration on the stability documentation # 18:45 harry but he was happy as long as its marked clearly what is stable and what isn't. # 18:46 tantek there are both stable portions of vocabulary, and in-progress / proposed portions # 18:46 harry I think the answer is "in general, it's not as strong, but broadly compatible" # 18:46 tantek that sounds similar to what I believe Moz lawyers said to me too # 18:47 tantek harry, however, my understanding from lawyers is also that OWFa *is* stronger than IETF's fairly vague patent non-asserts. bengo joined the channel
# 18:47 tantek so as much as W3C is happy to normatively reference IETF, there should be no problems referencing OWFa # 18:47 harry and we get a non-member licesning agreement from whoever is not a W3C member and not member of the WG # 18:48 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 ) # 18:48 tantek nice thing is that it's all in the wiki history # 18:50 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 # 18:51 tantek in fact I'll add that to the spec right now as a contribution requirement # 18:51 harry yeah, we may have to do that, but that's a pre-CR thing bengo joined the channel
# 18:56 ben_thatmustbeme regarding you email about static pages, I think thats fine, we did agree to prefer follow-your-nose over any known-url pattern stuff, if its follow your nose, it basically allows for offloading of things to external services # 18:57 harry ok, will be up for discussion in a sec, gotta move so will be offline for a bit # 18:58 ben_thatmustbeme basic CUD (read should be able to be done from the site) is done in any way they want, they could use the social API or not (maybe external service rsyncs to the site) # 18:58 ben_thatmustbeme but we have found that useful as a lot of people host on things that don't allow them to set special headers, others host by github pages i believe so their updates are done by git bengo, KevinMarks and tilgovi joined the channel
bengo_, bengo, harry and hhalpin joined the channel
KevinMarks, harry and hhalpin joined the channel
Loqi Akuckart made 1 edit to [[Socialwg/2015-05-04]] https://www.w3.org/wiki/index.php?diff=83368&oldid=83352
AnnB elf-pavlik, you there?
melvster found it! http://rdfs.org/sioc/types#Playlist
elf-pavlik adding http://www.w3.org/TR/vcard-rdf/ to Social IG Vocabulary TF
RRSAgent logging to http://www.w3.org/2015/04/07-social-irc
ShaneHudson Zakim, ??P10 is me
ben_thatmustbeme Zakim, mute me
tantek on n.m. found https://www.w3.org/wiki/Socialwg/2015-03-31-minutes
aaronpk f2f meeting https://www.w3.org/wiki/Socialwg/2015-05-04
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.
rhiaro 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
KevinMarks nice thing about html classes and json keys is that they are intrinsically extensible by adding new ones
cwebber2 oshepherd's original spec: http://oshepherd.github.io/activitypump/ActivityPump.html