Questions relating to metadata

Showing 1-7 of 7 messages
Questions relating to metadata Greg Austic 4/21/12 6:34 AM
I had a few questions on met-data:

1) What badge metadata can currently be added to badges - ie how many fields?  Is there a limit to the amount of data per field?  How hard would it be to add additional fields in the future, and is there a plan to do so?  We're looking at tagging our badges so that we can group them around events (in a similar way that you can put your badges in your backpack in groups, except that the tag will be globally associated with the badge).  For example, you can see all of the badges you got from a single event, even if the badges creators were different (imagine you went to the a Maker Faire and got 5 badges from 5 different exhibitors, but you want them all to be tagged "Maker Faire 2012").

2) Is it possible for metadata to be continuously updated?  For example, imagine I had a "thingiverse user" badge, meaning I was an active user of Thingiverse, a project-based design sharing website.  Now imagine that the website Thingiverse tracked the number of projects I posted to it.  Could I have that value be tracked continuously in my badges metadata, so that when I create a new project on Thingiverse my "thingiverse user" badge metadata goes from 2 projects to 3 projects automatically?  The other way to do this is the additional project triggers the creation of an additional badge (a "you achieved 3 projects!" badge), but that to me seems significantly less elegant.

3) I'm wondering how other people in the community want to see the metadata develop?  How much control will the community have in adjusting/creating additional metadata itself?  If the community wants to add additional metadata fields will we have to request that addition from the Open Badges team, or can the community add that functionality by itself?  It seems that in the long term the attachment of metadata is one of the most important functions of badges and relates to the idea of redesigning the traditional CV which has been discussed on this forum.  I'm just wondering what people's perspective is on it.

Greg
Re: [openbadges] Questions relating to metadata Sunny 4/21/12 10:46 AM
Hi Greg, 

I have answers to some of these questions which I hope may help:

On Sat, Apr 21, 2012 at 1:34 PM, Greg Austic <gbat...@gmail.com> wrote:
I had a few questions on met-data:

1) What badge metadata can currently be added to badges - ie how many fields?

Check out our github wiki page on assertions which lists all the required and optional metadata fields along with description if you haven't done so already: https://github.com/mozilla/openbadges/wiki/Assertions

This will be a good starting point. 
 
 Is there a limit to the amount of data per field?  

This information is detailed in the description for each metadata field. 
 
How hard would it be to add additional fields in the future, and is there a plan to do so?  

This is currently supported. The below is from our tech lead, Brian Brennan:

The caveat is that we hash the entire assertion and store the hash with the assertion in the database. When we periodically verify the assertion hosted on the issuer end, we check it against the hash to make sure the assertion has not changed since we received it. If it does, the badge would be marked "invalid" This is to prevent someone from issuing the "You are awesome badge!" then sneakily changing it later to the "You are terrible" badge. There currently isn't a method for updating the information received in the badge, though it's not off the table.

TL;DR -- issuers can put a reasonable amount of extra material into the badge, but that material must be static -- once the badge is issued, any change to that information must not change. Directly embedding things that could go stale would be bad.
 
We're looking at tagging our badges so that we can group them around events (in a similar way that you can put your badges in your backpack in groups, except that the tag will be globally associated with the badge).  For example, you can see all of the badges you got from a single event, even if the badges creators were different (imagine you went to the a Maker Faire and got 5 badges from 5 different exhibitors, but you want them all to be tagged "Maker Faire 2012").

2) Is it possible for metadata to be continuously updated?  

Please see above. 
 
For example, imagine I had a "thingiverse user" badge, meaning I was an active user of Thingiverse, a project-based design sharing website.  Now imagine that the website Thingiverse tracked the number of projects I posted to it.  Could I have that value be tracked continuously in my badges metadata, so that when I create a new project on Thingiverse my "thingiverse user" badge metadata goes from 2 projects to 3 projects automatically?  The other way to do this is the additional project triggers the creation of an additional badge (a "you achieved 3 projects!" badge), but that to me seems significantly less elegant.

