{"action":"created","issue":{"url":"https://api.github.com/repos/w3c/csvw/issues/365","labels_url":"https://api.github.com/repos/w3c/csvw/issues/365/labels{/name}","comments_url":"https://api.github.com/repos/w3c/csvw/issues/365/comments","events_url":"https://api.github.com/repos/w3c/csvw/issues/365/events","html_url":"https://github.com/w3c/csvw/issues/365","id":62020235,"number":365,"title":"Need for URL compaction","user":{"login":"iherman","id":520723,"avatar_url":"https://avatars.githubusercontent.com/u/520723?v=3","gravatar_id":"","url":"https://api.github.com/users/iherman","html_url":"https://github.com/iherman","followers_url":"https://api.github.com/users/iherman/followers","following_url":"https://api.github.com/users/iherman/following{/other_user}","gists_url":"https://api.github.com/users/iherman/gists{/gist_id}","starred_url":"https://api.github.com/users/iherman/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/iherman/subscriptions","organizations_url":"https://api.github.com/users/iherman/orgs","repos_url":"https://api.github.com/users/iherman/repos","events_url":"https://api.github.com/users/iherman/events{/privacy}","received_events_url":"https://api.github.com/users/iherman/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/w3c/csvw/labels/CSV%20to%20JSON%20mapping","name":"CSV to JSON mapping","color":"84b6eb"},{"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":1,"created_at":"2015-03-16T09:19:35Z","updated_at":"2015-03-16T09:23:54Z","closed_at":null,"body":"(This issue is a spin-off from PR #362 ; I will try to reproduce the issue discussion in this note, and add my response in a separate one. \r\n\r\n@gkellogg in https://github.com/w3c/csvw/pull/362#issuecomment-80686059:\r\n\r\n> Step 3.1 of Generating the Objects; propertyUrl is expanded in the metadata definition of URI Template Properties. These should be re-compacted to terms or prefixed names to be used as property names.\r\n\r\n@gkellogg in https://github.com/w3c/csvw/pull/362#issuecomment-80734873\r\n\r\n>  If propertyUrl is rdf:type, use @type for name, Compact values using the same mechanism for propertyUrl compaction.\r\n\r\n@iherman https://github.com/w3c/csvw/pull/362#issuecomment-80943074\r\n\r\n> I wonder how to do that properly, and whether this is not something to be described more generally somewhere. Indeed, compacting the URI may be relevant for aboutUrl-s and valueUrl-s as well; after all, if we do use compacted values, they may look better. Of course, propertyUrl-s are the place where it occurs the most often, but may also occur for the other two. Ie, wouldn't it be better to refer to this in the model document, saying that the value returns a full URI as well as a compacted URI when possible? Conversions may then use what they want.\r\n\r\n@iherman https://github.com/w3c/csvw/pull/362#issuecomment-80944032\r\n\r\n> See my [previous reply](https://github.com/w3c/csvw/pull/362#issuecomment-80943074): I think the compaction should be described at one place, then this can be incorporated. So not done for the moment.\r\n\r\n@gkellogg https://github.com/w3c/csvw/pull/362#issuecomment-81174308\r\n\r\n> Because of the differences in how values and properties are compacted (with or without being like @vocab in JSON-LD), it would be difficult to do this as part of the cell model. However, the algorithm is pretty simple, and I can create a section in CSV2JSON on compacting IRIs, but probably best to wait until outstanding PRs are merged.\r\n>\r\n> Basically, for properties and values of @type:\r\n>\r\n>  *  If the URL exactly matches a term in the context, replace the URL with that term.\r\n>  *  Otherwise, if the the context has a term who's URI definition is a prefix of the URL, replace the URL with a prefixed name formed from the term, a ':', and the remainder of the URL after the URL prefix.\r\n>\r\n>For all other values which are a URL:\r\n>\r\n> *  If the the context has a term who's URI definition is a prefix of the URL, replace the URL with a prefixed name formed from the term, a ':', and the remainder of the URL after the URL prefix.\r\n>\r\n> Note that this does not do any document-relative compaction of values.\r\n\r\n@iherman https://github.com/w3c/csvw/pull/362#issuecomment-81200989\r\n> Hm. I do not really understand why there would be a difference. We do not have a @vocab in the metadata; the compaction of the URI-s are the same everywhere and are based exclusively on the predefined prefixes that are known in advance. It is of course a question whether this would be useful for RDF (probably not), but may be for other conversions. \r\n>\r\n> Also, Do we allow for fragmentbid-s or URI-s with query parts to be compacted? I guess probably yes, but this should be made clear...  \r\n\r\n\r\n@gkellogg https://github.com/w3c/csvw/pull/362#issuecomment-81399374\r\n> Properties and @type are vocabulary-relative, @id is document-relative. @id cannot take a term as a value, only a URI or prefixed name. Properties and @type can take a type (obviously, as intended for properties in particular), or a URI or prefixed name. A relative URL in property/@type is relative to @vocab, if defined. On @id it's relative to the document. For the details, see JSON-LD.\r\n>\r\n> As a result, a value of a property or @type can compact to a term, but not an @id (or other use of a valueUrl). That's just the way it is. We could of course, not compact to terms at all, in which case if we had http://www.w3.org/ns/csvw/Table, it would compact to 'Table:rather than justTable`, but that would be odd.\r\n>\r\n> Currently, I don't specify compacting URLs to generally be document relative (CSV2JSON has a special case for this). But, there's no reason that fragment-ids or query parameters would be excluded here. If we choose to compact to relative URIs (not sure there's a need for this), then it would simply be by removing the document URL prefix, if it ends in \"/\" or \"#\"; otherwise, probably not worth doing. I'm not sure we really need to do this, though.\r\n\r\n\r\n"},"comment":{"url":"https://api.github.com/repos/w3c/csvw/issues/comments/81529992","html_url":"https://github.com/w3c/csvw/issues/365#issuecomment-81529992","issue_url":"https://api.github.com/repos/w3c/csvw/issues/365","id":81529992,"user":{"login":"iherman","id":520723,"avatar_url":"https://avatars.githubusercontent.com/u/520723?v=3","gravatar_id":"","url":"https://api.github.com/users/iherman","html_url":"https://github.com/iherman","followers_url":"https://api.github.com/users/iherman/followers","following_url":"https://api.github.com/users/iherman/following{/other_user}","gists_url":"https://api.github.com/users/iherman/gists{/gist_id}","starred_url":"https://api.github.com/users/iherman/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/iherman/subscriptions","organizations_url":"https://api.github.com/users/iherman/orgs","repos_url":"https://api.github.com/users/iherman/repos","events_url":"https://api.github.com/users/iherman/events{/privacy}","received_events_url":"https://api.github.com/users/iherman/received_events","type":"User","site_admin":false},"created_at":"2015-03-16T09:23:54Z","updated_at":"2015-03-16T09:23:54Z","body":"@gkellogg wrote:\r\n\r\n> Properties and @type are vocabulary-relative, @id is document-relative. @id cannot take a term as a value, only a URI or prefixed name. Properties and @type can take a type (obviously, as intended for properties in particular), or a URI or prefixed name. A relative URL in property/@type is relative to @vocab, if defined. On @id it's relative to the document. For the details, see JSON-LD.\r\n\r\nFor our users the reference to JSON-LD does not help.\r\n\r\nB.t.w., I am not even sure I understand. All these properties generate an absolute URL. That part is independent of compaction, it is done by the template expansion. The compaction should be restricted to the predefined prefixes that we have (we have no `@vocab`). So if the `@id` value is, by some coincidence, compacted with a prefix that happens to be predefined, so what? It is still correct, isn't it? In other words, I am not sure I follow your argumentation. But... see below\r\n\r\n> As a result, a value of a property or @type can compact to a term, but not an @id (or other use of a valueUrl). That's just the way it is. We could of course, not compact to terms at all, in which case if we had http://www.w3.org/ns/csvw/Table, it would compact to 'Table:rather than justTable`, but that would be odd.\r\n\r\nI presume what you mean by 'term' are the terms as defined in the metadata document (again, we have no notion of @vocab here, so that is the only one that makes sense). Let me then restrict this while issue to a simpler case:\r\n\r\n* we do compaction on `propertyUrl`-s only (and we do not touch `aboutUrl` and `valueUrl`)\r\n* compaction means replacing a URL with a prefixed case for all the prefixes defined in the initial context, and nothing else\r\n* `rdf:type` is exchanged against `@type`\r\n\r\nThat covers, in my view, the basic situation whereby we get \"proper\" names in the pure JSON output; if the user uses aboutUrl and valueUrl, he/she counts on URL-s anyway, so that is it. The issue around `csvw:Table` does not really arise in practice; I do not expect anybody using `propertyUrl` for `csvw` terms, so it is not a real issues.\r\n\r\nIf we accept these restrictions, I maintain that compaction is something that other serializations can also use, so it is worth defining that in general.\r\n"}}