Web Annotation Working Group Teleconference

<tbdinesh_> Is the password changed?

<ivan> tbdinesh_: no

<TimCole> https://www.w3.org/TR/annotation-model/#candidate-recommendation-exit-criteria

<bigbluehat> scribenick: bigbluehat

<TimCole> PROPOSED RESOLUTION: Minutes of the previous call are approved: https://www.w3.org/2016/10/07-annotation-minutes.html

TimCole: any objections? no. Great!

RESOLUTION: Minutes of the previous call are approved: https://www.w3.org/2016/10/07-annotation-minutes.html

Issues

TimCole: azaroth got updates?

azaroth: there are 4 issues. All of which are I18N related
... these haven't yet been accepted or a proposal to fix hasn't been accepted

TimCole: do they all have proposals

azaroth: yes. numbers coming into the logs shortly

<azaroth> #342, #343, #345, #348

https://github.com/w3c/web-annotation/issues/342

https://github.com/w3c/web-annotation/issues/343

https://github.com/w3c/web-annotation/issues/345

https://github.com/w3c/web-annotation/issues/348

ivan: for 342, this isn't one the I18N group created
... so we can close this without the I18N sign-off

azaroth: right. let's see if we can close it now
... it's a request in a non-normative note that we should clarify when and where you use processing language and language
... since it would be non-normative, then I'm not sure it adds any value
... and we essentially say it's OK not to provide processingLanugage anyhow
... seems easy to close to me

TimCole: any discussion on this?
... I don't see a normative way to address their concern

<Jacob> +1 to close

<azaroth> PROPOSAL: Close #342 without a fix, as there's no value in a non normative note, and the information is already in the document in a slightly different form

<azaroth> +1

+1

<tbdinesh> +1

<ivan> +1

<PaoloC> +1

RESOLUTION: Close #342 without a fix, as there's no value in a non normative note, and the information is already in the document in a slightly different form

Issue 343

azaroth: should there be a relationship between language and processingLanguage?
... it doesn't really make since the RDF statement world
... and you might want to be more specific in processingLanguage than in language
... such as a spellchecker use case for English + English UK (for the spellchecker)
... there are reasons not to disallow it--and I added a scenario to the issue
... so I propose wontfix

TimCole: should we got back and ask?

azaroth: let's flip it. We close it, and if they object, we'll reopen it

ivan: I agree.

<azaroth> PROPOSED RESOLUTION: Close #343 as there are no use cases for requiring processingLanguage to be one of the languages, and at least one use case for when they would not be

<Jacob> +1

<ivan> +1

<azaroth> +1

<TimCole> +1

+1

<tbdinesh> I can object already

<PaoloC> +1

azaroth: so the issue is whether or not we require the `language` value to be included in `processingLanguage`
... there might be a reason to not include it, as your processingLanguage is a sub-set

https://www.w3.org/TR/annotation-model/#model-1

processingLanguage ^^

"The language to use for text processing algorithms such as line breaking, hyphenation, which font to use, and similar. "

TimCole: basically, you want to narrow or clarify the processing of the text via processingLanguage

<tbdinesh> +1

ivan: can you +1 then tbdinesh
... tnx.

RESOLUTION: Close #343 as there are no use cases for requiring processingLanguage to be one of the languages, and at least one use case for when they would not be

azaroth: the next one's a bit longer
... also Richard created this one

ivan: right, so we shouldn't close it without his feedback

Issue #345

azaroth: the issue seems to be that processingLanguage does not say that BCP47 is a SHOULD
... but it should be a SHOULD in my opinion

ivan: is this normative?

azaroth: it would only add a SHOULD

ivan: you may also want to call out to Richard that we want his yeah/nay on this one
... we conditionally accept it if Richard +1's it...basically

TimCole: any concerns from the folks on the call?
... it seems it really SHOULD have been there all along

azaroth: putting in the proposal

TimCole: well, we can't close it today

<azaroth> PROPOSAL: Add a SHOULD for BCP47 to processingLanguage (as an oversight), conditional on acceptance from i18n

<azaroth> +1

<Jacob> +1

azaroth: but we can have it ready for when we hear back from Richard

<tbdinesh> +1

+1

<TimCole> +1

<ivan> +1

RESOLUTION: Add a SHOULD for BCP47 to processingLanguage (as an oversight), conditional on acceptance from i18n

Issue 348

azaroth: there are two issues in this one
... one is that we take "auto" from HTML5--which is character-by-character order
... essentially I feel it's not our problem
... There was also a lot of discussion about Unicode
... that we should express direction related to Unicode
... but these properties are about external resources
... so we can't dictate Unicode for those resources
... for the inline bodies and such, they have to be UTF-8 because JSON
... so the plan is to propose that we cannot change the declarations related to external resources

TimCole: we still need a resolution for 348

<azaroth> PROPOSED RESOLUTION: Change the definition of textDirection as requested, leave the definitions of rtl, ltr and auto exactly as per HTML5, do not require unicode for external resources outside of our control

<ivan> +1

+1

<azaroth> +1

<TimCole> +1

