Manu Sporny: During last call, we said w3c wants to move fairly quickly, that timeline has been moved up even closer. very aggressive timeline. w3c wants web payment ig to recommend groups by end of june of this year. need to get everything ready by that time frame, meaning charter, exec summary etc. ✪

Manu Sporny: Want new group created by sept of this year ✪

Manu Sporny: Right now talking to w3c mgmt, trying to get things quickly set up ✪

Manu Sporny: Lot of educating, staff contacts at w3c up to speed ✪

Manu Sporny: Timeline: by june mgmt of w3c want a recommendation to create a wg. need to get all messaging cohesive. usually get 6 months, but we need to do this in 2 months. very aggresive timeline. ✪

Manu Sporny: Need to have people on that list contacted by end of june. ✪

Manu Sporny: Once that happens, they need to get caught up to speed on technical work. ✪

Manu Sporny: By sept when we launch, we're all ready to go. ✪

Manu Sporny: Problem with launching a wg like this is that we don't want to spin up a wg only to stall. that's the risk with taking on such an aggressive timeline. ✪

Manu Sporny: When sept rolls around, people in the group should hit the ground running. ✪

Manu Sporny: We basically have a month before w3c meeting in sapporo japan in late october 2015 ✪

Manu Sporny: To review the timeline again, we need to get as many orgs up to speed by june - july timeframe. need them to get caught up by sept, we only have several telecon meetings before gathering in sapporo ✪

Manu Sporny: Questions? ✪

elf Pavlik: http://www.w3.org/2015/11/TPAC/ ✪

Mark Leuba: Hi Manu, It was my understanding that the Roadmap would morph, with portions moving into the Executive Overview, the diagram moving into Use Cases and remainder (mostly schedule/timeline, issues, etc.) remaining - a part of which will it seems be duplicated in a charter? Is that the plan? Thanks, Mark ✪

Brian Sletten: Can you tell us about what outreach work entails? ✪

Manu Sporny: Reaching out to those in the recruiting doc. ✪

Manu Sporny: Get them to understand everything that we're doing. bsletten you can definitely help out with that with current w3c members. effectively sending out an email and answering any questions they might have. ✪

Manu Sporny: Any other qs with w3c credential cg update? ✪

elf Pavlik: Where do we find info on steps for W3C members to support creation of Credentials WG ? ✪

Manu Sporny: It is vital we execute on this stuff as soon as possible. If we screw this up, we'll have to wait another year. w3c is putting a lot of pressure on us. ✪

Manu Sporny: Think we're gonna end up with actions to every single person this call. make sure they understand the work that we're trying to do. ✪

Manu Sporny: In response to elf-pavlik the steps are what i just outlined. this is being done in a very different way. trying to fast track it. They're fast tracking it faster than we asked them to. We need to accelerate our timeline by a couple months. ✪

Manu Sporny: https://www.w3.org/Payments/IG/wiki/Communications_Strategy_Task_Force/Doc_Relations#Draft_Charters ✪

Manu Sporny: Will know more after this week. Will be having discussion with w3c about nailing down a timeline. ✪

elf Pavlik: How do they do official +1 ? ✪

Manu Sporny: That link shows that our charter has already been integrated into the pitch ✪

Manu Sporny: The official way this is done is you do a call for interest, you have a workshop, you create an interest group, after the interest group works for a year, you go into working group. We're skipping 18 months. Everyone on the working group is reading off the same page. ✪

Manu Sporny: Next steps: everyone will be assigned orgs and we need to onboard those orgs ✪

Manu Sporny: We give them a link to exec summary, we ask them specifically for a statement that they want the group to be created. Then we work with them to bring them up to speed. show them exec summary, use cases and some demos. ✪

Manu Sporny: https://docs.google.com/document/d/1Nq543-Am1hQUIZ2hhzAFl8KexvIEBwDDc_f3Ikz1opQ/edit ✪

Manu Sporny: This is a first pass at a one-pager executive summary. ✪

Manu Sporny: Brief intro to what we mean by credentials, demonstrate that credentials are applicable to a variety of market places. outline group's goals, what we want to achieve. ✪

Manu Sporny: How are we going to drive this? what steps do they need to go through? ✪

Manu Sporny: We'll likely need to create a google doc form. we want to link them to the use cases so they can understand the type of problems we're trying to address. ✪

