Minutes, 2016-03-11

Minutes of the meeting are at:

https://www.w3.org/2016/03/11-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

11 Mar 2016

   [2]Agenda

      [2] https://lists.w3.org/Archives/Public/public-annotation/2016Mar/0045.html

   See also: [3]IRC log

      [3] http://www.w3.org/2016/03/11-annotation-irc

Attendees

   Present
          Rob Sanderson (azaroth), Benjamin Young, Jacob Jett, Tim
          Cole, Dan Whaley, TB_Dinesh, Doug Schepers (shepazu),
          Ivan Herman, Ben De Meester (bdjmeest), Randall Leeds,
          Takeshi Kanai, Paolo Ciccarese, Davis Salisbury, Kyrce
          Swenson

   Regrets
          Frederick Hirsch

   Chair
          Rob Sanderson, Tim Cole

   Scribe
          Jacob

Contents

     * [4]Topics
         1. [5]Scribe selection, agenda, announcements?
         2. [6]next meeting time
         3. [7]Minutes approval
         4. [8]Issue: IRI / URI / URL
         5. [9]Issue 184
            https://github.com/w3c/web-annotation/issues/184
         6. [10]Conformance
            https://github.com/w3c/web-annotation/issues/165
         7. [11]Testing
     * [12]Summary of Action Items
     * [13]Summary of Resolutions
     __________________________________________________________

   <azaroth> trackbot, start meeting

   <trackbot> Meeting: Web Annotation Working Group Teleconference

   <trackbot> Date: 11 March 2016

Scribe selection, agenda, announcements?

next meeting time

   TimCole: us/canada time is going to be the same and europe 1
   hour earlier

   ivan: european time will be one hour earlier for the next two
   weeks
   ... not sure about how this affects Japane (maybe takeshi can
   say)

   <tbdinesh> we wil all be 1hr earlier.. which is not bad

   TimCole: everyone on the call is now aware, this is the plan
   for the next two weeks, will be noted in the next couple of
   agendas

   takeshi: no daylight saving time in japan, so will be starting
   at midnight until the fall. will be better (than 1 AM)

Minutes approval

   <TimCole>
   [14]https://www.w3.org/2016/03/04-annotation-minutes.html

     [14] https://www.w3.org/2016/03/04-annotation-minutes.html

   TimCole: any objections, corrections etc.?

   <TimCole> PROPOSED RESOLUTION: Minutes of the previous call are
   approved:
   [15]https://www.w3.org/2016/03/04-annotation-minutes.html

     [15] https://www.w3.org/2016/03/04-annotation-minutes.html

   <azaroth> +1

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

     [16] https://www.w3.org/2016/03/04-annotation-minutes.html

Issue: IRI / URI / URL

   TimCole: ivan you mentioned a concern about the next topic now,
   waiting for some feedback from the w3c

   ivan: feedback is 'yes, it's a mess', so for moving on let's
   proceed, can look again if the masses desire

   azaroth: proposal is that we should follow the specs we're
   building on

   <TimCole> [17]https://github.com/w3c/web-annotation/issues/183

     [17] https://github.com/w3c/web-annotation/issues/183

   azaroth: as takeshi notes json-ld and ttl use iri's
   ... the proposal is to use iri's, will put an explanation in
   the introduction(?) that explains what that means

   TimCole: is the concern that iri's require more escaping (of
   characters)

   azaroth: as ivan says it's a mess; in recent specs though uri
   is not really used, is usally url or (more recently) iri
   ... iri gives a nice algorithm to conform with unicode and
   transformation back to percent encoded form

   shepazu: the direction of other w3c specs in the future seems
   to be url
   ... shouldn't dwell on this but should have space to revisit on
   we move to CR and get feedback
   ... feedback may indicate that the decision needs to be
   revisited

   takeshi: found that each browser deals with urls differently
   ... will summarize the differences on github

   <azaroth> +1 to Takeshi :)

   takeshi: will need that information in the document

   <shepazu> +1 to takeshi

   <TimCole> PROPOSED RESOLUTION: Go with IRI, make necessary
   changes in docs, revisit when more information

   <azaroth> +1

   <tbdinesh> +1

   <tilgovi> +0

   <takeshi> +1

   <ivan> +1

   +1

   <PaoloCiccarese> +0

   TimCole: should we change to editorial for now or close

   azaroth: change to editorial

   <bigbluehat> +1

   <bjdmeest> +1

   RESOLUTION: Go with IRI, make necessary changes in docs,
   revisit when more information

