Basic skill DataModel

[ben-razor]

First attempt at a skill DataModel.

Basic Skill is intended as a lightweight way for users to register skills against their decentralized identity, with the potential for more advanced use cases where they may be needed.

For simple cases, fields in the schema are used directly. For more advanced cases a client or connected group of clients can use the details URI field to extend the skill schema.

Many of the fields have been left as strings for flexibility. For example, the issuer field may use a did to link the skill to a specific organisation, or if the user is using the schema informally, they may simply enter a company name they have worked for.

Case 1 - Portfolio site

A user may wish to enter their own list of skills for a portfolio site. In this case, they would enter the name, id, description and image. They may enter some tags to allow searches.

Case 2 - CV / Education

An official body may issue qualifications for a user. In this case, the issuer field would be filled with the did of the body. They would digitally sign the json object with the details of the qualification, and include these in the issuerVerfication section.

Case 3 - Decentralized gaming platforms

Similar to use 2, games can issue skills for a user when they complete achievements in the game. Through use of the issuer and verification fields other games can verify that the user has a skill that is relevant in their environment. The new user would then immediately be able to perform tasks requiring the same skill without needing to gain it again for multiple games.

[oed]

Seems like it's only possible to store one skill within this schema? Is the intention not to be able to have an array of skills? Otherwise you will need to create a new DataModel for each skill.

[ben-razor]

This might come from the fact I'm not yet sure how ceramic is intended to be interacted with.

I was working on the assumption that you have a Schema for 1 record, then each time you perform a write against a data store (for one skill), it creates a commit of that record. Then you access the stream of commits to find all your skills.

The other way I thought it might work is like you're suggesting, that the schema itself contains multiple records and each commit would contain all your currently active skills. That makes more sense in that it's easier to remove records, and lookups only need to look at the latest record. The downside being that more data is stored.

Is that how it should be? It does make more sense that way now I see it written down.

[oed]

So yes. There is one DataModel "definition" per record. You can think of the schema as a column in a user table, i.e. each user has one record per column.

[ben-razor]

I tried a few methods changing the schema to use an array but I was getting errors when trying to use the generated model. The previously working schema also has the same issue so it must be a bug that's arrived in my model generator. I'll have to bail on this for the moment as I have no way to test the model.

[oed]

Top level arrays doesn't work in Ceramic right now due to a bug in json-patch @ben-razor. Try wrapping the array in an object and see if it helps!

[ben-razor]

@oed I think I had the top level array issue on the first attempt and put in a fudge that broke the model export of the subsequent versions. The model in the repo now seems to work with lists of skills.

[Cali93]

Hi @ben-razor,

I just saw this branch, we've created a working group to work on the skills schema.
Would you be interested to join ? see discussion
We'll probably start with the awesome schema you made to create variants and then challenge each other's schema to find a common ground.

[ben-razor]

Hi @Cali93, this is my only experience in this area but I'm happy to contribute what I've learned from working on this project.