Web Annotation Working Group Teleconference

Agenda review

azaroth: review Berlin F2F agenda, Annotations and DOIs (dwhly), update on privacy review, outstanding issues, testing
... anything else?
... welcome Rebecca!

rebecaruiz: I'm here to listent to learn more about annotations
... my company provides services to publishers
... in Spain
... focused on academic publishing especially
... background in semantics, editing, etc.

ivan: FYI, had short chat with Richard Ishida
... internationalization had some comments which they will add to our Github soon
... additionally Felix Sasaki one of their members lives close to Berlin, would be good if he can join F2F for that part of the agenda
... invited them to participate

<azaroth> PROPOSED RESOLUTION: Minutes of the previous call are approved: https://www.w3.org/2016/04/29-annotation-minutes.html

ivan: made clear that we are trying to get to CR as soon after F2F as possible

<ivan> +1

+1

<azaroth> +1

<tbdinesh> +1

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

<ShaneM> +1

F2F Agenda

<rebecaruiz> +1

<azaroth> Link: https://www.w3.org/annotation/wiki/Meetings/F2F_Berlin_2016

azaroth: we made changes based on last week's discussion.
... Tuesday afternoon we will focus on issues (fewer observers Tuesday afternoon), also high priority for CR
... Wednesday am testing
... Wednesday pm discuss Notes and any other work we plan to get done
... does that seem better?

Annotations and DOIs

dwhly: early discussion
... basic summary for a long time now people have been asking hypothes.is if they can get a DOI for an annotation
... scholars want to be able to cite annotations
... DOIs signal annotation is a scholarly object, and a signal that annotation will be persistent
... hypothes.is has talked to CrossRef
... they were receptive
... but they noted that there is no current category of DOI that is a good match for annotations
... so they anticipate needing to add a new category
... getting a DOI might imply that an annotation is locked down (not editable), so who is allowed to request a DOI for an annotation
... might up the priority of annotation versioning
... wanted to highlight that this dicussion is underway, comments?
... promise to keep this commuinity informed.

shepazu: Is there an expectation that other documents with DOIs don't change

dwhly: my guess is that there is some committment by the publisher, but not certain how committment might be different for different categories

<Zakim> azaroth, you wanted to discuss versioning and canonical

ivan: it is a social expectation

azaroth: the intent is that the content identified by the DOI is stable in terms of the intellectual content
... typo fixes are common, but not to the sense of the content
... note, that urls that the DOIs resolve to change frequently

shepazu: wants to make sure we don't get over-rigorous about changes allowed, but probably beyond scope of this group

azaroth: wanted to talk about cannonical
... we allude to the canonical URI for an annotation

<azaroth> Link: https://www.w3.org/TR/annotation-model/#other-identities

azaroth: see Section 3.6.6 of the model
... would a DOI be appropriate as an annotation's canonical URI?
... or is there something else?

<bigbluehat> `via`?

dwhly: We would probably not use the DOI as our canonical URI

azaroth: which means we have nowhere in the model to talk about the DOI of an annotation

ivan: and to be precise the DOI itself is not a URI

<azaroth> Resolver is: http://dx.doi.org/...

ivan: there is a way to make it a doi by prepending the resolver

<shepazu> this can just be an extension to the model

ivan: so DOI probably could not be the canonical URI

azaroth: so question for discussion on the list, Do we need to provide a way to talk about 'other' identifiers in our model?

ivan: would like to try first to see if we can use DOI with resolver as canonical URI

shepazu: this seems like an extensibility (community) use case
... even if not part of the model, scholarly community could develop their own extension

Brief update regarding Privacy Horizontal Review

azaroth: let's discuss more on the list - its importance, whether it is just a community extension, etc.

<azaroth> link: https://github.com/w3c/web-annotation/issues/204

TimCole: Chairs and staff contacts joined the privacy interest group call, and talked about their thoughts on the model and protocol.
... Talked about plans to move to CR swiftly. Biggest topic, as expected, was the question about publishers could signal a preference for how or whether their resources are publicly annotated
... Can they say please don't annotate this, or please don't publish the annotations along with the rendering of the resource
... PING agreed that it's a broad issue with implications beyond this WG, but suggested that after we get work on CR done, we could come back and have a broader discussion
... a rain check to talk about this in the summer
... otherwise very positive about the specs :)

