Hi Felix,
here is a short example of what I mean with custom span pointers.
{
"headline" : "Today Acme Inc is prod to announce that John Doe has joined the company as Vice President of Infinite Improbability drive development.",
"annotations" : [
{ "type" : "date", "subtype" : "relative-issue", "ref" : "2015-10-18T14:19:54+00:00", "span" : [0,4] },
{ "type" : "name", "subtype" : "company", "ref" : "http://www.test.org", "span" : [6,13] },
{ "type" : "name", "subtype" : "person", "ref" : "http://www.allpeople.biz/Doe/John/123", "span" : [40,47] },
{ "type" : "title", "subtype" : "business", "ref" : "https://en.wikipedia.org/wiki/Vice_president#In_business", "span" : [75,88] },
{ "type" : "name", "subtype" : "product", "ref" : null, "span" : [93,120] }
]
}
I have found this to be useful in the cases where adding or propagating annotations happens without changing the main content. Or where changing the main content is hard do, if it is signed for example.
Best Regards,
Fredrik Estreen
From: Felix Sasaki [felix@sasakiatcf.com]
Sent: Saturday, October 17, 2015 6:04 AM
To: Estreen, Fredrik
Cc: XLIFF Main List
Subject: Re: [xliff] Internationalization and beyond related metadata for JSON - XLIFF perspective?
Hi Fredrik,
thanks a lot for your detailed reply. Esp. your thoughts on a data type are interesting since
had as one suggestion to have a dedicated data type - which you have good arguments against (the complexity).
Hi Felix,
I well aware of the issues caused by not having explicit language information and needing to fall back on heuristics for things like base direction. So I can see why there is a need for this. When it comes to JSON I personally prefer to have such features be
part of the document specification instead of trying to add XML like features, type systems and constructs to JSON. If the problem need "heavy-weight" solutions like that XML is probably a better choice. The switch from XML to JSON in large areas of the Web
space was to a large degree that XML became complicated as more and more standards and products started to make use of the more advanced parts of it. A lot of people wanted back to something simpler and smaller.
Looking at JSON-LD for example I think the outside of the content parts are ok, like having per-document/per-nesting level "@context" sub objects that augment the main data without in any way modifying it or complicating use of it by someone who do not care
about the meta-information. The inline "@value" objects on the other hand does not feel right to me in JSON as an example.
I have essentially used completely document specific solutions when doing JSON. If I need to be able to tag a section of text in some way, be it language or something else I have broken it up into objects that have properties for the needed metadata, used custom
span pointers for it or just added custom macros/codes in the text itself.
Interesting approach. I am not sure what you mean by custom span pointers, do you have an example?
Best,
Felix
Best Regards,
Fredrik Estreen
Hi all,
apologies for posting a similar message to the W3C ITS IG and this list; I am hoping to reach more people, obviously.
In the W3C i18n working group we recently had discussion about how to add language information or directionality information to a json string. I mentioned that a while ago in the W3C ITS IG esp. Yves had experimented with adding metadata like a translate flag
to json strings. Addison and Richard from the i18n WG have prepared some background reading on the json metadata topic and on plain text metadata in general, see here
https://www.w3.org/International/wiki/ContentMetadataJavaScriptDiscussion
http://r12a.github.io/docs/bidi-plain-text/index.html
I am interested in hearing what solutions people have in mind for the issue, and if there is interest in specifying a common one. Of course the planned work on an XLIFF object model may become relevant here.
Best,
Felix