Re: URGENT: bodyValue

Do we also remove Composite, List, Independents and bodyValue from the
JSON-LD context document and ontology?  These are, admittedly,
non-normative, but it seems strange to me to keep them when they're not
actually part of the model/vocabulary.

If we remove them, then their use would require a different namespace and
an extension context.  It also seems weird to have RFC normative statements
in informative appendices, so I've tried to at least lowercase them and
re-describe them as potential features rather than actual requirements.

My preference is to remove them, especially given we need a new CR for
vocab.

Rob


On Fri, Nov 11, 2016 at 10:50 AM, Robert Sanderson <azaroth42@gmail.com>
wrote:

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



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