Re: ISSUE-71: annotatorsRef [action-388]

I have no objections to restricting the use of annotatorsRef to 
mt-confidence, disambiguation and terminology.

Phil.





From:   Dave Lewis <dave.lewis@cs.tcd.ie>
To:     public-multilingualweb-lt-comments@w3.org, 
Cc:     Chase Tingley <chase@spartansoftwareinc.com>, 
kevin@spartanconsultinginc.com
Date:   24/01/2013 10:03
Subject:        Re: ISSUE-71:  annotatorsRef [action-388]



Hi Chase, All,
This comment promted some good discussion at the WG face-to-face meeting 
yesterday in Prague.

The concensus was:
1) As Yves indicated, the issue of potentially having many annotatorsRef 
attributes added at different times by different processors is not a major 
issue. It can be kept tidy fairly simply, and could be minimised through 
best practice such as adding the annotation as close in the nnode tree to 
the change as possible. As a result we don't see any change is needed 
here.

2) The interaction between annotatorsRef and the local stand off 
record/issue list in provenance and localisationQualityIssue data 
categories is definitly problem, and there isn't a clean obvious solution 
to managing this. 

However after a broad discussion on the requirements, it was agreed that 
using annotatorRef with these two data categories didn't bring us much, so 
we agreed to exclude these from use with annotatorsRef.

We also discussed this further however, and concluded similarly that there 
wasn't strong use cases for using annotatorRef with several other data 
categories. We proposed therefore to exclude all data categories from 
being used with annotatorsRef _except_ for the ones where it was already 
deemed as mandatory, i.e. mt-confidence, disambiguation and terminology.

So does anyone who was not at yesterday's face to face object to 
restricting annotatorsRef to be usable only with mt-confidence, 
disambiguation and terminology?

Chase, you comment has therefore been very helpful in refining the use of 
annotatorsRef - thank you for that. So can I ask whether you are satisfied 
with this response, so we can advance resolution of the issue?

Best Regards,,
Dave

On 23/01/2013 00:27, Dave Lewis wrote:
Hi Yves,
Comments below:

On 21/01/2013 14:33, Yves Savourel wrote:
Updating the annotatorsRef also puts a big burden on the implementer:
the easiest way to do it is to set it for the modified node, and then 
you can end-up with a document full of meaningless annotatorsRef 
(set on parents and immediately overridden).

I understand the issue, but do you have a solution in mind? Just trying 
to move the discussion forward.

I think the issue of possibly having a lot of useless annotatorsRef 
attributes dangling around after an update can be solved by a simple 
cleanup of the tree once in a while: you traverse the tree and remove any 
redundant attributes. So I think that part is not a big issue.


I agree. 

But do you think there needs to be some text in the ITS Tools Annotation 
section indicating that any processor that adds a data category should 
ensure that if annotatorRef attribute is present in the document referring 
to that data category, then it should ensure that the IRIs identifying the 
processor in all instances of the attribute should be accurate? Or should 
that be left to some non normative best practice, in which case the 
accuracy of the value of annotatorRef would essentially 'best effort', 
i.e. its value could be incorrect?

The most problematic part is what to do with LQI and Provenance, 
especially Provenance where annotatorsRef is required) when you have 
entries coming from different annotators on the same node. (question ii 
from chase & Kevin).

I don't have a solution for that.

Just to illustrate the problem:

[...]

It's probably not a huge problem with LQI, but I'm guessing it's more 
critical with Provenance where the annotator is an important part of the 
information.
Actually I don't think it is really critical for provenance, since it only 
indicates the processor that provided the provenance annotation, but that 
doesn't have the quality interpretation impact that the provenance 
information itself has, i.e. the agents involved in translation and 
translation revision.


The only solution I can think of is really not nice. It would be to add 
some attribute to <locQualityIssue> and <provenanceRecord> that tells the 
annotator and override any annotatorsRef value. But that is starting to 
make things really complicated. They are already quite difficult to 
understand.


Agreed, that's not very clean. You could add the annotatorRef attribute to 
those elements (the data category part of the value would obviously be 
redundant). We'd need to rephrase the wording of the ITS Tools Annotation 
section, specifically: 
"The attribute applies to the content of the element where it is declared 
(including its children elements) and to the attributes of that element." 
would need to be clarified.

However, another alternative, if we feel that annotatorsRef doesn't anyway 
add much to these two data categories, is to exclude them from the set 
covered by this feature. That would be simpler I think.

cheers,
Dave

cheers,
-yves








************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the sender immediately by e-mail.

www.vistatec.com
************************************************************