Re: URGENT: bodyValue

I'm okay with moving it to an appendix, as that seems the easiest to
justify of the four options.  The argument against it is the weakest.

It does mean a new CR on vocab too, as it's normatively defined and there's
no use of it in other contexts, unlike Choice and Agents, or the classes
marked at-risk.

Rob


On Fri, Nov 11, 2016 at 10:41 AM, Cole, Timothy W <t-cole3@illinois.edu>
wrote:

> Apologies for missing this one ahead of today's call.  Not sure if I
> missed it by being fooled because it showed up in more than one annotation
> (albeit only 1 implementation), or if I just missed it because I prefer not
> to think about bodyValue.
>
> Regardless, my recommendation would be to treat it the same as you are
> treating Choice-Target and Creator-Target. I believe this would be
> consistent with the decision of the WG earlier today and we should not
> invent a new pattern in spite of the temptation some of us may have to do
> so for this particular key.
>
> So, move it to informative appendix or mark at risk for the CR extension -
> whichever it is you are doing for the other 2 features that do not yet have
> 2 implementations and are unlikely to get 2 next few weeks (in the latter
> case of marking it at risk, as you say, it will be moved before we enter PR
> unless another implementation turns up during the CR Extension).
>
> For me, the fact that there is one implementation (as there is for
> Creator-Target) argues against jettisoning bodyValue from the document
> altogether, as does the fact that the WG discussed at length and in the end
> decided to include it.
>
> Regarding Exit Criteria, I assume that today you are removing the exit
> criteria for Choice-Target and Creator-Target, and should do the same for
> bodyValue.
>
> If marked at risk or relocated to an informative appendix now, would we
> have the option to consider dropping bodyValue altogether when we do
> finally move into PR (personally, I'd rather not do so at that point in
> time, but just asking).
>
> Thanks,
>
> Tim Cole
>
>
>
>
>
>
> ------------------------------
> *From:* jgjett@gmail.com [jgjett@gmail.com] on behalf of Jacob Jett [
> jjett2@illinois.edu]
> *Sent:* Friday, November 11, 2016 12:12
> *To:* Web Annotation
> *Subject:* Re: URGENT: bodyValue
>
> I'm personally in favor of jettisoning it. However, if I understand
> correctly from today's call all four of the options you listed will cause
> some form of issue for exiting CR so...
>
> I'm not certain what we can do. Ivan?
>
> Regards,
>
> Jacob
>
>
> _____________________________________________________
> Jacob Jett
> Research Assistant
> Center for Informatics Research in Science and Scholarship
> School of Information Science
> University of Illinois at Urbana-Champaign
> 501 E. Daniel Street, MC-493, Champaign, IL 61820-6211 USA
> (217) 244-2164
> jjett2@illinois.edu
>
>
> On Fri, Nov 11, 2016 at 12:02 PM, Robert Sanderson <azaroth42@gmail.com>
> wrote:
>
>>
>> One of our exit criteria is:
>>
>>     The bodyValue property of an Annotation.
>>
>> However according to the report (http://td.spec-ops.io/test-re
>> sults/annotation-model/all.html
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__td.spec-2Dops.io_test-2Dresults_annotation-2Dmodel_all.html&d=DQMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=zjI0r-H6xRs5fYf2_jJkju6US9ijk0nLw4ns2nuwU2k&m=hWpKA6k6kL6R-zJULrRnnsHIkDHLL4O3FxqITgP9x_Q&s=5sUMaKzpEpcxswL_GxXUXMCUXRap4Xj4458dn-Zt8Xk&e=>),
>> we have only one implementation of bodyValue (EF).  It's 1:4 in the
>> annotation optionals section.
>>
>> I don't believe we'll get a second implementation of it, so do we:
>>
>> * Just remove the exit criterion, as it's an optional feature anyway
>>     -- But there's a lot of optional features that are still exit criteria
>> * Move the feature to an appendix, following Composite/List
>>     -- But it wasn't marked at risk like those classes
>> * Mark the feature at-risk and remove it before PR
>>     -- But we rejected this approach for the other features in the same
>> state;
>> * Remove the feature completely
>>     -- But this would be a big change without formal discussion
>>
>>
>> My preference hasn't changed, which would be to remove it completely.
>> That we don't have implementations that use it, and we do have
>> implementations that use TextualBody is evidence that the rationale for it
>> (TextualBody is too hard) is unjustified.
>>
>> Thoughts?
>>
>> Rob
>>
>> --
>> Rob Sanderson
>> Semantic Architect
>> The Getty Trust
>> Los Angeles, CA 90049
>>
>
>


-- 
Rob Sanderson
Semantic Architect
The Getty Trust
Los Angeles, CA 90049