W3C home > Mailing lists > Public > public-annotation@w3.org > January 2016

Minutes of meeting, 2016-01-20

From: Ivan Herman <ivan@w3.org>
Date: Wed, 20 Jan 2016 18:14:28 +0100
Message-Id: <D0C03C56-3219-4C4A-A5CE-079484283287@w3.org>
To: W3C Public Annotation List <public-annotation@w3.org>
Meeting minutes are here:

https://www.w3.org/2016/01/20-annotation-minutes.html

Textual version below

   [1]W3C

      [1] http://www.w3.org/

              Web Annotation Working Group Teleconference

20 Jan 2016

   [2]Agenda

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

   See also: [3]IRC log

      [3] http://www.w3.org/2016/01/20-annotation-irc

Attendees

   Present
          Ivan Herman, Frederick Hirsch, Rob Sanderson (azaroth),
          Tim Cole, Benjamin Young, Jacob Jett, Doug Schepers
          (shepazu), Davis Salisbury, Paolo Ciccarese, Ben De
          Meester, Chris Birk, TB Dinesh, Takeshi Kanai

   Regrets
   Chair
          Rob Sanderson

   Scribe
          bjdmeest

Contents

     * [4]Topics
         1. [5]I Annotate & F2F
         2. [6]Call Time
         3. [7]Testing
         4. [8]Multiple Selectors
     * [9]Summary of Action Items
     * [10]Summary of Resolutions
     __________________________________________________________

   <azaroth> PROPOSED RESOLUTION: Minutes of previous call are
   approved
   [11]http://www.w3.org/2016/01/13-annotation-minutes.html

     [11] http://www.w3.org/2016/01/13-annotation-minutes.html

   azaroth: agenda will start with logistic issues, then about set
   of issues about lists, multiplicity, etc.
   ... what's not on the agenda: iAnnotate, and WG meeting prior
   to that
   ... second: the call time

   RESOLUTION: Minutes of previous call are approved
   [12]http://www.w3.org/2016/01/13-annotation-minutes.html

     [12] http://www.w3.org/2016/01/13-annotation-minutes.html

   azaroth: doug asks about HTML serialization
   ... to be on the agenda
   ... maybe that will be better kept for a later date? To have a
   big block of time for that?

I Annotate & F2F

   dwhly: We are identifying a venue, which allows us to fix a
   date
   ... I think we have a venue now
   ... Microsoft venue at ter linden street
   ... dates are 19 and 20th of May
   ... F2F could thus be 17th and 18th
   ... could happen at DFKI
   ... probability is high that it will be there
   ... If you need support for funding, send me a private note
   ... we generally try to support traveling
   ... We typically have a hack event after the event
   ... so this year, on Saturday after iAnnotate
   ... we are looking for venue suggestions
   ... for +- 40 people
   ... suggestions are mostly welcome

   ivan: Will Microsoft and/or DFKI give suggestions for hotels?
   Unter ter Linden is in the city centre

   dwhly: We will try to get some standard recommendations for the
   area

   ivan: It would be good for the group to be in the same hotel or
   area

   azaroth: How long would the meeting be before iAnnotate?

   ivan: On Tuesday morning, there is a conflicting meeting at
   DFKI
   ... Tuesday afternoon is possible, not full 2 days

   <fjh> my question - will the room actually be ready in the
   afternoon?

   azaroth: 1,5 day it is
   ... we talked about at least a half a day of a more open
   session
   ... the last half day, where non-WG members could participate
   ... I am in favor
   ... Should we start promoting that?

   fjh: Is it realistic that the afternoon meeting rooms will be
   ready?

   ivan: Georg confirmed yes
   ... DFKI is a little bit north of the city center, Unter ter
   Linden is in the city center

   <fjh> +1 to venue, 1.5 days

   <fjh> +1 to guests from iAnnotate

   ivan: I think the best way is we accept guests to the entire
   F2F meeting, they are guests, not decision making

   <fjh> big thanks to Dan and Hypothes.is for arranging iAnnotate
   and working with Web Annotation WG to coordinate

   <chrisbirk> +1

   azaroth: other remarks? Thanks Dan and Hypothes.is for
   arranging!

   <ivan> +1

   azaroth: [silence], no other remarks

