Re: ISSUE-71: annotatorsRef

For my Use Case the combination of Provenance and LQI data categories is 
capturing what I need: i.e. Quality Issue and who/what raised the issue.

I would support Dave's proposal to exclude Provenance and LQI from the 
list of data categories covered by annotatorsRef.

Phil.





From:   Dave Lewis <dave.lewis@cs.tcd.ie>
To:     public-multilingualweb-lt-comments@w3.org, 
Date:   23/01/2013 00:28
Subject:        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






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