- From: Ivan Herman <ivan@w3.org>
- Date: Fri, 27 May 2016 18:11:21 +0200
- To: W3C Public Annotation List <public-annotation@w3.org>
- Message-Id: <90C2E2DB-075A-4133-82D9-9CEC6CA6D87C@w3.org>
Meeting minutes are here:
https://www.w3.org/2016/05/27-annotation-minutes.html
Textual version below
----
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
27 May 2016
[2]Agenda
[2] http://www.w3.org/mid/083301d1b69e$b062d490$11287db0$@illinois.edu
See also: [3]IRC log
[3] http://www.w3.org/2016/05/27-annotation-irc
Attendees
Present
Ben De Meester, Benjamin Young, Doug Schepers (shepazu),
Ivan Herman, Randall Leeds, Rob Sanderson (azaroth), Shane
McCarron (ShaneM), Takeshi Kanai, Tim Cole, Paolo
Ciccarese, Dan Whaley, csarven, Frederick Hirsch
Regrets
Chair
Tim, Rob
Scribe
bjdmeest
Contents
1. [4]Contents
1. [5]Issues
1. [6]Internationalization issues
2. [7]Issue #240
3. [8]issue 230
4. [9]issue 228
5. [10]issue 231
6. [11]Antoine's issue on reviewing and assessment
2. [12]Testing
2. [13]Summary of Action Items
3. [14]Summary of Resolutions
__________________________________________________________
<TimCole>
[15]https://mit.webex.com/mit/j.php?MTID=me422bef2c6690852d7d9a
2cf39f591b8
[15] https://mit.webex.com/mit/j.php?MTID=me422bef2c6690852d7d9a2cf39f591b8
scribenick
scribenick bjdmeest
<azaroth> scribenick: bjdmeest
TimCole: agenda: approve minutes of the F2F, talking about
issues, and talk about testing
<TimCole> PROPOSED RESOLUTION: Minutes of the F2F are approved:
[16]https://www.w3.org/2016/05/17-annotation-minutes.html,
[17]https://www.w3.org/2016/05/18-annotation-minutes.html
[16] https://www.w3.org/2016/05/17-annotation-minutes.html,
[17] https://www.w3.org/2016/05/18-annotation-minutes.html
<ivan> +1
TimCole: minutes are in two parts (two days)
... any concerns?
<TimCole> +1
+1
<bigbluehat> +1
<azaroth> +1
<ShaneM_> +1
RESOLUTION: Minutes of the F2F are approved:
[18]https://www.w3.org/2016/05/17-annotation-minutes.html,
[19]https://www.w3.org/2016/05/18-annotation-minutes.html
[18] https://www.w3.org/2016/05/17-annotation-minutes.html,
[19] https://www.w3.org/2016/05/18-annotation-minutes.html
Issues
Internationalization issues
<TimCole>
[20]https://github.com/w3c/web-annotation/issues?utf8=%E2%9C%93
&q=is%3Aopen+label%3Ai18n-review+-label%3Aeditor_action+-label%
3Apostpone
[20] https://github.com/w3c/web-annotation/issues?utf8=%E2%9C%93&q=is%3Aopen+label%3Ai18n-review+-label%3Aeditor_action+-label%3Apostpone
TimCole: Had good meeting with i18n WG yesterday
... We are down to one i18n issue open, #227
... about reference to text encoding
azaroth: #227 is also some editorial changes
(lowercase/uppercase naming)
... also, the exact normalization that should occur on the text
was not clear
... there was general consensus around code points rather than
code units
... i18n will provide some text for us to put in the spec
... regarding the actual normalization, there was no agreement
<ivan> Present?
azaroth: i18n will discuss, and get back to us by next week
... hopefully, we can easily accept and close
TimCole: Is there any concern?
... no? So we are in good shape on that issue
<TimCole>
[21]https://github.com/w3c/web-annotation/labels/i18n-review
[21] https://github.com/w3c/web-annotation/labels/i18n-review
TimCole: since we only talked to i18n 24h ago, see the link
above
... all issues have been moved to editorial action
ivan: most of the decided things were already discussed on the
mailing list
... mostly, we agreed on what was decided beforehand on the
call
azaroth: the only significant change was issue #213 (0..1
languages)
... we accepted to add an extra `processingLanguage` attribute
<azaroth> Accepted proposal:
[22]https://github.com/w3c/web-annotation/issues/213#issuecomme
nt-221098949
[22] https://github.com/w3c/web-annotation/issues/213#issuecomment-221098949
azaroth: That's the easiest way to escape the conundrum we had
ivan: unless Adisson comes with a change for #227 (and we have
to change a bit), we have closed all i18n issues
azaroth: the specs in github are updated, so they are waited to
be published, for the issues to be closed
<ShaneM> I am so sorry I raised that
ivan: this discussion about URI vs IRI vs ... keeps on going
... personally, at this point, keeping what we have, and maybe
add something like what Shane referred to (cfr RDFa doc), is
perfectly fine
<ShaneM> The RDFa text is fine - and I liked Richard's comment
TimCole: is that already an editor action?
azaroth: yes
ivan: so the resolution is that we keep IRI, but add the text
that Shane mentioned
<azaroth> PROPOSED RESOLUTION: Use IRI in Protocol with
explanation in the terminology section to explain the
distinction
<azaroth> +1
+1
<takeshi> +1
<ivan> +1
<ShaneM> +1
<TimCole> +1
<PaoloCiccarese> +1
RESOLUTION: Use IRI in Protocol with explanation in the
terminology section to explain the distinction
Issue #240
<TimCole>
[23]https://github.com/w3c/web-annotation/issues?utf8=%E2%9C%93
&q=is%3Aopen+-label%3Ai18n-review+-label%3Aeditor_action+-label
%3Apostpone
[23] https://github.com/w3c/web-annotation/issues?utf8=%E2%9C%93&q=is%3Aopen+-label%3Ai18n-review+-label%3Aeditor_action+-label%3Apostpone
TimCole: these are the remaining open issues (6)
azaroth: we can quickly agree with #240, #230, and #228
TimCole: so about #240
... pretty straightforward
<ivan> Issue #240, Remove purpose=commenting requirement from
bodyValue
<ivan> [24]https://github.com/w3c/web-annotation/issues/240
[24] https://github.com/w3c/web-annotation/issues/240
azaroth: at F2F and iAnnotate, we heard a lot about the purpose
'tagging' for textualBody
TimCole: so only for plain text string
<azaroth> Link:
[25]https://www.w3.org/TR/annotation-model/#string-body
[25] https://www.w3.org/TR/annotation-model/#string-body
TimCole: nothing can be on that, so we assigned a purpose
azaroth: specifically, we remove the fifth bullet from
[26]https://www.w3.org/TR/annotation-model/#string-body
[26] https://www.w3.org/TR/annotation-model/#string-body
<shepazu> s/Use IRI in Protocol with explanation in the
terminology section to explain the distinction/Use IRI in
Protocol with explanation in the terminology section to explain
the distinction, specifically this text from RDFa Core
[27]https://www.w3.org/TR/rdfa-syntax/#h-note1/
[27] https://www.w3.org/TR/rdfa-syntax/#h-note1/
<azaroth> PROPOSED RESOLUTION: Remove the requirement that
purpose of bodyValue be interpreted as commenting, as can use
the motivation of the Annotation without ambiguity
<ivan> +1
<azaroth> +1
<TimCole> +1
+1
<takeshi> +1
<ShaneM> +0
<bigbluehat> +1
<shepazu> +0
<PaoloCiccarese> +1
RESOLUTION: Remove the requirement that purpose of bodyValue be
interpreted as commenting, as can use the motivation of the
Annotation without ambiguity
ivan: ok, issue closed
issue 230
<TimCole> [28]https://github.com/w3c/web-annotation/issues/230
[28] https://github.com/w3c/web-annotation/issues/230
ivan: this is about reverting a resolution we made
<TimCole> this issues is about our namespace url
ivan: that resolution was based on the fact that W3C would
encourage HTTPS for voc-docs
... that was wrong, there has been an official declaration on
the mailing list
... so we don't have to change OA to WA, I propose to close
#230 without further action
... that official statement was very long discussed
... I will try and find the rationale
TimCole: so we stick with OA?
... from discussions I had, that seems a good idea
<azaroth> PROPOSED RESOLUTION: Maintain the use of .../ns/oa#
as the namespace, including the use of http and not https
<azaroth> +1
<ivan> -> Discussion on SemWeb mailing list, thread starting at
[29]https://lists.w3.org/Archives/Public/semantic-web/2016May/0
082.html
[29] https://lists.w3.org/Archives/Public/semantic-web/2016May/0082.html
<ivan> +1
<TimCole> +1
+1
<shepazu> -0
<ShaneM> +1
<bigbluehat> +1
<takeshi> +1
<ivan> -> see also
[30]https://www.w3.org/blog/2016/05/https-and-the-semantic-webl
inked-data/
[30] https://www.w3.org/blog/2016/05/https-and-the-semantic-weblinked-data/
<PaoloCiccarese> +1
RESOLUTION: Maintain the use of .../ns/oa# as the namespace,
including the use of http and not https
issue 228
<TimCole> [31]https://github.com/w3c/web-annotation/issues/228
[31] https://github.com/w3c/web-annotation/issues/228
azaroth: about testing of the protocol
... for several sections, there isn't any guidance on the
status codes, e.g., we didn't mention status code 200 for
successful actions
... this is just an issues about adding those codes
... these codes would make it a more useful spec
... if you don't support PUT, you should return 405
... however, if you don't support anything, you can just always
return 405, and have a compliant server
TimCole: so not a matter of compliance testing, but some
guidance on successful implementations
azaroth: yes
<azaroth> PROPOSED RESOLUTION: Add successful HTTP status codes
for the different operations in the protocol document
<azaroth> +1
<ivan> +1
+1
<TimCole> +1
<bigbluehat> +1
<tilgovi> +1
<PaoloCiccarese> +1
<takeshi> +1
<ShaneM> +1
RESOLUTION: Add successful HTTP status codes for the different
operations in the protocol document
issue 231
azaroth: a proposal of a new feature
<ivan> [32]https://github.com/w3c/web-annotation/issues/231
[32] https://github.com/w3c/web-annotation/issues/231
<TimCole> [33]https://github.com/w3c/web-annotation/issues/231
[33] https://github.com/w3c/web-annotation/issues/231
azaroth: we noticed that we didn't have any a11y information
... also, we looked at the IDPF use of AO
<ShaneM> note that I have appointed myself the A11Y liason for
this group.
azaroth: they added an a11y feature
... similar to our construct for audience
... [see the example in the issue]
... this adds a new cross domain key
... we adopt an existing pattern
ivan: IDPB and EPUB WG have a strong set of a11y requirements
... they work with schema.org to enlarge it for a11y
... this is a fairly stable and well managed set of terms on
schema.org, that we can rely on
TimCole: there are a lot of properties that might be useful for
a body or target
... in general, we said: if you have a vocabulary for this, use
it, but we don't put a lot of those in
... are there other vocabularies out there, that we can use?
azaroth: a11y is a core feature we should support (just as
i18n)
... another is rights/license
... they all seem pretty fundamental
<ivan> ivan- later
azaroth: if we can get all people to do one thing, we achieve
interoperability
shepazu: I strongly support this extra key
... this is not domain-specific, but functionality-specific
... if we don't include it, people will do it differently, or
people won't do it at all
... included, it is more probably it will be filled in
... also, there is the matter that annotations can be used
specifically for a11y
... we have already seen people annotating images and videos to
add text descriptions
... there is already a bunch of use cases that would benefit
from this
<tilgovi> Is this only about using annotation to add
accessibility features, or also about making annotations
accessible?
<azaroth> PROPOSED RESOLUTION: Add accessibilityFeature as a
property in the model for body and target resources
tilgovi: is this about adding a11y features to the target, or
adding a11y to the annotation themselves?
<ivan> +1
azaroth: what it does, is showing the existing a11y features of
the body or target
<TimCole> +1
+1
<ShaneM> +1
<shepazu> if don't have+1
<azaroth> And the proposed description:
[34]http://w3c.github.io/web-annotation/model/wd2/#accessibilit
y-of-content
[34] http://w3c.github.io/web-annotation/model/wd2/#accessibility-of-content
<tilgovi> +1
<shepazu> +1
RESOLUTION: Add accessibilityFeature as a property in the model
for body and target resources
Antoine's issue on reviewing and assessment
ivan: let's try and resolve the issue antoine raised via mail,
so the editors can have a reviewable version by the end of the
week
<ivan> Antoine's thread starts at
[35]https://lists.w3.org/Archives/Public/public-annotation/2016
May/0275.html
[35] https://lists.w3.org/Archives/Public/public-annotation/2016May/0275.html
azaroth: they want to use annotations to assess the quality of
something
... they don't want to subclass (that's where motivations are
for)
... currently, there is no good fitting existing motivation
... the reviewing description isn't fitting, because it is too
restrictive
... it currently implies rather being a comment, than an
assessment
... the proposal would be to generalize `reviewing` a bit, to
`assesing`
TimCole: when reading the thread, I thought to add a
motivation, you suggest replacing one
<shepazu> (I think this reveals the underlying problem with
motivations in that they are not generalized and don't derive
from functional aspects on behaviors)
ivan: the way it comes up, is that there is a document
published by another WG, for assessing quality on data
<csarven> (Sorry not in the call) If parts of assessment of the
quality is coming from a controlled vocabulary, oa:classifying
might help a little.
ivan: the other WG should define an extension, but the current
way the extension works, is that the spec says you SHOULD use
SKOS-ish things to use a more specific motivation of already
existing defined motivations
azaroth: this is an opportunity to fix the too narrow
description of the reviewing motivation
TimCole: so, maybe, we should change the SHOULD to MAY?
ivan: I think the SHOULD is fine (it's not a MUST)
<shepazu> (I appreciate the acknowledgment, but this is a
specific patch, not a systemic examination of criteria for
inclusion and broad applicability)
<azaroth> PROPOSED RESOLUTION: Rename "reviewing" to
"assessing" and broaden the description
ivan: in this case, we can solve this one
<ivan> +1
<TimCole> +0
<azaroth> +1
+1
<tilgovi> +0
<shepazu> (this seems like it's catering to a particular
scholarly community, not a real solution)
<shepazu> -0
<csarven> -0
<ShaneM> +1
<fjh> -0
azaroth: assessment is also about reviewing, about assessing
video bitrate, etc.
<shepazu> (correction noted, it's data not scholarly, but this
still feels arbitrary)
azaroth: some community that wants to do reviewing, can make a
skos:narrower `assessment`
<csarven> "assessing" sounds more specific than "reviewing"
azaroth: let's, by wednesday next week, make sure we have
agreement on this using github-issue tracker
<csarven> Generally, one reviews, then assesses
shepazu: I don't think it's worth delaying this
... instead, we go ahead, I don't see a change in the outcome
RESOLUTION: Rename "reviewing" to "assessing" and broaden the
description
azaroth: I will create the issue and describe the resolution
TimCole: we still have the HTML serialization as an
editor-action
ivan: we will have to look at the postponed at some time
... the HTML note is not for version 2, it is something we
intend to do
shepazu: I think it is correct to be an editor-action
Testing
ShaneM: infrastructure is in place
... I'm going to work with the WPT to get the base
infrastructure into the WPT
... once that's done, we'll start rolling tests in
shepazu: so, you are still committed to do the testing
framework, help with the initial tests, and then step away?
ShaneM: I won't be stepping away, but I don't plan to actually
author test, I'll show up whenever you want
<ivan> trackbot, end telcon
Summary of Action Items
Summary of Resolutions
1. [36]Minutes of the F2F are approved:
https://www.w3.org/2016/05/17-annotation-minutes.html,
https://www.w3.org/2016/05/18-annotation-minutes.html
2. [37]Use IRI in Protocol with explanation in the terminology
section to explain the distinction
3. [38]Remove the requirement that purpose of bodyValue be
interpreted as commenting, as can use the motivation of the
Annotation without ambiguity
4. [39]Maintain the use of .../ns/oa# as the namespace,
including the use of http and not https
5. [40]Add successful HTTP status codes for the different
operations in the protocol document
6. [41]Add accessibilityFeature as a property in the model for
body and target resources
7. [42]Rename "reviewing" to "assessing" and broaden the
description
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [43]scribe.perl version
1.144 ([44]CVS log)
$Date: 2016/05/27 16:08:09 $
[43] http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm
[44] http://dev.w3.org/cvsweb/2002/scribe/
Received on Friday, 27 May 2016 16:11:34 UTC