{"action":"created","issue":{"url":"https://api.github.com/repos/w3c/csvw/issues/128","labels_url":"https://api.github.com/repos/w3c/csvw/issues/128/labels{/name}","comments_url":"https://api.github.com/repos/w3c/csvw/issues/128/comments","events_url":"https://api.github.com/repos/w3c/csvw/issues/128/events","html_url":"https://github.com/w3c/csvw/issues/128","id":52274162,"number":128,"title":"language term ambigious","user":{"login":"gkellogg","id":46296,"avatar_url":"https://avatars.githubusercontent.com/u/46296?v=3","gravatar_id":"","url":"https://api.github.com/users/gkellogg","html_url":"https://github.com/gkellogg","followers_url":"https://api.github.com/users/gkellogg/followers","following_url":"https://api.github.com/users/gkellogg/following{/other_user}","gists_url":"https://api.github.com/users/gkellogg/gists{/gist_id}","starred_url":"https://api.github.com/users/gkellogg/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/gkellogg/subscriptions","organizations_url":"https://api.github.com/users/gkellogg/orgs","repos_url":"https://api.github.com/users/gkellogg/repos","events_url":"https://api.github.com/users/gkellogg/events{/privacy}","received_events_url":"https://api.github.com/users/gkellogg/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/w3c/csvw/labels/Metadata%20vocabulary%20document","name":"Metadata vocabulary document","color":"5319e7"},{"url":"https://api.github.com/repos/w3c/csvw/labels/Requires%20telcon%20discussion/decision","name":"Requires telcon discussion/decision","color":"e11d21"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":3,"created_at":"2014-12-17T18:28:54Z","updated_at":"2015-01-23T16:42:55Z","closed_at":null,"body":"We specify `csvw:language` as a property of a Column, and define a `language` term accordingly. We also say we want terms for all xsd types, including `xsd:language`. This creates an ambiguity. Perhaps the use of `xsd` types in a metadata document should always use the CURIE form, as we've already created specific aliases (such as `any`) for important datatypes."},"comment":{"url":"https://api.github.com/repos/w3c/csvw/issues/comments/71222644","html_url":"https://github.com/w3c/csvw/issues/128#issuecomment-71222644","issue_url":"https://api.github.com/repos/w3c/csvw/issues/128","id":71222644,"user":{"login":"gkellogg","id":46296,"avatar_url":"https://avatars.githubusercontent.com/u/46296?v=3","gravatar_id":"","url":"https://api.github.com/users/gkellogg","html_url":"https://github.com/gkellogg","followers_url":"https://api.github.com/users/gkellogg/followers","following_url":"https://api.github.com/users/gkellogg/following{/other_user}","gists_url":"https://api.github.com/users/gkellogg/gists{/gist_id}","starred_url":"https://api.github.com/users/gkellogg/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/gkellogg/subscriptions","organizations_url":"https://api.github.com/users/gkellogg/orgs","repos_url":"https://api.github.com/users/gkellogg/repos","events_url":"https://api.github.com/users/gkellogg/events{/privacy}","received_events_url":"https://api.github.com/users/gkellogg/received_events","type":"User","site_admin":false},"created_at":"2015-01-23T16:42:55Z","updated_at":"2015-01-23T16:42:55Z","body":"The problem comes with the context definition for the terms. To do what you want would require something like the following:\r\n\r\n    {\r\n      \"@context\": {\r\n        ...\r\n        \"language\": {\"@id\": \"csvw:language\", \"@language\": null},\r\n        \"language\": \"xsd:language\",\r\n        ..\r\n      }\r\n    }\r\n\r\nHaving two entries in a JSON object with the same key is illegal. That is the gist of what I'm saying, is that we can't define both terms in the context.\r\n\r\nHowever, you're talking about the value of the `datatype` property; I think the property definition makes  this confusing:\r\n\r\n> An atomic property that contains a single string that is the main datatype of the values of the cell. ...\r\n\r\nIn reality, the value is expected to denote the datatype, and should be expanded to a URI. This means the term definition should be the following:\r\n\r\n    \"datatype\": {\"@id\": \"csvw:datatype\", \"@type\": \"@vocab\"}\r\n\r\nmeaning that the values are expanded as vocabulary terms. So, saying `\"datatype: \"anyUri\"` means that `anyUri` is expanded as a vocabulary term, which would make it the same as `xsd:anyUri`. You can see where the problem is using the value `language` in this case.\r\n\r\nAn alternative interpretation is that the value of `datatype` _is_ a string, but then some mechanism for mapping that string value to a datatype URI is needed which would have to be CSVW-specific, rather than making use of the JSON-LD mechanism. This seems like adding needless complexity to CSVW and questions the purpose of using JSON-LD as the basis for metadata in the first place."}}