Properties to Skills

Search…
Different properties can be assigned to skills. Properties impact the way the skills are rendered in the frontend, information collected from the users and others.
Once associations have been created we can now give different properties to the nodes or skills:
Searchable, Not Searchable: We do not want all the elements or nodes to be Searchable as they may unnecessarily cause chaos in the search efficiency. Therefore, we mark nodes as Not Searchable
​
Verified, Not Verified, To Be Reviewed: Sometimes we may not want to include a node (all the child and grandchild nodes under it) as not to be seen (not just in search) in which case they can be marked as Not Verified. 
To Be Reviewed is used where a new skill has been added and needs examination on whether it is to be included or not. This is important, particularly where a skill has been added in master and the skill is then added to all the places where the master has been added. There are possibilities that the skill is not relevant in all the contexts where the master has been added
​
Discrete, Not Discrete: Discrete indicates that in LIVE this is the node that is considered as the layer 1 or the parent, ancestors (parent, grandparent etc.) will not be seen by users. The corollary of this is that Non Discrete users will be able to see the ancestors. For example, if we have a construct as follows:
 IT >> Tools & Technologies >> Programming Languages >> C++
 IT >> Tools & Technologies >> Databases >> Oracle
Let’s say Programming Languages and Databases are marked as ‘Discrete’, and go to the user side of things. When a user searches for Oracle, the user will be able to see that it is a child of Database and also see other siblings of Oracle (children of Database) like MySQL. However, they will not be able to see Tools and Technologies, which is the parent of Database. This is because Database is marked ‘Discrete’. This also means that Programming Languages, which is a sibling of Database, will not be automatically seen by the user as Database is ‘Discrete’. This is relevant from many angles, the most important being that it enables a smooth graphical representation where we want to relate stems from other branches. By default, skills when added from master are ‘Not Discrete’.
​
Rating and Rating Legend: Skills can be rated for proficiency. IYS offers a standard four levels (or four stars) of scale for rating on proficiencies. However, the rating scales or legends vary for the skills. For example, typical domain or contextual references are assigned years of experience as a rating scale. Tools and Technologies are on level of expertise. There are about seven (7) or eight (8) variations that are used. The system provides for creation of many rating legends. To the skills (one by one or in bulk), one can choose the rating legend that he/she wants to assign. There are times when there is no rating assigned. This is possible under two situations:
1.When the node is more like a connector and it itself cannot be considered a skill
2.When the node is elaboration or a higher level skill and they are mentioned to help the user consider these to rate on the higher level skill and not use it for rating (as it will only clutter the whole construct)
​
Tagging: Nodes can be tagged. A master of tags is maintained. Tags typically can be for a functional or industry category (like Sales, Marketing or Information Technology or Engineering) and for skills category (like Soft Skills, Tools and Technologies). Tagging plays a very important role while creating rules that can cut across the hierarchical and graphical structure that is created. For example, we could create a rule as if the tag is ‘Role of a Manager’, then assign managerial skills from the soft skills node. For skills tagged as Tools and Technologies, assign Rating Legend related to expertise on tools.
​
Proxy: Nodes could be assigned a Proxy term. Proxy terms are what will be visible in the search while the normal term will show in the skills profile. For example, 
Language Proficiency >> English >> Speaking
Language Proficiency >> English >> Writing
We create a Proxy for the two nodes as Speaking English and Writing English. These proxies appear in the search. Proxies have profound implications as they bring contextual meaning to terms while allowing for scaling up. Let's say we have a master called List of Machineries. Now let's say in association we want to create different occupations around machineries such as Technician, Operator, Designing, Manufacturing, Selling, Purchasing So, we create nodes like:
 Technician >>Repairing, Installing of Machineries>>[ Master of Machineries]
Manufacturing >>[ Master of Machineries]
Designing >>[ Master of Machineries]
Operating >>[ Master of Machineries]
Purchasing >>[ Master of Machineries]
We will add one master to all the five nodes i.e. Technician, Manufacturing, Designing, Operating and Purchasing, however, we will create different proxies for the machinery nodes under them. For example, say we have:Lathes in the Machineries master
Lathes will get added to all the five branches, but we will create proxies for Lathes in each of those branches, as:
 Repairing, Installing Lathes
 Manufacturing Lathes
 Designing Lathes
 Operating Lathes
 Purchasing Lathes

NB: Proper nouns by themselves are not skills. When we add a verb they become a skill.
In this process of creating proxy, we are enabled with scaling up as we need to add a skill to one master yet be able to add that skill to multiple contexts. Also, there is a provision to add prefixes and suffixes to skills to create proxy using rules, so that new skills added will have prefixes and suffixes added based on rule by the system itself.
​
Renaming of Nodes: Nodes can be renamed. This is only to be used in exceptional cases.
​
Descriptions: At node level, descriptions can be given to a skill.
​
Ordering of Skills: Skills or children of a node can be ordered. It can be done alphabetically or in a custom manner. The order here is also the order in which users will see the skills in the frontend.
​
From an operational point of view there are features as follows:
1.Copying of branches from one node to another
2.Cutting and pasting from one node to another
3.Copying of an association and making it a virtual node
4.Copying a virtual node and making it an association
5.Creating group of association (and so a family)
Skills Taxonomy Construct - Previous
Layer 3 - Association
Next - Skills Taxonomy Construct
Process for Constructing Areas
Last modified 1yr ago
Copy link