RE: agenda+ for Wednesday (WG Draft about high level use cases (Re: [ISSUE-75] - Domain - 2.a. [ACTION-434]))

Thanks! Felix




Pablo Nieto Caride

Dpto. Técnico/I+D+i

Linguaserve Internacionalización de Servicios, S.A.

Tel.: +34 91 761 64 60 ext. 0422
Fax: +34 91 542 89 28 

E-mail:  <> <> 


«En cumplimiento con lo previsto con los artículos 21 y 22 de la Ley
34/2002, de 11 de julio, de Servicios de la Sociedad de Información y
Comercio Electrónico, le informamos que procederemos al archivo y
tratamiento de sus datos exclusivamente con fines de promoción de los
productos y servicios ofrecidos por LINGUASERVE INTERNACIONALIZACIÓN DE
SERVICIOS, S.A. En caso de que Vdes. no deseen que procedamos al archivo y
tratamiento de los datos proporcionados, o no deseen recibir comunicaciones
comerciales sobre los productos y servicios ofrecidos, comuníquenoslo a, y su petición será inmediatamente cumplida.»


"According to the provisions set forth in articles 21 and 22 of Law 34/2002
of July 11 regarding Information Society and eCommerce Services, we will
store and use your personal data with the sole purpose of marketing the
products and services offered by LINGUASERVE INTERNACIONALIZACIÓN DE
SERVICIOS, S.A. If you do not wish your personal data to be stored and
handled, or you do not wish to receive further information regarding
products and services offered by our company, please e-mail us to Your request will be processed immediately.”


De: Felix Sasaki [] 
Enviado el: martes, 05 de febrero de 2013 16:52
Asunto: agenda+ for Wednesday (WG Draft about high level use cases (Re:
[ISSUE-75] - Domain - 2.a. [ACTION-434]))


Hi all,

this is to resolve Pablo's comment on the wiki link.

Dave, I can't be on the Wednesday call, but could you discuss this topic:

as a w3c working draft (not a final document) before Rome"

With the aim to finally publish it as a "note" (= an informative best
practice document). Needed to for that would be by 18 February:

- a "clean up" of sections, so that they don't contain coments any more and
follow the style of
- useful links to tool demos or further info if available)
- sometimes re-naming and editing, e.g.
"text analysis annotation"? see issue-68

Per partner this would actually not be a lot of work: I assume 1-2 hours.
Dave, could you discuss whether people would be available to do that by 18
February? I would then take care of a short introduction. Conversion to a
working draft format will happen on the fly, see

proposal of the location of the draft and name:
"Metadata for the Multilingual Web - Use Cases and Implementations"



Am 05.02.13 16:17, schrieb Pablo Nieto Caride:

It also works for me, although as I think I mentioned before I don't know
whether to use links to the wiki is appropriate or not.


