Web Annotation Working Group Teleconference

20 Jan 2016


See also: IRC log


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


<azaroth> PROPOSED RESOLUTION: Minutes of previous call are approved 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 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: 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


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> 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> 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. 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 scribe.perl version 1.144 (CVS log)
$Date: 2016/01/20 17:10:55 $