Manu Sporny: Mark tried to reconfigure roadmap doc into this format ✪

Manu Sporny: Any questions about exec summary or what we're doing there? ✪

Manu Sporny: Would anyone have any concern about circulating this? ✪

Brian Sletten: Will take a quick pass after the call but don't see any issue ✪

Manu Sporny: Keep in mind this one pager is first contact for many orgs ✪

Manu Sporny: Please comment on this and try to refine it ✪

elf Pavlik: Can we replace all [LINK TO..] with links to current drafts? ✪

Manu Sporny: Needs to be done by end of next week ✪

Manu Sporny: Elf-pavlik yes idea is that this will be off of credential wiki. we'll create new wiki pages like we did for credential cg. use cases we'll put in cg respec format. ✪

Manu Sporny: Use cases need to be in good shape by end of next week ✪

Manu Sporny: We should talk about use cases. ✪

Sunny Lee: Based on the conversation last week - we felt pretty good wrt. what we've captured so far. ✪

Sunny Lee: I took a look at it this morning, looking for additional comments - not sure if people have been able to make a pass at it. ✪

Nate Otto: Maybe instead of "earning" as a phase, something along the lines of "recipient management" ✪

Brian Sletten: I looked through it - looked at Web Payments Use Cases (micro use cases) - will look at it more this week. ✪

Sunny Lee: Who needs to coordinate on this? [scribe assist by Manu Sporny] ✪

Manu Sporny: Let's send out an email manu, bsletten, SunnyLee NateOtto kerri will be on the thread ✪

Manu Sporny: Because of the tight timeline we may step on each other's toes. ✪

Manu Sporny: Have an idea of what this doc looks like in the micro use cases model. ✪

Manu Sporny: If that model doensn't work, we can use what's there and shove it into an editor ✪

Manu Sporny: NateOtto says he can't join via voice ✪

Manu Sporny: Only on IRC ✪

Victoriano Giralt: Victoriano as well ✪

Manu Sporny: Let's see if NateOtto can contribute on IRC ✪

Nate Otto: Howdy ✪

Nate Otto: Sure, can do my best ✪

Nate Otto: At the Badge Alliance, we're getting ready to release the first Linked Data version of Open Badges ✪

Nate Otto: The Credentials vocabulary draft that was shown a couple weeks ago hasn't changed since then; haven't seen any comments or feedback besides elf's, which was very helpful ✪

elf Pavlik: https://github.com/openbadges/openbadges-specification/issues/32 ✪

Nate Otto: I proposed a badges context that referenced IRIs in the credentials vocabulary namespace, but was warned that it may be a long time before the credentials vocabulary is locked down ✪

Manu Sporny: Here's the vocabulary document for OpenBadges http://specification.openbadges.org/credentials/# ✪

Nate Otto: ... And so it would be better to use IRIs in a Badges vocabulary namespace ✪

Nate Otto: So the question came up: Open Badges wishes to release a version that uses a Linked Data context in the near future. Some of the classes and properties in the draft Credentials Vocabulary could serve as the IRIs for components of badges that could appear in this context. But the Credentials vocabulary has not been thoroughly reviewed, and it might not be approved by this group or a future Working Group to be published for ✪

Nate Otto: Some time. What would the consequences be of using IRIs within an Open Badges context for now that may later be superceded by terms in a published Credentials vocabulary. Is it hard to move from using one IRI for a term to another IRI? ✪

Nate Otto: Manu and dlongley said it is more important that the _meaning_ of a term stays constant than the IRI that is its anchor ✪

Nate Otto: So that's my #1 question this week, and I have 2 other minor ones ✪

Nate Otto: What is the community's feeling on the terms included in the current draft of the Credentials Vocabulary? (too much, too little, just right?) ✪

Nate Otto: And then consequences for the future: Should Open Badges and Credentials vocabularies look toward being merged in the future? If the community desires to move that direction, what legacy elements of badges would meet resistance? ✪

elf Pavlik: IMO we may need make Open Badges 2.0 using Web Credentials directly but 1.x may need some extra compatibility layer ✪

Dave Longley: First question: my opinoin about cred vocab should be aboslute bare min that enables interoperability ✪

Dave Longley: Right now definedachievement and definedachievementassertions, don't think we need to talk about badges in core credential vocab. ✪

