- From: Tadej Stajner <tadej.stajner@ijs.si>
- Date: Thu, 23 Aug 2012 12:58:33 +0200
- To: public-multilingualweb-lt@w3.org
- Message-ID: <50360CD9.8000202@ijs.si>
Hi,
following up on the idea of consolidating textAnalysisAnnotation with
something else, like qualityReviewAgent, or provenance: intuitively, it
should fit nicely, but I would point out that textAnalysisAnnotation
talks about other annotations in the document ('this
<its:disambiguation> was produced by that tool') , not the document's
content ('the quality of that translation is good'). In a sense, its
meta-metadata. Is this difference in targets an issue for consolidation?
-- Tadej
On 8/23/2012 9:41 AM, Felix Sasaki wrote:
> Hi Dave, we discussed this on the call during your absence. The
> general opinion was that the the information needed for mtconfidence,
> quality and disambiguation is very similar and very specific. I had a
> brief look at the drafts for the three data categories and came to
> that conclusion, hence the issue-42 (drafted before the call).
>
> The also discussed whether this would be a separate data category, or
> whether we need to interrelate data category. Instead of going this
> path the rough consensus was that it is OK if the three data
> categories convey the same information - we should just try to
> harmonize the description of aspects like score or tool
> identification. Hence my action-194 related to issue-42, to come up
> with such a harmonization proposal. I am not sure yet if I'll get to
> it before the call.
>
> Best,
>
> Felix
>
> Am Donnerstag, 23. August 2012 schrieb Dave Lewis :
>
> Felix,
> I've only now got to your post on ISSUE-42 :
> http://lists.w3.org/Archives/Public/public-multilingualweb-lt/2012Aug/0149.html
>
> I think with the combination of mtconfidence score and
> translationAgent I suggest below is suggesting pretty much the
> same thing, just arrived at via a different route. Was that the
> direction you were heading in?
>
> The translationReviewAgent could work similarly with quality, and
> we could add a sourceReviewAgent or terminologyReviewAgent, or
> generalise translationReviewAgent or qualityReviewAgent to address
> textAnalysisAnnotation.
>
> One point here is that as different data categories are separably
> conformant, will specifications of how they are used in
> combination essentially have to be non-normative, or would we need
> a distinct normative data category in combination section?
>
> cheers,
> Dave
>
> On 23/08/2012 01:56, Dave Lewis wrote:
>
> Yves, David,
> Apologies coming to this thread a bit late. You've already
> pointed out that the score needs to be mostly local, i.e. per
> segment as passed to an MT service, while the definition of
> providers/engine would be more likely global, i.e. the same
> engine would be used for most segments in a document. We also
> have distinct use cases where only the score is relevant or
> where the score and the service is needed. So it seems that
> two data categories would suite, one for score and one for
> identifying the engine.
>
> We do however already a way of identifying an MT service that
> has been used on a document or its segments, in the form of
> translationAgent (see call for concensus
> http://lists.w3.org/Archives/Public/public-multilingualweb-lt/2012Jul/0256.html).
>
> I propose therefore that translationAgent used in conjunction
> with an mtConfidence score data category that had just one
> score attribute would therefore cover the different use cases
> while also supporting the existing use cases outlined for
> translationAgent.
>
> Note translationAgent allows multiple agents to be specified,
> but doesn't concern itself with distinguishing the types of
> agent, e.g. provider/organisation from software/engine, though
> both are possible. The form of the ID or the result of
> dereferencing it is assumed to address this, given the lack of
> common namign schemes for organsiations or engines.
>
> I'd be happy anyway to include the example IDs from
> mtConfidence engine attribute into translationAgent - as these
> are sensible ideas, and something we could address more
> comprehensively as best practice next year.
>
> cheers,
> Dave
>
>
>
> On 09/08/2012 13:56, Yves Savourel wrote:
>
> The end user who does not understand this MUST NOT be
> exposed to values
> >coming from mixed engines/producers.
> >In other words it is OK to DISPLAY SCORE ONLY TO THE
> END USER
> >if you have ensured up the stream that they DO come
> from the same
> >producer AND engine.
> >Again not sure how to cut this with defaults, as the
> defaults would
> >collapse filtering.
>
> Again all this applies only when you have translations for
> different providers/engines for the same text. That only
> one part of the scenarios.
>
> In any case, the bottom line is that making a local
> attribute presence required or not based on whether a
> global one is present or not is not easily implementable.
> It could be defined in an linked rule file for example.
>
> What I think you really try to do is make sure a value is
> define for mtProducer and mtEngine. I don't agree that one
> is always need, but that is a different topic (as
> discussed above). But if we decide one is needed, we can
> just state that one must be define. It doesn't make sense
> to me to try to define how or where it should be defined:
> the inheritance takes care of that.
>
>
>
>
>
>
Received on Thursday, 23 August 2012 10:59:02 UTC