Re: ISSUE-71: annotatorsRef

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