3) I'm wondering how other people in the community want to see the metadata develop?  How much control will the community have in adjusting/creating additional metadata itself?  If the community wants to add additional metadata fields will we have to request that addition from the Open Badges team, or can the community add that functionality by itself?  It seems that in the long term the attachment of metadata is one of the most important functions of badges and relates to the idea of redesigning the traditional CV which has been discussed on this forum.  I'm just wondering what people's perspective is on it.

Greg

Re: [openbadges] Questions relating to metadata Greg Austic 4/22/12 5:43 AM
Great, thanks for pointing me in the right direction there, very helpful.

It may be useful to have non-static material in the long run if possible, particularly for websites as I described them above.  That way, badges could be used to consolidate and easily compare user stats from a wide variety of sites which for some people is a very important component of their experience/education/value.  Especially if it's easy to implement, the sites will jump right in.  It's one more step towards becoming a universal CV system.

Greg
Re: [openbadges] Questions relating to metadata Brian Brennan 4/23/12 7:36 AM
Hey Greg, 

Agreed that dynamic data is important, but the data itself should not be embedded in the badge -- stable pointers to the data (URLs) should be so when we implement signing, the badge itself won't have to be resigned every time the information gets updated.

Let me know if that doesn't sound reasonable or if I'm misunderstanding something, I want to make sure I'm not missing what could be an important use case.

Brian
Re: [openbadges] Questions relating to metadata Greg Austic 4/24/12 6:27 AM
That definitely makes sense - adjusting the badge itself creates lots of problems.  I guess I just think the functionality of the badge include a variable set of data is important for applications in sites like Thingiverse, Stack Exchanges, etc.  Perhaps an additional displayer (besides the badge) is needed to pull the data from those stable pointers and display your user information from that site in a useful and meaningful way.  It seems that having a "thingiverse user badge" which can display all of your thingiverse information is more useful than having 100 "I achieved X on thingiverse" badges, which would be required with a fixed set of data associated with the badge.  

Point is - stable pointers to data sounds like a good solution!  They could be used to mate the site's user information with a fixed badge in an easy, effective way which is great.  The question then is how to then redisplay the site user info on the badge side.

Greg
Re: [openbadges] Questions relating to metadata Bill Fitzgerald 4/25/12 4:34 PM
RE:

the badge itself won't have to be resigned every time the information gets updated.

Why would a specific badge be updated? It seems that, in most cases, earning a badge is a representation that a certain set of criteria were met by a certain person at a certain time.

If the criteria for a badge gets updated, it doesn't follow that past instances of the badge should also be updated, because the new criteria wouldn't apply to legacy badges. It seems like if the criteria for a badge changes, then that effectively makes it a new badge. 

What would be the use case for updating information on a badge after it had been earned?

Cheers,

Bill

On Monday, April 23, 2012 7:36:18 AM UTC-7, Brian Brennan wrote:
Hey Greg, 

Agreed that dynamic data is important, but the data itself should not be embedded in the badge -- stable pointers to the data (URLs) should be so when we implement signing, the badge itself won't have to be resigned every time the information gets updated.

Let me know if that doesn't sound reasonable or if I'm misunderstanding something, I want to make sure I'm not missing what could be an important use case.

Brian



On Sun, Apr 22, 2012 at 8:43 AM, Greg Austic wrote:
Great, thanks for pointing me in the right direction there, very helpful.

It may be useful to have non-static material in the long run if possible, particularly for websites as I described them above.  That way, badges could be used to consolidate and easily compare user stats from a wide variety of sites which for some people is a very important component of their experience/education/value.  Especially if it's easy to implement, the sites will jump right in.  It's one more step towards becoming a universal CV system.

Greg


On Saturday, April 21, 2012 1:46:31 PM UTC-4, Sunny wrote:
Hi Greg, 

