- From: gsergiu via GitHub <sysbot+gh@w3.org>
- Date: Sat, 13 Feb 2016 23:01:37 +0000
- To: public-annotation@w3.org
@iherman 1. Yes ... this is also our question which approach should be used to embed multilingual texts in the annotation body? The current examples include only "mono"-lingual texts, and this is not enough for our usecase. We aim at being compliant with the standard, and we want to avoid extending the context. 2. If I got it right with dc language you mean using “language”, instead of “@language”. Well ... that is not that much the problem from my point of view. However by taking a look in the string-internationalization, in the json-ld, I saw first that the section is non-normative, and secondly I saw that in examples there are several different way to embed “language-maps”. https://www.w3.org/TR/json-ld/#string-internationalization a) Example 31 is actually monolingual. b) Example 32 is only bilingual , in the sense the it uses “ja” or “null”. I also don’t like the idea to use embedded “@context” elements for resetting the language. c) Example 33, seems to be the one that is very close to the “text@language” format used in turtle. But again this overloads massively the context, and more than that for every multilingual field. That’s a total no go from my side. d) Example 34 is the most natural and compact representation for end users. However, this still requires to add "@container": "@language" in the context (for the “text” property I assume) e) Example 35 and 36 are exactly the representations discussed in the previous comments in this thread... So ... by looking as these options, I think that the question is still open. Which should be the preffered solution? 3. I think that in the context of Web (& annotations) the String internationalization is very important and I would be glad if the WA standard proposes a normative solution for it. Don’t you agree on this? -- GitHub Notification of comment by gsergiu Please view or discuss this issue at https://github.com/w3c/web-annotation/issues/149#issuecomment-183769804 using your GitHub account
Received on Saturday, 13 February 2016 23:01:39 UTC