See also: IRC log
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?
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
<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
<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