{"action":"created","issue":{"url":"https://api.github.com/repos/json-ld/json-ld.org/issues/583","repository_url":"https://api.github.com/repos/json-ld/json-ld.org","labels_url":"https://api.github.com/repos/json-ld/json-ld.org/issues/583/labels{/name}","comments_url":"https://api.github.com/repos/json-ld/json-ld.org/issues/583/comments","events_url":"https://api.github.com/repos/json-ld/json-ld.org/issues/583/events","html_url":"https://github.com/json-ld/json-ld.org/issues/583","id":293491581,"number":583,"title":"Introducing @dir ?","user":{"login":"iherman","id":520723,"avatar_url":"https://avatars0.githubusercontent.com/u/520723?v=4","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":[{"id":3978881,"url":"https://api.github.com/repos/json-ld/json-ld.org/labels/api","name":"api","color":"F5A9F2","default":false},{"id":119746,"url":"https://api.github.com/repos/json-ld/json-ld.org/labels/spec-design","name":"spec-design","color":"e10c02","default":false},{"id":6627833,"url":"https://api.github.com/repos/json-ld/json-ld.org/labels/syntax","name":"syntax","color":"FFFF00","default":false},{"id":447701005,"url":"https://api.github.com/repos/json-ld/json-ld.org/labels/under-review","name":"under-review","color":"bfdadc","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":{"url":"https://api.github.com/repos/json-ld/json-ld.org/milestones/3","html_url":"https://github.com/json-ld/json-ld.org/milestone/3","labels_url":"https://api.github.com/repos/json-ld/json-ld.org/milestones/3/labels","id":169853,"number":3,"title":"JSON-LD 1.1","description":"This milestone keeps track of all issues/features that are being considered for JSON-LD 1.1.","creator":{"login":"lanthaler","id":456407,"avatar_url":"https://avatars2.githubusercontent.com/u/456407?v=4","gravatar_id":"","url":"https://api.github.com/users/lanthaler","html_url":"https://github.com/lanthaler","followers_url":"https://api.github.com/users/lanthaler/followers","following_url":"https://api.github.com/users/lanthaler/following{/other_user}","gists_url":"https://api.github.com/users/lanthaler/gists{/gist_id}","starred_url":"https://api.github.com/users/lanthaler/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/lanthaler/subscriptions","organizations_url":"https://api.github.com/users/lanthaler/orgs","repos_url":"https://api.github.com/users/lanthaler/repos","events_url":"https://api.github.com/users/lanthaler/events{/privacy}","received_events_url":"https://api.github.com/users/lanthaler/received_events","type":"User","site_admin":false},"open_issues":20,"closed_issues":84,"state":"open","created_at":"2012-09-04T15:40:09Z","updated_at":"2018-02-08T22:11:58Z","due_on":null,"closed_at":null},"comments":22,"created_at":"2018-02-01T11:14:37Z","updated_at":"2018-02-09T13:55:48Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"In some situations it is important/necessary to include the base direction of a text, alongside its language; see the [“Requirements for Language and Direction Metadata in Data Formats”](https://w3c.github.io/string-meta/) for further details. In practice, in a vanilla JSON, it would require something like:\r\n\r\n \r\n  ```\r\n  \"title\": [ { \"value\": \"Moby Dick\", \"lang\": \"en\" },\r\n\t         { \"value\": \"موبي ديك\", \"lang\": \"ar\"  \"dir\": \"rtl\"}\r\n\t       ]  \r\n  ```\r\n\r\n  (the example comes from that document).\r\n\r\n  At this moment, I believe the only way you can reasonably express that in JSON-LD is via cheating a bit:\r\n\r\n  ```\r\n  \"title\": [ { \"@value\": \"Moby Dick\", \"@language\": \"en\" },\r\n\t         { \"@value\": \"موبي ديك\",  \"@language\": \"ar\"  \"dir\": \"rtl\"}\r\n\t       ]  \r\n  ```\r\n\r\n  and making sure that the `dir` term is _not_ defined in the relevant `@context` so that, when generating the RDF output, that term is simply ignored. But that also means that there is no round-tripping, that term will disappear after expansion.\r\n\r\n  The difficulty lies in the RDF layer, in fact; RDF does not have any means (alas!) to express text direction. On the other hand, this missing feature is a general I18N problem whenever JSON-LD is used (there were issues when developing the Web Annotation Model, these issues are popping up in the Web Publication work, etc.).\r\n\r\n  Here is what I would propose as a non-complete solution\r\n\r\n  1. Let us introduce a `@dir` term, alongside `@language`. This means this term can be used in place of `dir` above, ie, it is a bona-fide part of a string representation, and would therefore be kept in the compaction/expansion steps, can also be used for framing.\r\n  2. In JSON-LD 1.1, `@dir` is _ignored_ when transforming into RDF. I.e., only the language tag would be used.\r\n  3. We _may_ initiate some work in the RDF community to solve this issue. There may be several ways, each of them require the RDF community to chime in\r\n  \t3.1. Define a mechanism of \"parametrized\" standard datatypes that represent a (language,direction) pair. One would then get something like`[] ex:title \"موبي ديك\"^^rdf:internationalText(ar,rtl) ;`\r\n  \t3.2. Go for a \"generalized\" RDF where strings can also appear as subjects (that has been a matter of dispute for a long time...). That would give the possibility to add such attribute to texts like directions\r\n  \t3.3. Some other mechanisms that I cannot think about\r\n  4. In a future JSON-LD 1.* the `@dir` value can be properly mapped onto an RDF representing the right choices (if such choices are worked out)\r\n\r\nCc: @BigBlueHat @r12a\r\n"},"comment":{"url":"https://api.github.com/repos/json-ld/json-ld.org/issues/comments/364439938","html_url":"https://github.com/json-ld/json-ld.org/issues/583#issuecomment-364439938","issue_url":"https://api.github.com/repos/json-ld/json-ld.org/issues/583","id":364439938,"user":{"login":"lisp","id":191726,"avatar_url":"https://avatars1.githubusercontent.com/u/191726?v=4","gravatar_id":"","url":"https://api.github.com/users/lisp","html_url":"https://github.com/lisp","followers_url":"https://api.github.com/users/lisp/followers","following_url":"https://api.github.com/users/lisp/following{/other_user}","gists_url":"https://api.github.com/users/lisp/gists{/gist_id}","starred_url":"https://api.github.com/users/lisp/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/lisp/subscriptions","organizations_url":"https://api.github.com/users/lisp/orgs","repos_url":"https://api.github.com/users/lisp/repos","events_url":"https://api.github.com/users/lisp/events{/privacy}","received_events_url":"https://api.github.com/users/lisp/received_events","type":"User","site_admin":false},"created_at":"2018-02-09T13:55:48Z","updated_at":"2018-02-09T13:55:48Z","author_association":"NONE","body":"\n> On 2018-02-09, at 14:34, Ivan Herman <notifications@github.com> wrote:\n> \n>>  Note that using (2) is perfectly valid today, ie, \"\\u200Fabcdefg\" is not equal to \"abcdefg\", which perfectly in line with the definitions you refer to.\n> \n> in the sense which is implied by the “^ltr” proposal, as i understand the provisions which those passages from my earlier note describe for string comparison in the presence of language tags, no.\n> \n> Why?\n\nbecause the language tag adds an additional dimension to processing control paths in order to accommodate the equivalence rules.\nto make matters worse, its definition is not even complete.\neither the domain should be expanded and include operations which close over the entire space, or, if that is not the intent, the relationship should be reified via a predicate.\nto apply sugar to the situation would be to compound a mistake.\nsee: https://www.w3.org/TR/sparql11-query/#modOrderBy\n\n\n"}}
{"actor":{"display_login":"lisp"}}