See also: IRC log
<TimCole> 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: https://www.w3.org/2016/05/17-annotation-minutes.html, 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: https://www.w3.org/2016/05/17-annotation-minutes.html, https://www.w3.org/2016/05/18-annotation-minutes.html
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> 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: 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
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> 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: 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 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 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
<TimCole> 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 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 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
<TimCole> 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
azaroth: a proposal of a new feature
<ivan> https://github.com/w3c/web-annotation/issues/231
<TimCole> 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: 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
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 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
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