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

Re: issue-68 from an annotation representation point of view, with potential implications for annotatorsRef and standoff markup

From: Felix Sasaki <fsasaki@w3.org>
Date: Tue, 29 Jan 2013 15:38:32 +0100
Message-ID: <5107DEE8.8010300@w3.org>
To: public-multilingualweb-lt@w3.org
Am 29.01.13 10:56, schrieb Tadej Štajner:
> Hi, Felix, Phil,
> maybe 'tanRefs' was misleading. the intention was to point to an 
> its:textAnalysisAnnotations, element which could in turn contain 
> contain several its:textAnalysisAnnotation elements that all describe 
> the same fragment. 

Thanks for the clarification, Tadej - that makes things clearer to me.

I think it also means that we could - instead of "my" standoff proposal 
- have standoff markup for a joint terminology + disambiguation data 
category, to allow for both kinds of annotations to be represented for 
the same fragment. At Marcis: it would also mean - that's a different to 
my proposal - that annotations would not be hierarchical and they would 
not overlap, since they always - both in the inline and standoff case - 
are anchored at the same span of text.



> Is this valid usage of the its:textAnalysisAnnotations, or was it only 
> meant to be a container for the individual rules? I was looking at 
> this example for inspiration:
> http://www.w3.org/International/multilingualweb/lt/drafts/its20/examples/xml/EX-locQualityIssue-local-2.xml 
> Alternatively, having multiple values would also work equivalently, 
> then we could point to individual textAnalysisAnnotation statements.
> -- Tadej
> On 29. 01. 2013 10:41, Felix Sasaki wrote:
>> Thanks, Phil. Tadej, was the intention of its:tanRefs at
>> http://lists.w3.org/Archives/Public/public-multilingualweb-lt/2013Jan/0212.html 
>> to have several pointers, e.g. allow for
>> its:tanRefs="tan1 tan2 tan3"
>> or just one, that is only "tan1"?
>> Best,
>> Felx
>> Am 29.01.13 10:34, schrieb Phil Ritchie:
>>> All
>>> @Felix: "But while doing that a question on the LQI/Provenance
>>> implementers: is it a feature that you point to just one external 
>>> standoff
>>> unit, or an oversight, and it could it be several ones?"
>>> My current thinking is that stand-off stores many annotations for one
>>> segment. This is because if several segments are linked to one 
>>> stand-off
>>> block, then if one of those segments needs to have another unique issue
>>> registered against it, you have to copy the stand-off, add the unique
>>> annotation and change the reference id's so that the link is between 
>>> the
>>> segment with the additional annotation and the copied stand-off. 
>>> Complex.
>>> Another argument for pointing to a single stand-off is that although 
>>> the
>>> "classification" attributes of the markup might be identical (e.g.
>>> loc-quality-issue-type="style" loc-quality-issue-severity="75") each 
>>> may
>>> have a different loc-quality-issue-comment to highlight the specific 
>>> nature
>>> of the error.
>>> Hmm. The benefit of the id being on the segment/element and the idRefs
>>> being on the stand-off really comes into its own if you want to have
>>> multiple annotations across many data categories for the same
>>> segment/element.
>>> <span id="loaded">blah</span>
>>> <its:prov ref="loaded"...
>>> <its:locQualityIssues ref="loaded"...
>>> <its:textAnalysis ref="loaded"
>>> (on the train, I know this is not valid markup.)
>>> Phil
>>> On 28 Jan 2013, at 19:57, "Felix Sasaki" <fsasaki@w3.org> wrote:
>>>> But while doing that a question on the LQI/Provenance implementers: 
>>>> is it
>>> a feature that you point to just one external standoff unit, or an
>>> oversight, and it could it be several ones?
>>> ************************************************************
>>> 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
>>> ************************************************************
Received on Tuesday, 29 January 2013 14:38:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:32:00 UTC