ivan: We're cross-checking from a process point of view
... they made some formal comments, we agreed with some (and are in editors' hands) so from a CR point of view, we're okay
... privacy review happened, we followed what they wanted, and agreed that the third comment is a larger discussion

TimCole: Agreed on HTTPS, and talked about a note or some way for the WG to weigh in on preferences

ivan: An agreement that the outcome of that doesn't change the functionality of the specifications themselves

TimCole: That should be added to the issue

ivan: Yes, need to make it clear that's our understanding

rebecaruiz: Should make it clear in the issue

TimCole: We didn't think it was in scope for this group to enforce the preferences, but it would be good to signal them, such as via robots.txt
... the mechanism wouldn't be in the model, but a separate discussion with more participants

shepazu: I think that there's nothing for the model to do in this version, not that there's nothing that /could/ be specified
... Could use meta tags. Model could have a signal that page the annotation was made on doesn't want the annotation to appear. Just that we shouldn't do it in this version

TimCole: Yes, correct
... Sense that we need to talk with others with similar issues, particularly Social Web WG

Issues

azaroth: 3 issues
... 191, 206, 205/207
... starting with 206

<azaroth> link: https://github.com/w3c/web-annotation/issues/206

<ivan> Addison's advice-> https://github.com/w3c/web-annotation/issues/206#issuecomment-217146564

ivan: internationalization has weighed in on this issue

<ivan> "It is usually best to define offset in terms of Unicode code points."

azaroth: the advice is to define offset in terms of unicode code point
... seems like we should add an example based on this advice in the spec

<azaroth> PROPOSED RESOLUTION: We will clarify that character position is based on Unicode code points, per recommendation from i18n group

<ivan> +1

<azaroth> +1

+1

<ShaneM> +1

<tbdinesh> +1

<bigbluehat> +1

<rebecaruiz> +1

RESOLUTION: We will clarify that character position is based on Unicode code points, per recommendation from i18n group

<azaroth> Link: https://github.com/w3c/web-annotation/issues/191

azaroth: let's see if we can dispense with 191
... there is a bug in the current WD that led to confusion
... there are 2 ways of saying values
... there's oa:text and there's rdf:value
... can we simplify and have only 1 way

<azaroth> https://github.com/w3c/web-annotation/issues/191#issuecomment-202470464

azaroth: change would be that we would always use rdfs:value (value would be the json key)
... would finish the replacement of content-in-rdf draft
... allows urls that de-reference to text

<bigbluehat> I like this change :)

<tbdinesh> +1

azaroth: become editor_action to replace text with value and simplifies model spec

<azaroth> PROPOSED RESOLUTION: Remove oa:text and replace with rdfs:value, json key of 'value' ; rename bodyText to bodyValue

<azaroth> +1

azaroth: note bodyText becomes bodyValue

<ivan> +1

<bigbluehat> +1

+1

<tbdinesh> +1

RESOLUTION: Remove oa:text and replace with rdfs:value, json key of 'value' ; rename bodyText to bodyValue

ivan: note, that this issue started for a slightly differnt reason
... so SVG example should not have content type

azaroth: yes, will fix example

<azaroth> PROPOSED RESOLUTION: Remove format from SvgSelector (and CssSelector, CssStyle) ... each selector/stype MUST have one format only

+1

<azaroth> +1

<ivan> +1

<azaroth> link: https://www.w3.org/TR/annotation-model/#svg-selector

<rebecaruiz> +1

<bigbluehat> +1

<tbdinesh> +1

azaroth: this example is over specified... so proposals are to simplify

RESOLUTION: Remove format from SvgSelector (and CssSelector, CssStyle) ... each selector/stype MUST have one format only

<azaroth> PROPOSED RESOLUTION: Remove Content type from embedded Selectors, States, etc. If the resource has a value, then it's embedded. If it has a URI, it's to be dereferenced.

<azaroth> +1

<ivan> +1

+1

<tbdinesh> +1

RESOLUTION: Remove Content type from embedded Selectors, States, etc. If the resource has a value, then it's embedded. If it has a URI, it's to be dereferenced.

<azaroth> scribenick: azaroth

Testing

TimCole: Please look at URLs in the agenda
... in order to prepare for Berlin
... Have made a lot of progress

<ShaneM> https://github.com/Spec-Ops/web-platform-tests/tree/master/annotation-model

ShaneM: This URL is the pointer to the documentation about what we're doing. It's changing often as we refine things
... comments, issues etc are all welcome

TimCole: Thanks, good to have in the minutes and please double check it

<shepazu> +1

<TimCole> scribenick: TimCole

azaroth: the notion of a warning versus an error, can this be accommodated in the test framework

ShaneM: at this point the framework just understands pass / fail, but we can annotate assertions
... so testers can better understand warnings and the like

shepazu: discussion wasn't public, should have been

<bigbluehat> shepazu: please do! my time dried up...

shepazu: since no one else has committed to extracting features, shepazu volunteers

<bigbluehat> shepazu: are you just extracting MUSTs? or also crafting the JSON Schema bits?

azaroth: should we have one issue to which all can add assertions?

ShaneM: would be best in a format from which we can generate stub test files

shepazu: will put CSV in gitHub

<bigbluehat> TimCole: yep

<bigbluehat> that

TimCole: as part of testing we will generate lots of little schemas
... we may at some point want to bring these together into a single schema, but not yet.

<ivan> trackbot, end telcon