![\"Gate\"](\"https://storage.googleapis.com/kaggle-media/competitions/kaggle/3338/media/gate.png\")
You cannot sign up to Kaggle from multiple accounts and therefore you cannot submit from multiple accounts.
\r\n\r\n Privately sharing code or data outside of teams is not permitted.\r\n It's okay to share code if made available to all participants on the forums.\r\n
\r\n\r\n Team mergers are allowed and can be performed by the team leader. In order to merge, the combined team must have a total submission count less than or equal to the maximum allowed as of the merge date. The maximum allowed is the number of submissions per day multiplied by the number of days the competition has been running.
\r\n
There is no maximum team size.
\r\nYou may submit a maximum of 2 entries per day.
\r\nYou may select up to 2 final submissions for judging.
\r\nStart Date: 5/29/2013 7:56 PM UTC
\r\nMerger Deadline: None
\r\nEntry Deadline: None
\r\nEnd Date: 7/31/2013 11:59 PM UTC
\r\n\t\r\nEmployees of Amazon are not eligible to receive prizes.
\r\nI agree to the competition rules.
", "isPublished": false, "hasIsPublished": false, "postTitle": "", "hasPostTitle": false, "mimeType": "", "hasMimeType": false }, { "name": "data-description", "content": "The data consists of real historical data collected from 2010 & 2011. Employees are manually allowed or denied access to resources over time. You must create an algorithm capable of learning from this historical data to predict approval/denial for an unseen set of employees.
\r\ntrain.csv - The training set. Each row has the ACTION (ground truth), RESOURCE, and information about the employee's role at the time of approval
\r\ntest.csv - The test set for which predictions should be made. Each row asks whether an employee having the listed characteristics should have access to the listed resource.
\r\n| Column Name | \r\nDescription | \r\n
| ACTION | \r\nACTION is 1 if the resource was approved, 0 if the resource was not | \r\n
| RESOURCE | \r\nAn ID for each resource | \r\n
| MGR_ID | \r\nThe EMPLOYEE ID of the manager of the current EMPLOYEE ID record; an employee may have only one manager at a time | \r\n
| ROLE_ROLLUP_1 | \r\nCompany role grouping category id 1 (e.g. US Engineering) | \r\n
| ROLE_ROLLUP_2 | \r\nCompany role grouping category id 2 (e.g. US Retail) | \r\n
| ROLE_DEPTNAME | \r\nCompany role department description (e.g. Retail) | \r\n
| ROLE_TITLE | \r\nCompany role business title description (e.g. Senior Engineering Retail Manager) | \r\n
| ROLE_FAMILY_DESC | \r\nCompany role family extended description (e.g. Retail Manager, Software Engineering) | \r\n
| ROLE_FAMILY | \r\nCompany role family description (e.g. Retail Manager) | \r\n
| ROLE_CODE | \r\nCompany role code; this code is unique to each role (e.g. Manager) | \r\n
When an employee at any company starts work, they first need to obtain the computer access necessary to fulfill their role. This access may allow an employee to read/manipulate resources through various applications or web portals. It is assumed that employees fulfilling the functions of a given role will access the same or similar resources. It is often the case that employees figure out the access they need as they encounter roadblocks during their daily work (e.g. not able to log into a reporting portal). A knowledgeable supervisor then takes time to manually grant the needed access in order to overcome access obstacles. As employees move throughout a company, this access discovery/recovery cycle wastes a nontrivial amount of time and money.
\r\nThere is a considerable amount of data regarding an employee’s role within an organization and the resources to which they have access. Given the data related to current employees and their provisioned access, models can be built that automatically determine access privileges as employees enter and leave roles within a company. These auto-access models seek to minimize the human involvement required to grant or revoke employee access.
\r\nThe objective of this competition is to build a model, learned using historical data, that will determine an employee's access needs, such that manual access transactions (grants and revokes) are minimized as the employee's attributes change over time. The model will take an employee's role information and a resource code and will return whether or not access should be granted.
\r\nThis competition is hosted in collaboration with the IEEE International Workshop on Machine Learning for Signal Processing (MLSP 2013)
\r\n![\"IEEE](\"https://storage.googleapis.com/kaggle-media/competitions/kaggle/3338/media/ieee.gif\")
![\"IEEE](\"https://storage.googleapis.com/kaggle-media/competitions/kaggle/3338/media/ieee_mb_blue.jpg\")
Submissions are judged on area under the ROC curve.
\r\nIn Matlab (using the stats toolbox):
\r\n[~, ~, ~, auc ] = perfcurve(true_labels, predictions, 1);\r\n\r\n
In R (using the verification package):
\r\nauc = roc.area(true_labels, predictions)\r\n\r\n
In python (using the metrics module of scikit-learn):
\r\nfpr, tpr, thresholds = metrics.roc_curve(true_labels, predictions, pos_label=1)\r\nauc = metrics.auc(fpr,tpr)\r\n
For every line in the test set, submission files should contain two columns: id and ACTION. In the ground truth, ACTION is 1 if the resource should be allowed, 0 if the resource should not. Your predictions do not need to be binary. You may submit probabilities/predictions having any real value. The submission file should have a header.
\r\nid,ACTION\r\n1,1\r\n2,0.2\r\n3,1\r\n4,0\r\n5,2\r\n...\r\n", "isPublished": false, "hasIsPublished": false, "postTitle": "", "hasPostTitle": false, "mimeType": "", "hasMimeType": false }, { "name": "Prizes", "content": "
First Place
\r\nWinning code is posted here.
\r\nSecond Place
\r\n\r\nWinning code is posted here.
\r\nThird Place
\r\nWinning code is posted here.
\r\n\r\n", "isPublished": false, "hasIsPublished": false, "postTitle": "", "hasPostTitle": false, "mimeType": "", "hasMimeType": false } ] }