{"action":"created","issue":{"url":"https://api.github.com/repos/openml/python/issues/25","labels_url":"https://api.github.com/repos/openml/python/issues/25/labels{/name}","comments_url":"https://api.github.com/repos/openml/python/issues/25/comments","events_url":"https://api.github.com/repos/openml/python/issues/25/events","html_url":"https://github.com/openml/python/issues/25","id":126398244,"number":25,"title":"Retrieving class labels of a dataset","user":{"login":"PG-TUe","id":15890747,"avatar_url":"https://avatars.githubusercontent.com/u/15890747?v=3","gravatar_id":"","url":"https://api.github.com/users/PG-TUe","html_url":"https://github.com/PG-TUe","followers_url":"https://api.github.com/users/PG-TUe/followers","following_url":"https://api.github.com/users/PG-TUe/following{/other_user}","gists_url":"https://api.github.com/users/PG-TUe/gists{/gist_id}","starred_url":"https://api.github.com/users/PG-TUe/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/PG-TUe/subscriptions","organizations_url":"https://api.github.com/users/PG-TUe/orgs","repos_url":"https://api.github.com/users/PG-TUe/repos","events_url":"https://api.github.com/users/PG-TUe/events{/privacy}","received_events_url":"https://api.github.com/users/PG-TUe/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":4,"created_at":"2016-01-13T11:29:36Z","updated_at":"2016-01-14T09:40:49Z","closed_at":null,"body":"I'm working on a function which lets users more easily run machine learning experiments through the OpenML API. For every run, the arff-file which contains the result should contain the names of the class labels. Currently there is no way to directly retrieve class labels from an OpenML dataset object.\r\n\r\nIn the code below, let's assume that 'dataset' is an OpenML Dataset entity of the [iris dataset](http://www.openml.org/d/61), so it should have the class labels {Iris-setosa,Iris-versicolor,Iris-virginica}.\r\nWhat I would like is (something like) this:\r\n```\r\ndataset.class_labels\r\n>>> [\"Iris-setosa\", \"Iris-versicolor\", \"Iris-virginica\"]\r\n```\r\nInstead, I currently do this (which works):\r\n```\r\narffFileName = dataset.data_file;\r\nwith open(arffFileName) as fh:\r\n    arffData = arff.ArffDecoder().decode(fh);\r\n    dataAttributes = dict(arffData['attributes']);\r\ndataAttributes['class'];\r\n```\r\nThat is, I open the associated ARFF file, and decode it to find the class label information. After executing above code, dataAttributes['class'] is exactly  [\"Iris-setosa\", \"Iris-versicolor\", \"Iris-virginica\"].\r\n\r\nAt first I thought I would simply change the initialization of the dataset, and add a class_label attribute, but looking into it raised the following questions:\r\n -  In [apiconnector.py line 456](https://github.com/openml/python/blob/feature/script/openml/apiconnector.py#L456), which currently initializes the dataset objects, the dataset description is used to initialize the dataset object. Class labels are not information contained in the dataset description XML file, but instead in the data ARFF file. This means that in order to retrieve the class labels, the ARFF file has to be opened. First, this seems to clash with the design so far, in that the dataset can be constructed from the description alone (and if the dataset ARFF is already cached, it then does not need to be opened). Second, from the comment on  [apiconnector.py line 536](https://github.com/openml/python/blob/feature/script/openml/apiconnector.py#L536) I gather that ARFF files might be sufficiently large not to want to load them into memory if not necessary. Opening a potentially colossal file just to search for the class labels attribute might be too much overhead, though since the attributes are listed before the data, I think a lazy read might negate much of the overhead. So should the class labels be stored in the description, or should the ARFF file be read upon construction of the dataset?\r\n -  Not all datasets have class labels (for example unsupervised learning problems), so in that sense it is not a generic dataset property. For those datasets, I'm in favor of just setting class_labels to None, but perhaps there are reasons to instead return an empty list. Alternatively, this could be an argument against having a class_label property.\r\n\r\nIf we can reach a conclusion, then I will try to implement it on my feature branch (feature/script (which I admit is poorly named and will rename to feature/run or feature/autorun)). Looking forward to hearing your thoughts.\r\n\r\nKind regards,\r\nPieter Gijsbers"},"comment":{"url":"https://api.github.com/repos/openml/python/issues/comments/171586874","html_url":"https://github.com/openml/python/issues/25#issuecomment-171586874","issue_url":"https://api.github.com/repos/openml/python/issues/25","id":171586874,"user":{"login":"mfeurer","id":5320498,"avatar_url":"https://avatars.githubusercontent.com/u/5320498?v=3","gravatar_id":"","url":"https://api.github.com/users/mfeurer","html_url":"https://github.com/mfeurer","followers_url":"https://api.github.com/users/mfeurer/followers","following_url":"https://api.github.com/users/mfeurer/following{/other_user}","gists_url":"https://api.github.com/users/mfeurer/gists{/gist_id}","starred_url":"https://api.github.com/users/mfeurer/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mfeurer/subscriptions","organizations_url":"https://api.github.com/users/mfeurer/orgs","repos_url":"https://api.github.com/users/mfeurer/repos","events_url":"https://api.github.com/users/mfeurer/events{/privacy}","received_events_url":"https://api.github.com/users/mfeurer/received_events","type":"User","site_admin":false},"created_at":"2016-01-14T09:40:49Z","updated_at":"2016-01-14T09:40:49Z","body":"I would go one step further than Joaquin and say that even a task does not need to know the labels. From what I understand, only the run object needs to know the label. In practice, the run object would get the labels from the task. Thus, the classification task object should implement that functionality.\r\n\r\nFor now, I would suggest that you add a callback to the liac-arff main loop. Then you can check whether the attributes are already read and stop parsing at that point."}}