Call Time

   <azaroth> Doodle: [13]http://doodle.com/poll/m25yrdi3fmne6src

     [13] http://doodle.com/poll/m25yrdi3fmne6src

   azaroth: frederic has an unresolvable conflict with this time
   ... doodle is in the minutes

   <fjh> contenders look like Tue 11am ET (no Doug), the current
   slot Wed 11am ET (no Frederick), and Fri at 11am ET (if need be
   for Doug)

   <fjh> I could participate at current time alternate weeks

   azaroth: so please fill out this poll the coming week

   TimCole: is it a possibility to alternate timings bi-weekly?
   ... to accommodate for asian members

   fjh: I have a conflict on alternate weeks, so synced, that
   would be a possibility

   azaroth: would it be a big advantage to have alternate timing
   every other week? Or is the current time easy enough?

   tbdinesh: it's ok for me

   Takeshi: it's currently 1am, but for me, it's ok

   azaroth: If we could find a better time for takeshi, that would
   be good, thanks for being here
   ... let's check the doodle poll, if there's no obvious winner,
   we can discuss
   ... alternate timings will not be easy, lot of miss calls
   ... so please fill out the poll

Testing

   azaroth: I propose to, instead of getting the discussion
   between Chris and Doug out of band, maybe you could discuss on
   the mailing list
   ... it would be good to have as many people in the discussion
   as possible

   chrisbirk: mailing list or github issue?

   azaroth: I think mailing list to begin with, and more granular
   things can go into github issues
   ... general discussion in the mailing list
   ... for next topics, we have lists-related issues, and HTML
   serialization
   ... given timing, we could go into part of the list issues, and
   a bit of HTML serialization
   ... to unblock other list issues