<tbdinesh> +1

RESOLUTION: Change the definition of textDirection as requested, leave the definitions of rtl, ltr and auto exactly as per HTML5, do not require unicode for external resources outside of our control

azaroth: now it's just the editorial work

<ivan> current PR Issues: https://github.com/w3c/web-annotation/milestone/3

<ivan> https://github.com/w3c/web-annotation/issues/324 ?

ivan: sadly, azaroth we have one left

azaroth: ah yes. 324

https://github.com/w3c/web-annotation/issues/324

Issue 324

azaroth: we decided not to do our own media-type
... but instead to a profile for JSON-LD
... there is a registry for profiles: https://tools.ietf.org/rfc/rfc7284.txt
... so to be good citizens of the Web, we should register it

ivan: is this expected procedure?

TimCole: do we need to do this before we exit CR?

ivan: we can close it by changing the milestone
... it doesn't effect CR

<ivan> Draft transition request: https://github.com/w3c/web-annotation/blob/gh-pages/admin/PRTransitionAdmin/PRTransitionRequest.md

ivan: I have prepared this transition request

azaroth: I'll take first cut at the editor_actions this afternoon

ivan: thanks

Draft doc for exiting CR

<ivan> Draft transition request: https://github.com/w3c/web-annotation/blob/gh-pages/admin/PRTransitionAdmin/PRTransitionRequest.md

ivan: I have prepared this transition request

azaroth: I'll take first cut at the editor_actions this afternoon

ivan: we do have to need to decide editorially what we do with the "at risk" features
... we need to do something with the ones marked as "at risk" and we need to address the sort-of "at risk" terms from AS2

TimCole: what are our options?

ivan: we have to remove them

TimCole: there were some use cases...

ivan: sadly, it doesn't matter

TimCole: I don't think we've seen samples from PaoloC

<TimCole> https://www.w3.org/TR/annotation-model/#sets-of-bodies-and-targets

<tbdinesh> :)

<tbdinesh> I told Benjamin, i will sure have a follow up for the renarration case

ivan: sadly, we have to have code

bigbluehat: is there still a window to ship something?

ivan: there is a window
... I personally would like to send out a PR within 2 weeks

PaoloC: sadly, I'm not in place to contribute right now
... I'm really sorry about that

<scribe> scribenick: TimCole

azaroth: At risk List, Composite, Independents (in the model) and activity streams related item in Protocol

Paolo: am using Sets, but out of date

<azaroth> New issue for removing sets: https://github.com/w3c/web-annotation/issues/369

TimCole: Choice has not been implemented
... Agent has not been implemented on Body or Target

<ShaneM> yes I do

<bigbluehat> scribenick: bigbluehat

TimCole: there are a few testing bugs tripping up Hypothes.is
... they also use terms a bit differantly
... specifically RangeSelector

ivan: if it's not putting the feature at risk, then it doesn't need to be a blocker for us

TimCole: mostly I want to be sure we're not leaving anything behind
... or if there are situations where they're they only ones using a thing
... such as TextQuoteSelector

ivan: that's all fine, but if those features are implemented by 2 others
... for the purpose of a PR, then it's not a problem for us

TimCole: if they violate part of the spec, it's not our problem?

ivan: no, it's there concern, not ours.
... it doesn't effect us going to PR/TR
... here is where ShaneM has more experience than I do
... if there is a feature not implemented during CR then we have to remove it?

ShaneM: yes. or extend CR until it is implemented

ivan: right. our only reasonable choice is that we remove the feature

ShaneM: I think that's accurate
... or move it to an Appendix

ivan: oh. that sounds better

<Jacob> +1 for the appendix approach

ShaneM: I'd hate to loose the concept just because we didn't get there

ivan: no, that's great
... it's also good news for the At Risk features

ShaneM: now...i just said that...could you, ivan, verify that this is still an ok approach?

ivan: I will ask the director

ShaneM: bye all

azaroth: bye all

<ivan> trackbot, end telcon

<ivan> trackbot, stop telcon

This is scribe.perl Revision: 1.148  of Date: 2016/10/11 12:55:14  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/logsshortly/logs shortly/
Succeeded: s/...I don't see a normative way to close this/...I don't see a normative way to address their concern/
Succeeded: s/Yes please//
Succeeded: s/by/bye/
Succeeded: s/by/bye/
Found ScribeNick: bigbluehat
Found ScribeNick: TimCole
Found ScribeNick: bigbluehat
Inferring Scribes: bigbluehat, TimCole
Scribes: bigbluehat, TimCole
ScribeNicks: bigbluehat, TimCole
Default Present: Benjamin_Young, Jacob_Jett, ivan, Tim_Cole, TB_Dinesh, Paolo_Ciccarese
Present: Benjamin_Young Jacob_Jett ivan Tim_Cole TB_Dinesh Paolo_Ciccarese
Agenda: http://www.w3.org/mid/097301d23098$d9a3f950$8cebebf0$@illinois.edu

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 28 Oct 2016
Guessing minutes URL: http://www.w3.org/2016/10/28-annotation-minutes.html
People with action items: