Re: [ISSUE-34] Problem with mandatory attributes for quality

2012/8/7 Phil Ritchie <philr@vistatec.ie>

> I would see a requirement to support multiple annotations per element but
> only independent ones. That is, Arle's second example would seem required
> as it allows multiple, independent agents to add markup. For the first
> example, the parent entity seems redundant.
>
> Felix, what would prohibit the application of CSS/DOM processing to the
> multiple records?
>

The complexity of writing adequate CSS selectors. How would you write a CSS
selector that matches
<meta its-loc-quality-profile="XYZ:xyz.com/fake" />
with
its-loc-quality-code="XYZ:wrong_name"
?

Felix


>
> Phil.
>
>
>
>
>
> From:        Felix Sasaki <fsasaki@w3.org>
> To:        Arle Lommel <arle.lommel@dfki.de>,
> Cc:        Multilingual Web LT Public List <
> public-multilingualweb-lt@w3.org>
> Date:        07/08/2012 15:05
> Subject:        Re: [ISSUE-34] Problem with mandatory attributes for
> quality
> ------------------------------
>
>
>
> Hi Arle, all,
>
> as Yves has pointed out in a separate mail, inline markup has its limits.
> But is there a need to have "multiple quality records" inline? No matter
> how you represent the multiple records, you won't be able to apply the CSS
> styling to it anymore, or any other dom based processing in the browser.
>
> So I would propose to leave the inline proposal as is, with Yves'
> suggestions at
> *
> http://lists.w3.org/Archives/Public/public-multilingualweb-lt/2012Aug/0107.html
> *<http://lists.w3.org/Archives/Public/public-multilingualweb-lt/2012Aug/0107.html>
> and leave further discussions to the standoff / reference scenario. The
> main point is that we align the metadata available inline and offline, but
> having the multiple quality records just offline sounds reasonable to me.
>
> (Btw., a conversion to NIF might be another solution to the offline
> scenario, but I won't go to far here ...)
>
> Best,
>
> Felix
>
> 2012/8/7 Arle Lommel <*arle.lommel@dfki.de* <arle.lommel@dfki.de>>
> Going further, I am not sure what it would mean, however, if a
> locQualityScore value were declared inside the context of another one.
> Under out normal precedence rules it would be as if the "outer" one did not
> exist, but it could be that someone it expressing partial scores (e.g., the
> overall score is 85, but this <div> has a score of 98 and that <div> is a
> 42. In this case it is *not * like translate where the meaning is clear:
> a translate="yes" bit nested in a translate="no" bit completely overrides
> the translation="no" intent. But here the semantics are not so clear. Maybe
> it would solve it to state that the attribute does NOT apply to daughter
> elements. It's clear that semantically it *does*, but syntactically, we
> cannot see this as normal inheritance if the value from the whole cannot be
> seen as applying to the parts
>
> And I see I contradicted myself. First I said that locQualityScore doesn't
> make sense going down to daughter elements, which is true in general, but
> at the same time it isn't true that if I have some structure like this:
>
> <div id="1" its-loc-quality-score="80">
> <div id="2" its-loc-quality-score="60">Some bad <span id="A"
> its-loc-quality-type="misspelling"
> its-loc-quality-code="ABC:SPELLING">kontint</span></div>
> <div id="3" its-loc-quality-score="100">Some good content</div>
> </div>
>
> that there is no relation between the daughters and the parent.
>
> Rather, there is a contributory (i.e., bottom-up) relationship at work
> here, not one of normal inheritance: the 80 applies to the whole, not to
> the constituent parts. The values for divs 2 and 3 *contribute *to the
> value of div 1.
>
> And going down further, the same applies, the value of 60 applies only to
> the div as a whole, not to any part of it. If anything "Some bad" would
> have a score of 100 and "kontint" might have a value of 0.
>
> On the other hand, it is not as if the value associated with divs 2 and 3
> completely replace the value of div 1. If they did there would be no text
> to which the value from div 1 applies, which clearly is not the case: it
> applies to all of the text in div 1, taken as an intact whole.
>
> The more I look at the score, the tougher it gets to unify with the other
> span-ish (as opposed to Spanish) attributes used to identify specific
> errors.
>
> LocQualityProfile is maybe a bit easier to unify with them, but what I'd
> really like to see is something like this:
>
> <html lang="en">
>    <head>
>       <meta charset="utf-8" />
>       <meta its-loc-quality-profile="XYZ:*xyz.com/fake*<http://xyz.com/fake>"
> />
>       <meta its-loc-quality-profile="PQR:*pqr.com/alsofake*<http://pqr.com/alsofake>"
> />
>       <title>Some junk in a document</title>
>    </head>
>    <body>
>       <p class="segment" id="s0001"><span
>           its-loc-quality-type="inconsistent-entities"
>           its-loc-quality-code="XYZ:wrong_name">Christian Bale</span>
>       (<span its-loc-quality-type="numbers"
>           its-loc-quality-code="PQR:numbers_do_not_match"
>           its-loc-quality-comment="Should be 1867">2067</span>–1934)
> conceived of an
>       instrument that could transmit its sound from a power plant for
> hundreds of miles
>       to listeners over telegraph wiring.</p>
>    </body>
> </html>
>
> Here the two quality profiles exist side by side and the prefix in
> loc-quality-code selects which one applies to which piece of content.
>
> So the question is if we can do this using the ITS inheritance model and
> scoping model or not. If we cannot than we run into having to redeclare the
> profile for each and every place we want to use the category.
>
> -Arle
>
>
>
> --
> Felix Sasaki
> DFKI / W3C Fellow
>
>
> ************************************************************
> 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
> ************************************************************
>



-- 
Felix Sasaki
DFKI / W3C Fellow

Received on Tuesday, 7 August 2012 14:26:26 UTC