Dave Longley: Don't think having it in this vocab is helpful. other than that, think everything else is fine ✪

elf Pavlik: +1 ✪

Dave Longley: Need to define id credential and its core property ✪

Dave Longley: Everything else that's domain specific whether badges or other kinds of credentiails should be pushed out to their own vocab ✪

Manu Sporny: Rephrase: fundamentally there should be cred vocab and open badges vocab ✪

Victoriano Giralt: +1 To "own vocab" ✪

Nate Otto: Thanks for feedback, dlongley , manu, Victoriano ✪

Manu Sporny: Openbadges should be specific to the open badges work. we want to do this because we don't want to slow down open badges work with all other stuff going on with web payments work ✪

Manu Sporny: Cred vocab should be super generic and minimal so that open badges work or healthcare credentials data can be built on top of it ✪

Manu Sporny: How best to achieve this from technical perpsecitve ✪

Nate Otto: I do feel that achieving some of the use cases in the use cases doc depends on having defined achievements of some sort in scope. I don't necessarily have strong feelings about where vocabularies are built ✪

Manu Sporny: Think we have answers to all these questions. ✪

Manu Sporny: Is it hard to move from using one IRI to another? as long as semantics don't change and you're using json-ld, not impossible but you really want to avoid doing this if you can ✪

Nate Otto: Cool, thanks, all. Interested in elf-pavlik's thoughts, as he has spent some time looking into the technical implementation ✪

Manu Sporny: You're relying on a json-ld trick from moving IRI to another ✪

Gregg Kellogg: It can be down with owl:equivalentClass/Property as well, but best avoided ✪

Manu Sporny: Rule of thumb, always use same IRI if we can do that, if we can't do that we need to sort it out ✪

Dave Longley: If you start generating badges and you designate badge with some IRI, if you change the IRI, the meaning will change and the signature will not work ✪

Dave Longley: Ideal situation is that all this stuff will converge and we will be using appropriate IRIs ✪

Nate Otto: Manu, it sounds like the badges vocabulary should be built with terms that make sense for badges, and those can serve as the canonical IRIs for those terms. ✪

Dave Longley: There will be some amount of pain if we put out a context with different set of IRIs and shift it over to something new ✪

Nate Otto: Perhaps a converged vocabulary in the future could continue using IRIs in a OBI namespace? ✪

Manu Sporny: Personally would rather put someting experimental in credential vocab and it effecitvely unchangeable, since open badges has been successful in using it. would much rather that happen and maybe stuck with term that's not fantastic, than us shiting and using a bunch of different IRIs ✪

Manu Sporny: Nate is saying there are some terms we want to use in open badges vocab from cred vocab. Saying we should put something in credential vocab, eg claim, put that it in credential vocab and have that stick around in open badges v1.1, v2, etc, than the Badge alliance create a different claim property and use that for the nextn couple years and when open badges v2 come out use the credential vocab property. ✪

Dave Longley: Recall NateOtto mentioned definedachievement. if we push all this out to topen badges, it makes things easier. Then there are minimal potential conflict. ✪

elf Pavlik: I see benefit with focusing on modeling domain using Linked Data best practices first ✪

elf Pavlik: So for example BA could model *Achievement* ✪

Manu Sporny: I think we're in general agreement ✪

elf Pavlik: And then use generic *Credential* as *AchievementCredential* ✪

Manu Sporny: Eg badge alliance could model achievement ✪

elf Pavlik: See also: https://lists.w3.org/Archives/Public/public-credentials/2015Mar/0007.html ✪

Manu Sporny: Do not agree with what elf-pavlik is saying, think it's backwards ✪

elf Pavlik: And https://gist.github.com/elf-pavlik/029917ccc535e889f693/abb0de12f0a31eac4e679a229fb0413d5c5ab20e ✪

Manu Sporny: Meaning credential is the base and a badge is a type of credential ✪

Manu Sporny: Nevermind, I didn't understand what elf-pavlik was saying. ✪

Dave Longley: Think he's saying modeling it the way you have in mind manu ✪

elf Pavlik: Manu please see https://github.com/openbadges/openbadges-specification/issues/32 ✪

elf Pavlik: BadgeAssertion == AchievementCredential ✪

Dave Longley: Think the way elf-pavlik has written it out on gist was the way we had thought about designing it ✪

