RE: [ACTION-256]: Compile and circulate itsTool examples togehter with proposal text

Hi Dave. Felix, all,

 

For me Jirka’s example of last week (or yours in the draft file) make it clear that option c) is the simplest.

I think we just need to decide whether or not the IRI parameters are defined by ITS or not.

 

I don’t have an opinion on that.

 

cheers,

-ys

 

 

From: Dave Lewis [mailto:dave.lewis@cs.tcd.ie] 
Sent: Sunday, November 11, 2012 9:53 AM
To: Felix Sasaki
Cc: Yves Savourel; public-multilingualweb-lt@w3.org
Subject: Re: [ACTION-256]: Compile and circulate itsTool examples togehter with proposal text

 

Hi Felix, Yves, all,
So if I'm following the discussion correctly I think  we have got to the following position on its tools:
a) we don't think it would be feasible to agree a common element format for tools that would suite all data categories, so we want to specify just an IRI value
b) having an stand-off element, e.g. processInfo containing toolInfo element, that is pointed to by the IRI, but that we leave otherwise unspecified does not buy us much in terms of interoperability, but it does incur the complexity of supporting local elements in scripts for HTML
c) encoding values in the IRI would seem to suffer from the same concensus issues that defining an element would.

To help us to complete this, I've redrafted the text to:
- dropped any definition of an info element
- just contain an IRI value for each data category, but specify no mandatory ways to use it
- made the wording (hopefully) a bit clearer for the override behaviour
- revised examples to highlight different usages of the IRI

Note, that I left in the possibility of using its toolRef with non data category attributes, but I've left a note in there since I'm not sure still if this has remification for what we are saying about the extensibility of ITS - thoughts welcome.

Comments welcome,
Dave


On 08/11/2012 13:21, Felix Sasaki wrote:

 

2012/11/8 Dave Lewis <dave.lewis@cs.tcd.ie>

Hi Yves, all,
essentially your outline is right, except I don't think we've had a concensus on the inclusion of global rules here (as well as in other data categories, but lets do that elsewhere).

So to consider reasons got gloabl rules for mtConfidence score,
1) whether we need global for supporting pointer is blocked on the XLIFF mapping (here, I agree with Felix, that if XLIFF mapping is the only usecase for pointers, then specifying this in a separate mapping rather than via a generic feature in ITS would be better in terms of simplfying ITS)

2) whether we need global rules for convenience is I think is a "no", since in general, we need to specify a different confidence score for every segment so we are unlikely to define it for sets of nodes via rules

3) whether we need global rules to support annotation of attributes is still an issue as discussed at:
http://lists.w3.org/Archives/Public/public-multilingualweb-lt/2012Oct/0271.html

In Lyon, however, David expressed the view that this was important, given the common use of translatable strings in, for examples, img attributes. I spoke recently to Enda McDonnell, head of engineering at Alchemy Software (CAT tool vendor) who was also of the opinion that support for translatable attributes was an important use case.

So here is the revised Mtconfidence data category wording and examples - with global rules (but no pointers for now). Note, I've specifically used attribute examples for the global rules. I didn't immediately see similar examples so comments welcome on this usage.

Are we near concensus - barring the pointer/XLIFF mapping issue?


We need also to resolve the URI definition issue (if such a definition is needed) - see
http://lists.w3.org/Archives/Public/public-multilingualweb-lt/2012Nov/0064.html

But that is not specific to mtconfidenc but to toolinfo in general I guess.

Best,

Felix

 


cheers,
Dave 









On 07/11/2012 18:12, Yves Savourel wrote:

Hi all,

which can be in the same file or in external file,
you would encode everything into single URL:
its:toolsRef="MTConfidence|http://mymt.org/toolinfo?version=456 <http://mymt.org/toolinfo?version=456&value=FR-to-EN-General> &value=FR-to-EN-General"

I'm looking at the current draft for MT Confidence and I'm not sure I understand why mtConfidenceScore is not defined either in the global rule or as local attribute. But maybe that's a moot point.

My understanding is that now MT Confidence would have:

Global:

- a required selector
- a required mtConfidenceScore
- a required its:toolsRef

Local:

- a required mtConfidenceScore
- a required its:toolsRef

its:toolsRef would be defined separately, including what parameters it must use (version and value).

And in the MT confidence section we would just define what goes in value.


Is that what we all have in mind?

Thanks,
-yves



 




-- 
Felix Sasaki 

DFKI / W3C Fellow