- From: Ivan Herman <ivan@w3.org>
- Date: Fri, 6 May 2016 18:09:17 +0200
- To: W3C Public Annotation List <public-annotation@w3.org>
- Message-Id: <45618161-FD37-4064-B05F-10DF000BF6C7@w3.org>
Minutes are at:
https://www.w3.org/2016/05/06-annotation-minutes.html
Text version below
ivan
----
Ivan Herman, W3C
Digital Publishing Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704
[1]W3C
[1] http://www.w3.org/
Web Annotation Working Group Teleconference
06 May 2016
See also: [2]IRC log
[2] http://www.w3.org/2016/05/06-annotation-irc
Attendees
Present
Rob Sanderson (azaroth), Ivan herman, Rebeca Ruiz
(rebecaruiz), Doug Schepers (shepazu), Tim Cole, TB
Dinesh, Dan Whaley (dwhly), Shane McCarron
Regrets
Frederick Hirsch, Ben De Meester, Paolo Ciccarese
Chair
Tim_Cole, Rob_Sanderson
Scribe
TimCole, azaroth
Contents
* [3]Topics
1. [4]Agenda review
2. [5]F2F Agenda
3. [6]Annotations and DOIs
4. [7]Brief update regarding Privacy Horizontal Review
5. [8]Issues
6. [9]Testing
* [10]Summary of Action Items
* [11]Summary of Resolutions
__________________________________________________________
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:
[12]https://www.w3.org/2016/04/29-annotation-minutes.html
[12] 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:
[13]https://www.w3.org/2016/04/29-annotation-minutes.html
[13] https://www.w3.org/2016/04/29-annotation-minutes.html
<ShaneM> +1
F2F Agenda
<rebecaruiz> +1
<azaroth> Link:
[14]https://www.w3.org/annotation/wiki/Meetings/F2F_Berlin_2016
[14] 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:
[15]https://www.w3.org/TR/annotation-model/#other-identities
[15] 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: [16]http://dx.doi.org/...
[16] 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:
[17]https://github.com/w3c/web-annotation/issues/204
[17] 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:
[18]https://github.com/w3c/web-annotation/issues/206
[18] https://github.com/w3c/web-annotation/issues/206
<ivan> Addison's advice->
[19]https://github.com/w3c/web-annotation/issues/206#issuecomme
nt-217146564
[19] 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:
[20]https://github.com/w3c/web-annotation/issues/191
[20] 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>
[21]https://github.com/w3c/web-annotation/issues/191#issuecomme
nt-202470464
[21] 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:
[22]https://www.w3.org/TR/annotation-model/#svg-selector
[22] 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>
[23]https://github.com/Spec-Ops/web-platform-tests/tree/master/
annotation-model
[23] 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
Summary of Action Items
Summary of Resolutions
1. [24]Minutes of the previous call are approved:
https://www.w3.org/2016/04/29-annotation-minutes.html
2. [25]We will clarify that character position is based on
Unicode code points, per recommendation from i18n group
3. [26]Remove oa:text and replace with rdfs:value, json key of
'value' ; rename bodyText to bodyValue
4. [27]Remove format from SvgSelector (and CssSelector,
CssStyle) ... each selector/stype MUST have one format only
5. [28]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.
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [29]scribe.perl version
1.144 ([30]CVS log)
$Date: 2016/05/06 16:07:00 $
[29] http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm
[30] http://dev.w3.org/cvsweb/2002/scribe/
Received on Friday, 6 May 2016 16:09:27 UTC