Issue 184 [18]https://github.com/w3c/web-annotation/issues/184

     [18] https://github.com/w3c/web-annotation/issues/184

   TimCole: linking collections to target

   azaroth: this came up in another community using annotations
   ... if you have a collection of annotations that is a list,
   even if you have a queryable endpoint, it remains complex to
   find the targets in the collection
   ... suggested inclusion of a list of included targets
   ... would allow consumers the ability to decide if the
   collection is something they want to consume or skip over
   ... wanted to raise it since it came up in the IIIF community

   TimCole: reason to do is if this a common enough use case to be
   needed in the core

   PaoloCiccarese: can we add things to the collections?
   ... not sure who would use this right now

   azaroth: at the moment have extensions and vocab, so could add
   it as an example to the extensions doc

   TimCole: proposing a resolution calling this use case out as an
   example, can be revisited

   <TimCole> PROPOSED RESOLUTION: Add an informative note in
   extension section calling this use case as an example, if need
   be later would be revisited.

   <PaoloCiccarese> +1

   <azaroth> +1

   +1

   <davis_salisbury> +1

   <ivan> +1

   <takeshi> +1

   <Kyrce> +1

   RESOLUTION: Add an informative note in extension section
   calling this use case as an example, if need be later would be
   revisited.

   TimCole: last two discussions will probably take around 20
   minutes each

Conformance [19]https://github.com/w3c/web-annotation/issues/165

     [19] https://github.com/w3c/web-annotation/issues/165

   ivan: only started the conformance discussion from an editorial
   point of view
   ... two or three meetings ago, related to selectors, question
   came up as to whether every conformant implementation of the
   model is supposed to implement selectors or not
   ... easy from the spec point of view to say, must implement
   everything in the model, but not so easy in practice
   ... need to identify groups of features in the model and define
   conformance levels for each group
   ... for example two levels, basic and full, then decide what
   basic must implement
   ... a traditional approach to conformance
   ... the danger and complication is that this affects testing
   ... need separate tests fro each profile
   ... so defining and specifying them now is important

   TimCole: resource issue of who will identify and break the
   features into categories and then the testing

   shepazu: idea of profiles is not how modern specs work
   ... specs that are browser-facing do not use profiles
   ... tend to define a global spec and then extend with
   additional specs

   <bigbluehat> in JavaScript & HTML focused browser bits?

   shepazu: profiles not being done, might be done in other
   domains

   <bigbluehat> or also in document formats?

   shepazu: skeptical that profiles will be helpful, leads to
   incompatibility by design
   ... are we talking about a client that generates an annotation,
   a server that interprets an annotation, etc. -- conformance
   would be helpful and reasonable for behavior categories

   <bigbluehat> As long as a "level 1" client can consume a "level
   2" document without breaking, what's the issue?

   <bigbluehat> I can open HTML5 documents in Navigator 2.0 and
   still read it ^_^

   TimCole: so more about if/how we break down features

   PaoloCiccarese: there are core things that I have to implement
   and maybe some things that I don't need
   ... if I implement the basic level, then a la carte several
   optional ones
   ... is it better to have a basic core and then optional extra
   features that we'd be happy if everyone implemented

   <bigbluehat> no. it's just well designed :)

   shepazu: how we figure what needs to be in or out of the core
   can be based on implementations

   ivan: to be clear, not married to profiles idea, but the
   approach suggested by Paolo is even worse
   ... don't want to have to test across multiple browsers (like
   with html 5)

   ivan: defining what we expect from them as a behavior, if we
   don't want profiles, would be fine with a single core model

   azaroth: wanted to point out the profiles are being used in CSS

   PaoloCiccarese: not a new concept, have discussed this many,
   many times in the CG

   <azaroth> And also at the Santa Clara TPAC

   PaoloCiccarese: called extension it  and then not extensions,
   and went back and forth
   ... in our case we don't have a minimum bar, we just say this
   is the spec, and not everyone implements everything

   TimCole: recalling from the CG, not all implementors want to
   implement every selector and say that they implement some of
   the basic ones but not the more exotic ones

   <Zakim> shepazu, you wanted to address CSS

   PaoloCiccarese: something like this, was related to collections
   of selected and recall that the CG had multiple levels

   shepazu: regarding css, it's an older spec, started before
   modern practices took hold
   ... is also extremely large, is nearly impossible to implement
   every combination
   ... many of its issues are related to differences in platforms
   (e.g., mobiles, etc.)
   ... reason for css profiles are due to hardware considerations
   and not software related
   ... in the case of the json-ld that we have, think that
   breaking it down would undercut its implementation

   ivan: don't see a reason to cut the spec into sub-pieces
   ... propose we say that conformant implementations must
   implement what is there
   ... not so huge as to need a piecemeal approach
   ... will likely need other types of conformance criteria, e.g.,
   for server, client, etc. behaviors
   ... a different dimension

   shepazu: agree, should be separated according to class of agent
   rather than portion of model

   azaroth: so if have an annotation client that only works for
   images (e.g., flickr), does that implementation need to
   implement the css and text selectors to be conformant, or does
   it only need to implement the svg (and other image specific)
   selectors in order to conform

   shepazu: need to functionally break it down around what it is
   doing
   ... is the client generating annotations

   ivan: seems like the issues are around selectors
   ... doesn't seem like the basic model is at issue
   ... can have performance criteria based on the media types that
   the particular implementation handles
   ... e.g., only images and not other media types
   ... may mean that selectors x, y, z, are not relevant to the
   implementation
   ... need a way to describe that
   ... it becomes a dimension of conformance criteria
   ... similar to css in that the criteria are around specific
   media types
   ... whereas a general purpose client would need to implement
   everything

   azaroth: need to clarify section 4

   <TimCole> PROPOSED RESOLUTION: Conformance section will be
   boilerplate adding notes that conformance for selectors will
   depend on media types and for rest on class of agent (server,
   client, ...)

   ivan: think that we should be a little more precise than just
   notes

   <azaroth> +1 to Ivan

   ivan: have some well-defined lists or tables that e.g., say
   what selectors need to be implemented in relation to which
   media types

   <davis_salisbury> +1

   <ivan> Proposed Resolution: Conformance section will be defined
   by listing the required selector/states per media types for
   various classes of agents (server, client)

   <TimCole> +1

   <azaroth> +1

   <ivan> +1

   <bjdmeest> +1

   <PaoloCiccarese> +1

   <davis_salisbury> +1 again thanks

   +1

   <takeshi> +1

   <tbdinesh> +1

   <shepazu> 0

   RESOLUTION: Conformance section will be defined by listing the
   required selector/states per media types for various classes of
   agents (server, client)

   TimCole: should be able to change this to editorial
   ... will post a new issue so that those not on call will be
   able to think about this

   <shepazu> (I'm still concerned that this means we're begging
   for lack of interoperability)

   ivan: need a clear proposal about what these categories are
   ... leave issue as is, someone come up with a clear proposal
   moving forward

   TimCole: will leave open and wait for the editors to come back
   with more concrete text

   azaroth: or anyone else as well