elf Pavlik: While Badge == Achievement ✪

Dave Longley: We may have multiple types; credentials and achievement might be a way to model it. ✪

Victoriano Giralt: +1 Badge == Achievement BadgeAssertion == AchievementCredential ✪

Dave Longley: You define whatever properties you want and define it inside a claim. You can create an achievement and it can be a type of badge. ✪

Dave Longley: When you use json-ld framing you can merge it all together and use it in an application ✪

elf Pavlik: We should also always check how things look with Merged Credentials Example ✪

Manu Sporny: Need to catch up on the discussion and get caught up ✪

Dave Longley: Believe the way elf-pavlik has modeled it matches linked data best practies ✪

Manu Sporny: Question: is there a misalignment with what the Badge Alliance is doing with their badge stuff? ✪

Dave Longley: Think this can work for them but NateOtto can probably speak to this. ✪

elf Pavlik: Merged Credentials Example http://tinyurl.com/nu7lrvb ✪

Nate Otto: Elf-pavlik is pretty close to what the BA has been doing ✪

Kerri Lemoie: A bit out of the loop. Wouldn't mind having a followup call. ✪

elf Pavlik: NateOtto, let's have small group call later this week! ✪

Manu Sporny: Let's do that with elf-pavlik NateOtto kerri, manu dlongley ✪

elf Pavlik: +1 ✪

Nate Otto: Inside what would be his `achievement` property (line 18) https://gist.github.com/elf-pavlik/029917ccc535e889f693/abb0de12f0a31eac4e679a229fb0413d5c5ab20e#file-definedachievementassertion-jsonld-L18 , the BA would have a 'recipient' property with information about the recipient identifier that was targeted by the issuer ✪

Manu Sporny: The thing that's throwing us in the loop is that BA is tring to deploy now. ✪

Manu Sporny: Don't want to get in the way of that. ✪

Nate Otto: But if the recpient identifier is in fact the id of the claim, it would be duplicative ✪

Nate Otto: So this is pretty close to where we might want to get to with v2 ✪

Kerri Lemoie: Do we want to get it out and appreciate you accommodating BA's needs. ✪

Dave Longley: We don't want to hold up your work in anyway ✪

Dave Longley: This is getting into the technical details that the working group would be getting into ✪

Kerri Lemoie: No apologies needed. we really appreciate your work ✪

Manu Sporny: 2 Other questions NateOtto had. scrolling back up. ✪

Manu Sporny: What is community's feelings of the terms included in the draft? too much too little? ✪

Manu Sporny: Assuming NateOtto means open badges vocab rather than credential vocab. ✪

Nate Otto: I was talking about the credentials vocab draft ✪

Nate Otto: http://specification.openbadges.org/credentials/ ✪

Gregg Kellogg: Definitely shouldn’t have name, description, image, issueDate, etc. ✪

Nate Otto: Dlongley expressed a desire to pare it back to minimal set, dropping almost all properties besides `claim` ✪

Dave Longley: Really credential vocab will only have like claim in it or something closely approaching that. something like claim, owner, recipient. you don't need much else for internoperatbilty, evidence or tag don't go into cred vocab. all this stuff goes into open badges vocab but not cred vocab. ✪

Manu Sporny: Other thing is should open badges and cred vocabs merge in the future? ✪

Nate Otto: Gkellogg, do you know of a preferred IRI for the issueDate term? ✪

Manu Sporny: Believe current working thought is these are 2 different vocabs: cred is very minimal and only there to allow interoperabilty, open badges is much more specific to cater towards needs of the open badges community. ✪

Manu Sporny: Don't think they should be merged but they should certainly complement each other ✪

Dave Longley: What we want is that open badges badges are generic credentials ✪

Gregg Kellogg: NateOtto, I’ll need to look, but I think something related to a schema:Event, or from more specific vocabulary might povide the same semantic meaning. ✪

Nate Otto: Badges vocab/spec attempting to cater to needs of any community or group that makes use of defined achievements ✪

Dave Longley: Generic cred vocab tells you how to define a claim. and open badges spec layers on top of it and goes into deeper property details. ✪

Gregg Kellogg: Perhaps schema:startDate? ✪

Nate Otto: Gkellogg, please post to mailing list in the next week if you can find something that you like. We're going to make a decision, and right now that's a term that is looking like it's in the badges vocab draft ✪

