W3C home > Mailing lists > Public > public-multilingualweb-lt-comments@w3.org > January 2013

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

From: Chase Tingley <chase@spartansoftwareinc.com>
Date: Fri, 25 Jan 2013 10:40:29 -0800
Message-ID: <CAHPP-oE31F5Hf7wvOD=G0gVXRD3=HJmbgaUtsX8X=QisjzJdfg@mail.gmail.com>
To: Dave Lewis <dave.lewis@cs.tcd.ie>
Cc: public-multilingualweb-lt-comments@w3.org, kevin@spartanconsultinginc.com
Hi Dave,

Thanks for the response, I think this is a satisfactory resolution.

ct

On Thu, Jan 24, 2013 at 2:02 AM, Dave Lewis <dave.lewis@cs.tcd.ie> wrote:

>  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
>
>
>
>
>
>
>
>
Received on Friday, 25 January 2013 18:41:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 25 January 2013 18:41:21 GMT