Testing

   TimCole: need someone other than the spec writers to help or
   take lead on testing

   shepazu: will need another testing lead

   TimCole: any volunteers?
   ... what else are folks concerned about that need to be on
   upcoming agendas?

   ivan: when can we push out the next release of the document
   ... document must go through a bunch of horizontal reviews at
   w3c
   ... need feedback from other groups
   ... conformance doesn't seem very simple
   ... should we try to get the documents out quickly by leaving
   conformance open for now?

   azaroth: most of the remaining issues that aren't marked as
   postpone are either done or will be closed through call actions

   <shepazu> (conformance is the most important part of a spec…
   I'm confused what Ivan is suggesting)

   azaroth: should go ahead and try to push out the docs as soon
   as possible

   TimCole: only one I'm concerned about is issue #19 (Client
   can't determine if user has authorization to modify
   annotation)/#119 (How do we model "groups" in the Annotation
   model?)
   ... those are already marked as postpone
   ... do we need to resolve first?

   azaroth: those are both big, time-consuming questions

   TimCole: comfortable leaving those for later, how those get
   addressed may ultimately be controversial

   ivan: both issues have not discussed in many months (since like
   December)
   ... not sure that they will be properly closed
   ... need feedback from other groups
   ... good to have a document that says the technical design is
   done

   <azaroth> [20]http://w3c.github.io/web-annotation/vocab/wd/

     [20] http://w3c.github.io/web-annotation/vocab/wd/

   azaroth: should be able to get model, protocol, and vocab docs
   in order, however vocab docs only has a few diagrams so will
   remove the existing ones and add diagrams later
   ... will take them out for the near term publication and then
   put them in for CR

   ivan: should put in an editorial note rather than remove the
   existing diagrams

   azaroth: cfc via email to try and publish it by next Thursday?

   ivan: if possible, will be great
   ... but moratorium begins soon
   ... more comfortable to aim for publication in 3 weeks or so
   rather than next week

   TimCole: adjourn

Summary of Action Items

Summary of Resolutions

    1. [21]Minutes of the previous call are approved:
       https://www.w3.org/2016/03/04-annotation-minutes.html
    2. [22]Go with IRI, make necessary changes in docs, revisit
       when more information
    3. [23]Add an informative note in extension section calling
       this use case as an example, if need be later would be
       revisited.
    4. [24]Conformance section will be defined by listing the
       required selector/states per media types for various
       classes of agents (server, client)

   [End of minutes]
     __________________________________________________________


    Minutes formatted by David Booth's [25]scribe.perl version
    1.144 ([26]CVS log)
    $Date: 2016/03/11 17:13:33 $

     [25] http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm
     [26] http://dev.w3.org/cvsweb/2002/scribe/