I have answers to some of these questions which I hope may help:

On Sat, Apr 21, 2012 at 1:34 PM, Greg Austic <gbat...@gmail.com> wrote:
I had a few questions on met-data:

1) What badge metadata can currently be added to badges - ie how many fields?

Check out our github wiki page on assertions which lists all the required and optional metadata fields along with description if you haven't done so already: https://github.com/mozilla/openbadges/wiki/Assertions

This will be a good starting point. 
 
 Is there a limit to the amount of data per field?  

This information is detailed in the description for each metadata field. 
 
How hard would it be to add additional fields in the future, and is there a plan to do so?  

This is currently supported. The below is from our tech lead, Brian Brennan:

The caveat is that we hash the entire assertion and store the hash with the assertion in the database. When we periodically verify the assertion hosted on the issuer end, we check it against the hash to make sure the assertion has not changed since we received it. If it does, the badge would be marked "invalid" This is to prevent someone from issuing the "You are awesome badge!" then sneakily changing it later to the "You are terrible" badge. There currently isn't a method for updating the information received in the badge, though it's not off the table.

TL;DR -- issuers can put a reasonable amount of extra material into the badge, but that material must be static -- once the badge is issued, any change to that information must not change. Directly embedding things that could go stale would be bad.
 
We're looking at tagging our badges so that we can group them around events (in a similar way that you can put your badges in your backpack in groups, except that the tag will be globally associated with the badge).  For example, you can see all of the badges you got from a single event, even if the badges creators were different (imagine you went to the a Maker Faire and got 5 badges from 5 different exhibitors, but you want them all to be tagged "Maker Faire 2012").

2) Is it possible for metadata to be continuously updated?  

Please see above. 
 
For example, imagine I had a "thingiverse user" badge, meaning I was an active user of Thingiverse, a project-based design sharing website.  Now imagine that the website Thingiverse tracked the number of projects I posted to it.  Could I have that value be tracked continuously in my badges metadata, so that when I create a new project on Thingiverse my "thingiverse user" badge metadata goes from 2 projects to 3 projects automatically?  The other way to do this is the additional project triggers the creation of an additional badge (a "you achieved 3 projects!" badge), but that to me seems significantly less elegant.

3) I'm wondering how other people in the community want to see the metadata develop?  How much control will the community have in adjusting/creating additional metadata itself?  If the community wants to add additional metadata fields will we have to request that addition from the Open Badges team, or can the community add that functionality by itself?  It seems that in the long term the attachment of metadata is one of the most important functions of badges and relates to the idea of redesigning the traditional CV which has been discussed on this forum.  I'm just wondering what people's perspective is on it.

Greg


Re: [openbadges] Questions relating to metadata Greg Austic 4/26/12 8:20 AM
Hey Bill, I see your point.  I think I'm suggesting a significantly different use for badges that you described.  I would like to see some badges not represent a single achievement, but instead accumulate user data from a given source of education/experience.  So if I'm active at CNC Zone, Slashdot, Thingiverse, and Stack Exchange, I'll have user data from each of those sites (how many projects I posted, how many people have viewed my project pages, how many bumps my replies get in forums, how many years I've been a user, etc).  It would be nice to display that user data in a meaningful, consistent, and comparable way using a single "CNC Zone user" badge or "Slashdot user" badge.  Again, this relates to the long term desire for a next generation CV.

Right now, many of those sites are creating their own badges system (for example, see http://gaming.stackexchange.com/badges).  If we want to use badges as a unified environment for comparison of people's experiences and education, and not just within the silos of these individual sites, we need a way to pull all of these systems together in a coherent UI that we can all use.  The mozilla badge system has the potential to be able to do that with the addition of dynamic data via stable pointers as Brian suggested.  Stable pointers are especially good because they make the cost of these sites to interact with open badges very very low - just stick your data into a format that we can point to and there you go.

Greg