elf Pavlik: Let's schedule after the call small vocab meeting later this week? awesome if gkellogg could join as well! ✪

Gregg Kellogg: Sure, also dc:dateAccepted. ✪

Manu Sporny: NateOtto is effetively saying that what elf-pavlik is proposing is what we want to do with version 2 ✪

Dave Longley: If we can sync up timeline of this working group with open badges version 2, then a lot of these problems can be resolved together. ✪

Nate Otto: Hmm, interesting re: dc:dateAccepted & schema:startDate -- I'll look at them, feel that neither really captures the issuance of a credential meaning. ✪

Manu Sporny: First off should be called open badges vocab not credential vocab. ✪

Gregg Kellogg: +1, In the context, but not in the RDFS vocabulary definition ✪

Nate Otto: I'm going to have to listen to audio of the call if possible to sort out this section. ;) sorry, I'm a bit lost. ✪

Manu Sporny: Looking at sournce. NateOtto did the right thing. schema.org/name, restating what schema.org states ✪

Mark Leuba: Great scribing Sunny, thanks! Hi Manu, It was my understanding that the Roadmap would morph, with portions moving into the Executive Overview, the diagram moving into Use Cases and remainder (mostly schedule/timeline, issues, etc.) remaining - a part of which will it seems be duplicated in a charter? Is that the plan? Thanks, Mark ✪

Gregg Kellogg: This doc appears to be all the terms defined in the credentiails vocab, so the fact that name is something contextual, gets lost. we need to keep separate, from modeling perspective. we want to describe the properties that make sense in this context ✪

Dave Longley: +1 To gkellogg ✪

Gregg Kellogg: Keep separation of terms and think about what is part of the formal vocab. ✪

Manu Sporny: 2 Things: 1 what's the formal vocab (minimal set of things that create interoperability), 2, documentaiton of the terms. we need to put out documents that talk about how badges or credentials are put together. open question is should we give examples in the vocab doc or should this be seprate ✪

Gregg Kellogg: In csv group, we have metadat terms but doesn't also try to be formal vocab definition but rather references vocab definitoin. alll the terms and the way it's used is in one doc but context and vocab doc just tries to do that. ✪

Mark Leuba: Where is the roadmap going? ✪

Manu Sporny: Mark believe this is the plan. roadmap doc will disappear. since content is being split up among charter, executive summary etc. ✪

Mark Leuba: Hi Manu, It was my understanding that the Roadmap would morph, with portions moving into the Executive Overview, the diagram moving into Use Cases and remainder (mostly schedule/timeline, issues, etc.) remaining - a part of which will it seems be duplicated in a charter? Is that the plan? Thanks, Mark ✪

Mark Leuba: Sorry I cannot connect. ✪

Manu Sporny: We need a roadmap to lay out a plan for the next 2 - 3 years. but wonder if that will end up reconstitute a lot of the content we already have. ✪

Mark Leuba: Not a good idea imo. ✪

Manu Sporny: Does anyone feel like the roadmap is a vital document? can we put it to the backburner? ✪

Mark Leuba: Yes ✪

Gregg Kellogg: Feels like it's useful for a transitory document. ultimately this will turn into some specification. ✪

Gregg Kellogg: Point of roadmap is to help resolve direction of where we're intending to go. this eventually gets translated into specification text. Helps to focus disucssion but with an eye towards obscoleting it. ✪

Manu Sporny: Let's wait to hear about Mark's argument on why we should keep roadmap doc. ✪

Manu Sporny: Bsletten roadmap docs are not often used in w3c, effectively the charter for the group. once you have the charter then you retire it. ✪

Mark Leuba: Manu ✪

Nate Otto: I appreciate Mark's work on pushing these documents forward. :) ✪

Manu Sporny: Roadmap helps people rally around the direction you're headed in. this is the direction we're headed in, these are the groups we're onboarding, this is what we need to do, etc. ✪

Mark Leuba: I don't think we should keep it, but reform it to meet Greg's vision. ✪

Dave Longley: In short, roadmap is very important for developing the charter ✪

Nate Otto: (I like the combo or exec summary + charter, sounds like gkellogg has a good idea for how things fit together.) ✪

Mark Leuba: Gotta go! ✪

Manu Sporny: Will ping us about use case stuff ✪