Re: issue-51 too many global rules

Hi Yves, all again ...

I thought about this again, esp. your argument "The capability to map
existing markup in other vocabulary that have the same functionality as the
ITS data categories".

For ITS 1.0, we specified best practices for such mappings, e.g. XHTML
http://www.w3.org/TR/2006/WD-xml-i18n-bp-20060518/#its-plus-xhtml10
http://www.w3.org/TR/2006/WD-xml-i18n-bp-20060518/EX-relating-its-plus-xhtml-1.xml

However, we only used data categories with small & fixed sets of values:
translate, term, dir, withintext.
Now, for the data categories we are discussing here, mostly there are open
value sets. Only QualityIssue has "qualityIssueType" and Disambiguation
"disambigType", but these are not really useful without other, "open" value
fields / attributes.

So it seems that mapping to existing vocabulares with global rules for
QualityIssue, Quality Precis, Disambiguation, mtConfidence, text analysis
annotation, provenance
only makes sense with pointer attributes, like here
http://www.w3.org/International/multilingualweb/lt/drafts/its20/its20.html#EX-locQualityIssue-global-2

So there may be the options:
1) remove the non pointer attributes, e.g. "locQualitIssueyComment", and
keep the pointer attributes, e.g. "locQualitIssueyCommentPointer"
2) keep everything as is
3) remove global rules completely.

Thoughts? At the end the question is: who would implement 1) or 2), or is
everybody happy with 3)?

Felix


2012/10/2 Felix Sasaki <fsasaki@w3.org>

> Hi Yves, all,
>
> good points. It seems that both aspects may be interrelated. You could
> resolve the "title" attribute issue by first converting HTML to XLIFF. Here
> you make use of the mtConfidence score at a "target" element (I think).
> Of course using ITS mtConfidence score at XLIFF "target" doesn't work
> (your second point). But maybe that's no important use case, only for
> locQualityIssueRef?
>
> About "we don't care" ... it seems that the main format for adding this
> metadata is XLIFF. So there is no need to have an XPath based mechanism to
> accomodate many formats, but a mapping between ITS metadata to XLIFF. I
> table could do too ...
>
> Felix
>
>
> 2012/10/2 Yves Savourel <ysavourel@enlaso.com>
>
>> Hi Felix, all,****
>>
>> ** **
>>
>> That make sense for the information part: all the data categories of the
>> second list basically need to be specified locally to be truly useable.**
>> **
>>
>> ** **
>>
>> But it would also remove two capabilities:****
>>
>> ** **
>>
>> **-    **The capability to associate those data category with attribute
>> values. We all know it’s not recommended to have translatable attributes,
>> but then how do you associate mtConfidence with the HTML5 title attribute
>> for example? Maybe the answer is “you don’t”. I’m just pointing the
>> potential issue.****
>>
>> ** **
>>
>> **-    **The capability to map existing markup in other vocabulary that
>> have the same functionality as the ITS data categories. Granted: it’s
>> unlikely to be a real use case in many cases: I’d be surprised to see the
>> same semantics as Disambiguation anywhere else. But there is at least one
>> case where a pointer would be handy: the pointer for the attribute that
>> points to the standoff markup for Localization Quality Issue in XLIFF 2.0.
>> We cannot use its:locQualityIssuesRef because <mrk> doesn’t allow non-XLIFF
>> attributes. It means an ITS-only-aware tool would not be able to see to
>> associate a localization quality issue with the content it pertains to. But
>> maybe we don’t care.****
>>
>> ** **
>>
>> -yves****
>>
>> ** **
>>
>> ** **
>>
>> ** **
>>
>> ** **
>>
>> *From:* Felix Sasaki [mailto:fsasaki@w3.org]
>> *Sent:* Tuesday, October 02, 2012 5:57 AM
>> *To:* public-multilingualweb-lt@w3.org
>> *Subject:* issue-51 too many global rules****
>>
>> ** **
>>
>> Hi all,****
>>
>> ** **
>>
>> as an input to issue-51, to the "global rules" part. I went through the
>> new data categories. Below are some proposals. In the cases there the "main
>> function of global rules, to define stable information about a document
>> format" (adapted from Yves' mail), I propose to drop global rules.****
>>
>> ** **
>>
>> - Domain, LocaleFilter, external resource, target pointer, preserve
>> space, allowed characters, storage size, id value: keep global rules as is.
>> ****
>>
>> ** **
>>
>> - QualityIssue, Quality Precis, Disambiguation, mtConfidence, text
>> analysis annotation, provenance: drop global rules. It seems that rules
>> here don't fulfill the main function mentioned above. That is also related
>> to the aspect of adding a closed set of metadata values, like "yes" or "no"
>> for translate. That makes sense for a document format, e.g. "all code
>> elements are translatable". But it doesn't make sense for the six data
>> categories: they don't add a closed set but rather open sets of values,
>> e.g. mtConfidence score =0.5. These will probably not be specific to a
>> document format.****
>>
>> ** **
>>
>> Thoughts?****
>>
>> ** **
>>
>> Felix****
>>
>> ** **
>>
>> --
>> Felix Sasaki****
>>
>> DFKI / W3C Fellow****
>>
>> ** **
>>
>
>
>
> --
> Felix Sasaki
> DFKI / W3C Fellow
>
>


-- 
Felix Sasaki
DFKI / W3C Fellow