Multiple Selectors

   <azaroth> [14]https://github.com/w3c/web-annotation/issues/93

     [14] https://github.com/w3c/web-annotation/issues/93

   azaroth: this is issue 93
   ... came up at TPAC
   ... this is indicative to the academic nature of some WG
   members
   ... suggestion: instead of using compositions and lists of
   selectors, use subselectors
   ... advantage: it uses the structure of the JSON to convey
   order, instead of RDF:List
   ... it makes choice also quite easy, as multiple selectors
   becomes: you can do this OR that
   ... currently, it doesn't make sense to do multiple selectors

   ivan: so, this example merges two sub-issues?
   ... the first one is a refinement selector, the other is a
   choice?

   azaroth: the selector in the example is a list, you choose
   between the two, the first one has a refinement

   <Jacob> How do we indicate when one is expected to make a
   choice verses apply things one after the other?

   shepazu: there is no way of having an ordered list in rdf?

   azaroth: the traditional way of doing ordering in RDF is
   complex at the triple level, and can done in many ways in the
   JSON-LD level
   ... I believe the proposal is simpler both in JSON as in RDF
   perspective

   shepazu: from a pure JSON position, I don't think there is
   ordering in JSON
   ... So not only an issue for RDF
   ... I see two solutions: nesting
   ... but why 'subSelector' instead of just nesting extra
   'selector's?
   ... is that necessary to add a new type?

   azaroth: It needs to be a different key, because it is a
   different predicate in RDF
   ... the semantics would be very strange when we would reuse
   'selector'
   ... a different key makes it clearer that a second selector
   needs to be done

   shepazu: are there cases where you want to do more than 2
   things in a sequence?
   ... azaroth, and then you can use 'subselector' again
   ... I suggest not using camecase
   ... also, we could also use an attribute for ordering the
   selectors
   ... e.g., this is the first one, this is the second one, this
   is the third one, do them in this order

   azaroth: that makes it more difficult to reuse, but so is the
   current proposal
   ... If you have a choice between selectors, I don't think it
   would cope with that

   fjh: it seems to do the job for 80/20 cases
   ... seems pretty good
   ... about the states comment
   ... aren't states orthogonal?

   <azaroth> [15]https://github.com/w3c/web-annotation/issues/135

     [15] https://github.com/w3c/web-annotation/issues/135

   azaroth: the states issue is #35
   ... it is orthogonal, but if we agree on #93, we need the same
   for #135

   fjh: so the same pattern for both issues?

   azaroth: yes

   TimCole: this pattern of choice and sequence came out of the
   CG, because it could be reused for eg state
   ... but also for the target of an annotation
   ... two concerns: differentiate between array[choice] and
   array[sequence]
   ... I think we are in danger of complicating the model as a
   whole, to accommodate for a 20% use case
   ... we are getting further away from RDF
   ... it's not really a property, you need some community
   knowledge to know that you need to apply the selector, even
   further with the subselector
   ... I think it needs more discussion
   ... more consistent with RDF, easier for JSON-LD
   ... applying a selector to a resource creates a more specific
   resource, and then subselector creates an even more specific
   resource

   azaroth: the desire to simplify the Choice and List constructs
   is the underlying desire here
   ... @TimCole, could you draw up an alternative?

   TimCole: I'd like to suggest a couple weeks, where we could
   come with more examples in different serializations, and decide
   then
   ... discussion highlights that there is still a lot of
   uncertainty here
   ... happy to make some examples

   azaroth: let's start as comments on the current issue

   ivan: I find this proposed structure very intuitive
   ... this structure is exact what an implementation would do

   <fjh> +1 to ivan

   ivan: apply selector to the resource, then apply next selector
   on subselection
   ... it's much more intuitive than a list of any form
   ... For me, this is atm the most intuitive solution

   shepazu: I was just thinking: are there other possible
   solutions?
   ... nesting seems fine
   ... other examples would be great though
   ... I'd like to think about the problem more deeply
   ... but the nesting solution seems intuitive

   ivan: let's suppose we choose this proposal
   ... does that mean the whole current section about multiplicity
   goes away?

   azaroth: I don't think it goes away, it gets reframed
   ... we still have the question about multiple bodies and
   targets
   ... choice of CG was to apply the same structure to both
   ... complicating factor is the addition of annotation lists
   ... which we need from several angles
   ... protocol needs ordered list of annotations
   ... there is a desire fetching a list of annotations
   ... which should be discoverable
   ... we have order in different levels
   ... from my perspective, there is no single good answer
   ... we need to come up with a solution for each of those levels
   ... as consistent as possible, without making any of them
   arbitrarily complex

   shepazu: it will be useful to talk about the cases where
   multiplicity will be used
   ... my intuition is that there are different places with
   different needs
   ... so the one structure to rule them all seems implausible
   ... we shouldn't constrain the solution too much
   ... to accommodate all possible level

   <tilgovi> Four places we're talking about multilpicity: ordered
   lists, unordered lists, alternates, and refinements

   azaroth: timing-wise, let's push HTML serialization to the next
   call
   ... to have the big picture: who would like to take
   responsibility for the different sections?
   ... #93 handles multiplicity for selectors and states
   ... #50 is about lists of annotations
   ... multiple targets has also an issue, I think

   <TimCole> that would be helpful

   azaroth: somewhere in the next couple of weeks, I will write up
   the higher level view
   ... depending on the comments of the github issues

   ivan: this whole multiplicity issue is for the model and vocab
   document, right?
   ... let's remember we are in the finishing strech
   ... we shouldn't spend too much time on this issue

   azaroth: HTML serialization is for next week
   ... proposal for other selectors is welcome
   ... there are a lot of selector issues
   ... we shoudn't discuss multiplicity alone

   <fjh> regrets from me for next week (unfortunately)

   azaroth: so, adjourn?
   ... adjourn!

   <ivan> trackbot, end telcon

Summary of Action Items

Summary of Resolutions

    1. [16]Minutes of previous call are approved
       http://www.w3.org/2016/01/13-annotation-minutes.html

   [End of minutes]
     __________________________________________________________


    Minutes formatted by David Booth's [17]scribe.perl version
    1.144 ([18]CVS log)
    $Date: 2016/01/20 17:10:55 $

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




----
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





Received on Wednesday, 20 January 2016 17:14:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:43 UTC