That works for me
From: Lieske, Christian []
Sent: Tuesday, February 05, 2013 5:35 AM
Subject: RE: [ISSUE-75] - Domain - 2.a. [ACTION-434]
I had an action item to re-write the note related to "domainMapping" in
"multi-engine" scenarios. Here is comes ...
Although the focus of ITS 2.0, and some of the usage scenarios addressed in
ITS 2.0 showcases (see
el_summary#ITS_2.0_Metadata:_Work-In-Context_Showcase) is on “single engine”
environments, ITS 2.0 - for example in the context of the "domain" data
category - can accommodate "workflow/multi engine" scenarios.
- A scenario involves Machine Translation (MT) engines A and B. The domain
labels used by engine A follow the naming scheme A_123, the one for engine B
follow the naming scheme B_456.
- A "domainMapping" like the following is in place: domainMapping="'sports
law' Legal, 'property law' Legal"
- Engine A maps 'Legal' to A_4711, Engine B maps 'Legal' to B_42.
Thus, ITS does not encode a process or workflow (like "Use MT engine A with
domain A_4711, and use MT engine B with domain A_42"). Rather, it encodes
information that can be used in workflows.
-----Original Message-----
From: Jörg Schütz []
Sent: Mittwoch, 30. Januar 2013 09:37
Subject: Re: [ISSUE-75] - Domain - 2.a. incl. 2.b. and 1.
Hi Felix and all,
Here is my suggestion for a note (native speakers please correct):
Bear in mind that ITS is first and foremost a powerful markup technology to
add metadata to (Web) content. In this sense, it is not a (direct) means to
support, or even drive process or workflow engines, although some of the
data categories like provenance, domain, domain mapping, etc. may induce
such a view. Since this ITS metadata enhances the content in a structured
way and in multiple forms, ITS consuming agents can employ that data to
effectively implement their usage or deployment scenarios within single
engine or single process environments as well as within multi-engine
environments such as "try MT engine A, then MT engine B, ..." (see also ITS
2.0 showcases at
It is, however, not possible to assign, say, a specific domain mapping
incarnation to a certain (process or workflow) instance because such an
assignment concerns the process side, and this is beyond the current ITS
metadata scope.
With this, we now have apparently reached consensus on 2.a., 2.b.
(already reviewed by Christian), and 1. (shepherd's view...)
[@Yves: 1. is independent of the domain mapping specs.]
Cheers -- Jörg
On Jan 29, 2013, at 18:15 (CET), Felix Sasaki wrote:

Hi Jan, all,
thanks a lot for the initial note, Christian, and for comments in this 
thread. It seems that Yves made clear that
“try MT engine A, then MT engine B”
may indeed work with the ITS domain mechanism - but there is a lot of 
white spaces including
“try MT engine A with domain ‘financials’, then try MT engine B with 
domain ‘healthcare’”
and layering of many other processing types. So maybe a final note 
could concentrate on these white spaces? Anybody volunteering to 
re-write the note?
Am 29.01.13 17:15, schrieb Jan Nelson:

I find it a reasonable practice to define what is not in scope as a 
part of any specification, though agree that clear statements of in 
scope features are crucial.
I am curious about how a multi-engine selection/validation process 
works.  Christian, you mentioned both TM services as well as MT 
engines.  I can see value to be able to call from a set of services 
depending on domain with fallback based on result quality scores.  
And you state that ITS 2.0 might be a single service scoped spec.
Yves, you believe that there is support for more than one MT engine 
as currently spec'd.  My interest in the white spaces between the two 
comments are when layering n-services of differing processing types, 
e.g., fuzzy matching TM services versus statistical MT engine results 
and how that plays out.  It seems very ambitious to me to provide 
scope for this, and yet having a system that is capable of providing 
the kinds of metadata needed to enable it would be a pretty powerful 
in terms of the potential to provide hi-fi results.
Maybe my comments are far out of scope, but the thread here caught my 
attention.  If this the case, I am happy to discuss it more offline, 
perhaps in Rome over a coffee.
From: Yves Savourel []
Sent: Tuesday, January 29, 2013 7:55 AM
Subject: RE: [ISSUE-75] - Domain - 2.a.
Hi Christian, all,
I’m always a bit uncomfortable with stating what a mechanism is NOT 
doing in a specification. It seems we should be able to define what 
it does do and that should be sufficient.
I would also argue that the scenario “try MT engine A, then MT engine 
B” can work perfectly well with what we have today. The specification 
provides domainMapping for some basic mappings that allow for example 
to point multiple keywords to a more common unique 'domain' label.
For example you have a mapping as this: domainMapping="'sports law'
Legal, 'property law' Legal"
and two MT engines: they each have a user-defined table that provide 
additional re-direction (they are even possibly pair specific: one 
maps 'Legal' to 'LEGAL_EN_PT' and the other maps 'Legal' to 
Using domainMapping for more than simple grouping is bound to have 
quick limitations:
a) what if you add a third MT engine? You have to edit every single 
rules document to add the new mapping?
b) how do you map to engine that are defined per pair?
IMO the mapping to the values used to slect the MT engine belongs to 
the process side, not the input.
From: Lieske, Christian []
Sent: Tuesday, January 29, 2013 8:11 AM
Subject: [ISSUE-75] - Domain - 2.a.
One of my comments related to “domain” (see
was the following:
2.a. Domain "systems" may not be harmonized across a processing chain.
A Translation Memory component may for example work with different 
domains than a Machine Translation system that is part of the same 
processing chain. Since ITS 2.0 "domain" currently does not allow to 
capture the information "This is for component X" these scenarios 
cannot be addressed.
During the face-to-face in Prague, we achieved the following status 
(see a note 
should explain that “domain” (and possibly other data categories) do 
not accommodate what could be called multi-engine scenario.
Here is my suggestion for a note …
The focus of ITS 2.0, and some of the usage scenarios addressed in 
2.0 showcases (see
is on “single engine” environments. Example: the Machine Translation
(MT) usage scenarios do not work along the lines of process chains 
such as “try MT engine A, then MT engine B”. Accordingly, ITS 2.0 has 
few provisions to support this kind of “multi-engine” environments 
which for example require domain-related information such as “try MT 
engine A with domain ‘financials’, then try MT engine B with domain 



Received on Tuesday, 5 February 2013 16:29:09 UTC