Re: Feedback on Open Data Management for Public Automated Translation Services

Thanks, Dave, for your immediate feedback. This discussion was in the 
context of the Linport initiative, and it is my opinion that a further 
exchange should be beneficial for both sides.
Would you mind sharing some insights about the falcon project with me; I 
guess "nomen est omen", right?
Cheers,
Jörg

Am 23.06.2014 14:22, schrieb Dave Lewis:
> Hi Jorge, Arle,
> Thanks for that great feedback. I'd very much agree that there are
> benefits for non-mt functions in the l10n value chain for improving open
> data management.
>
> We are looking at this in more detail at relevant implementations in the
> falcon project, but for advancing the modelling of open data
> vocabularies the LD4LT w3c community group is a good destination. We are
> already assisting with a linked data vocab for meta share and have been
> discussing similar for mqm with Arle and sts with Alan melby.
>
> Jorge, if you'd be interested in contributing please consider joining
> the ld4lt group, it's free and open.
>
> Cheers,
> Dave
>
> Sent from my iPhonei
>
> On 18 Jun 2014, at 16:02, Arle Lommel <arle.lommel@gmail.com
> <mailto:arle.lommel@gmail.com>> wrote:
>
>> Hi all,
>>
>> I forwarded the link to the document
>> (https://www.w3.org/International/its/wiki/Open_Data_Management_for_Public_Automated_Translation_Services)
>> to a couple of the core Linport people since Linport would fit into
>> this picture. I got the following back from Jörg Schütz, which he
>> asked me to forward on.
>>
>>     Hi Arle,
>>
>>     Thanks for providing this link. I was already thinking about how
>>     this initiative could contribute to the overall "Linport and
>>     related" discussions, and what kind of exchange could and should
>>     be possible.
>>
>>     My main concern with the W3C initiative, and the requirements
>>     document in particular, is that it is very much machine
>>     translation focused (even with a strong bias to SMT) which is
>>     certainly only one particular aspect within our current API (here,
>>     I use API is a generic metaphor for service interfaces)
>>     considerations.
>>
>>     In my view, "Public Automated Translation Services" can be more
>>     than just SMT and their associated data management (languages,
>>     lifecycles, processes, etc.) facilities. Since I'm not sure if
>>     this focus is because of the relation to CEF, but looking only at
>>     an MT infrastructure when talking about automated translation
>>     services would be to shortsighted (here I use "automated" in terms
>>     of processes). Think about, for example, terminology support to
>>     guide a particular translation request, or the assessment of a
>>     translation source content or a translation result for pre- and
>>     post-editing purposes, and you are confronted with data and
>>     interoperability challenges.
>>
>>     So, in priciple, the initiative might consider an overall
>>     framework for translations, and this then would directly lead to
>>     the Linport discussions. Obviously, all aspects mentioned in the
>>     document so far can be extended to a general framework for public
>>     translation services.
>>
>>     I would have liked very much to share my view in today's W3C
>>     online meeting but unfortunately 14:00 CEST is not a good time for
>>     me during an ordinary workday... Nevertheless, you may forward
>>     these lines to the W3C group working on the requirements document,
>>     and I would be happy to further explain my view.
>>
>>     Thanks again, and all the best,
>>
>>     Jörg
>>
>> I think Jörg’s comments point out that we should be clearer (both
>> internally and publicly) about the particular motivation for this
>> document and consider whether we want to talk in terms of a broader
>> infrastructure/ecosystem than just SMT. Since the CEF focus is
>> MT-centric, the present document reflects that, and maybe we want to
>> keep that particular focus, but we might also profitably discuss
>> whether it could be broadened a bit as well.
>>
>> Best,
>>
>> -Arle

Received on Friday, 27 June 2014 14:20:03 UTC