I have some concerns about the similarity
attribute, until there is a openly acknowledged standard around matching
proximity, having that attribute does not make sense to me. What does it
mean when your tool say 75%? What happens if my tool does not acknowledge
the calculation to be agreeable? Note that I am not suggesting it is not
useful information but I think the cart is in front of the horse.
Based on an agreed upon matching standard,
I do not believe there will be a need for subType. Most of the information
specified by similarity would be sufficient enough for determining what
the subType would be.
From:
Ryan King <>
To:
Ryan King <>,
"Dr. David Filip" <>
Cc:
Shirley Coady <>,
Yves Savourel <>, ""
<>
Date:
12/15/2012 10:54 PM
Subject:
RE: [xliff]
1.2 to 2.0 Gaps and Proposals
Sent by:
<>
Further comments or discussion
J ?
From:
[
mailto:
]
On Behalf Of Ryan King
Sent: Tuesday, December 11, 2012 10:35 PM
To: Dr. David Filip
Cc: Shirley Coady; Yves Savourel;
Subject: RE: [xliff] 1.2 to 2.0 Gaps and Proposals
To be honest, I originally proposed concatenated
because I thought that was what we agreed on for subState at the f2f and
I wanted to follow suit…but maybe I misremembered that. I actually think
a separate attribute is better. It is cleaner as you say, and I don’t
think it is really a heavy requirement to ask user agents to drop the subtype
when the main type changes (or is deleted), which I agree is the correct
behavior.
Should we define any sub values in Xliff
such as “fuzzy” or “exact”? I would actually put “ice” here as well
and not in the main type attribute. I reference Wikipedia for my reasoning
J
http://en.wikipedia.org/wiki/Translation_memory
:
Retrieval
Several different types of matches can be retrieved from a TM.
Exact match
Exact matches appear when the match between
the current source segment and the stored one is a character by character
match. When translating a sentence, an exact match means the same sentence
has been translated before. Exact matches are also called "100 % matches".
In-Context Exact (ICE) match or Guaranteed
Match
An ICE match is an exact match that occurs
in exactly the same context, that is, the same location in a paragraph.
Context is often defined by the surrounding sentences and attributes such
as document file name, date, and permissions.
Fuzzy match
When the match is not exact, it is a "fuzzy"
match. Some systems assign percentages to these kinds of matches, in which
case a fuzzy match is greater than 0% and less than 100%. Those figures
are not comparable across systems unless the method of scoring is specified.
So now we would have something like this:
<match id=”1” similarity=”75.0” type=”tm” subtype=”xlf:fuzzy”>
<match id=”1” similarity=”99.0”
type=”tm” subtype=”ms:near-exact”>
<match id=”1” similarity=”100.0”
type=”tm” subtype=”xlf:exact”>
<match id=”1” similarity=”100.0”
type=”tm” subtype=”xlf:ice”>
Thanks,
ryan
From: Dr. David Filip [
mailto:
]
Sent: Tuesday, December 11, 2012 4:06 PM
To: Ryan King
Cc: Shirley Coady; Yves Savourel;
Subject: Re: [xliff] 1.2 to 2.0 Gaps and Proposals
I support adding private subtype
Pending issues:
- Freeze of the normative top level
list
- Mechnics of subtype, we should
be probably using the same mechanics consistently, i.e. either concatenated
or separate attributes. This is a spec wide issue
Separate seems cleaner, but concatenation
seems better for processing, subtype is automatically dropped when main
type changed, which seems desirable ??
Cheers
dF
Dr. David Filip
=======================
LRC
CNGL
LT-Web
CSIS
University of Limerick, Ireland
telephone: +353-6120-2781
cellphone: +353-86-0222-158
facsimile: +353-6120-2734
mailto:
On Tue, Dec 11, 2012 at 11:32 PM,
Ryan King <
>
wrote:
Thanks Yves and Shirley, while
we are discussing the correct list of match values, I'd like to know from
the list if we have consensus on adding a subtype for match.
Thanks,
ryan
