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
>>
>>
>
>