How do badges get in to the directory?

[stenington]

We're starting to think about some of the details of how badge classes make their way in to the directory. I think in the early planning stages I did some hand waving and said something highly specific like "through various means and ways".

[stenington]

There are also sort of 2 parts to this questions: How do they get in now, and how do they get in later?

It looks in the short-term like the initial dataset we'll want in there is going to be defined in Badgekit, so we can use the badgekit api to pull the data in. However, as a general mechanism I think that might be the wrong way around. I'm not sure if the directory should be responsible for hitting apis to ask about badges, or if those sites should be hitting a directory url to tell it about badges.

[threeqube]

It looks in the short-term like the initial dataset we'll want in there is going to be defined in Badgekit, so we can use the badgekit api to pull the data in.

yeah makes sense.

However, as a general mechanism I think that might be the wrong way around. I'm not sure if the directory should be responsible for hitting apis to ask about badges, or if those sites should be hitting a directory url to tell it about badges.

Yeah..I think you're right.

[jpcamara]

Hmmm, I think there was some miscommunication in our earlier stand discussion.

It looks in the short-term like the initial dataset we'll want in there is going to be defined in Badgekit, so we can use the badgekit api to pull the data in.

In the stand, I was just brainstorming possibilities for getting the badges defined for pathways into the directory. The badgekit api came up as a less than optimal solution to get by, if the situation should occur that badgekit can't facilitate what we'd want to do for directory (ie, a badge class endpoint that issuers could expose to identify which badges they want to get indexed).

As part of the exploratory part for directory, @kayaelle and I have discussed aggregating the goodness from the openbadges-discussion issue on issuer badge listing/index (1EdTech/openbadges-discussion#1) into an issue or a few here, and using that to drive some/all of the discussion and work. We feel that for the initial work we do, exposing a json listing of badge classes makes the most sense (something in the vein of this perhaps 1EdTech/openbadges-discussion#1 (comment)). Still working through it, but my initial proposal in the meeting was to fork badgekit, and give them a pull request that exposes that type of endpoint so the directory could use it to a) get the ~200 pathway badges created there and b) have an app to test against.

If they weren't willing to accept something like that, we could get by using their API. However, we definitely don't want to write any code in directory itself to utilize BadgeKit's API since it's only useful for them specifically and no one else. We would probably just use it to make a json dump in the format of the json endpoint directory needs and consume that instead (not too dissimilar to how directory is currently consuming a json dump). Or as @stenington mentioned in the standup, just ask them to dump it for us and we could format it.

However, as a general mechanism I think that might be the wrong way around. I'm not sure if the directory should be responsible for hitting apis to ask about badges, or if those sites should be hitting a directory url to tell it about badges.

Agreed that specifically using their general API isn't the appropriate mechanism. But I don't think it's sustainable for the issuer to actively notify the directory about their badges. If the goal would be to get issuers up/running/and participating in the directory then the barrier to entry should be as low as possible. The thought we have is the issuers would need to somehow register with the directory, and they would have a standard endpoint for the directory to consume (mentioned earlier). From there it would be the directory's responsibility to keep itself up to date based on the data the issuer is exposing.

The endpoint is probably enough work on its own to get issuers involved, but a more active step of them having to consistently notify the directory incurs an additional burden, potentially across their whole application (rather than the more isolated passive capacity of an endpoint waiting for use). Totally anecdotally, but from my experience, the more you ask for the less people will be involved/the longer it will take to get them involved/and potentially the lower the quality of what people can offer will be once involved.

[stenington]

Oh okay, interesting. I was missing the "issuers somehow register with the directory" part of things. It makes sense to me that issuers could say "please ping us for our badge classes" and THEN the directory would periodically do that.

Cool, I think I agree with the general plan for continuing this work. 👍

[threeqube]

cc/ @cmcavoy for good measure.

[andrewhayward]

I was playing around with the idea of registration and pulling data in from providers at the end of last year, and quite happy to talk about thoughts that came up from that work. Essentially it piggy-backed on the robots.txt and sitemap standards to allow providers to specify which badges they have, and where they can be found, though I didn't get as far as actual crawling for information.

[jpcamara]

Taken a look through and this is pretty great! I'd love to hear your thoughts, and if you wanted to expound a bit on any of the finer details of what you're doing in there.

Nice that you have the xsd and jschema validation in there for the listing format - as part of the actual crawling @kayaelle and I have discussed actual badge class validation as well.

[iamjessklein]

Really enjoying reading through this conversation. One thing that I thought about, which is kind of discussed here in passing by @jpcamara is the idea of just having issuers provide that data. If we look at the Yelp model, it is actually quite interesting because it becomes a marketplace, (I wrote a bit about that here: http://jessicaklein.blogspot.com/2013/11/badge-directory-yelp-for-badges.html) there could be a way for a user to add badges and then for other users to validate or endorse that the badge actually exists. This would of course be made way more digestable with a GUI, but just throwing this out for context, not sure if it's helpful in this particular thread.

[kayaelle]

To keep this thread up-to-date - the first method we're using is asking issuers to register a url that lists their badge classes. The format is a JSON list which was the easiest for us to do initially but may not be the easiest for issuers.

It's only a first-step. We can also explore other list formats: rss, atom, etc... We'll also look at adding a basic form that anyone can use to register a badge. Jess brings up an interesting point about validating or endorsing badges that get into the directory.