Re: URGENT: bodyValue

Do we completely remove these, or will they become non normative terms that people may use? If the latter I see advantages to keep them in the context file (maybe in a different namespace?). But I don't have very strong feelings about it I must admit...

Ivan

----
Ivan Herman
+31 641044153

(Written on my mobile. Excuses for brevity and frequent misspellings...)



> On 11 Nov 2016, at 20:14, Robert Sanderson <azaroth42@gmail.com> wrote:
> 
> 
> 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-results/annotation-model/all.html), 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