Web Annotation Working Group Teleconference

19 Feb 2016

See also: IRC log


Ivan Herman, Frederick Hirsch, Rob Sandersion (azaroth), Benjamin Young (bigbluehat), Doug Schepers (shepazu), Paolo Ciccarese, Ben De Meester, TB_Dinesh, Takeshi Kanai, Dan Whaley, Nick Stenning,
Randall_Leeds, Tim Cole
bigbluehat, dwhly, azaroth


Scribe selection, agenda review, announcements?

<fjh> Agenda: https://lists.w3.org/Archives/Public/public-annotation/2016Feb/0120.html

<azaroth> Chair: Rob_Sanderson, Frederick_Hirsch

<azaroth> scribenick: bigbluehat

azaroth: are there any other issues for the agenda?

fjh: it might be good to review outstanding issues at the end of the call, to see what is left to resolve and where we are

azaroth: any announcements? face-to-face? etc?

dwhly: things are in place for the venue for the f2f, and were working on finishing off other remaining details
... we're working on getting hotel accommodation info also
... we'd love for folks to register for I Annotate soon

Minutes Approval

<azaroth> PROPOSED RESOLUTION: Minutes of the previous call are approved: https://www.w3.org/2016/02/12-annotation-minutes.html

<fjh> add me as chair if possible

RESOLUTION: Minutes of the previous call are approved: https://www.w3.org/2016/02/12-annotation-minutes.html

Outstanding Issue Review

<tbdinesh> persent+ tb_dinesh

<azaroth> https://github.com/w3c/web-annotation/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3Aeditor_action+-label%3Apostpone

<fjh> +1 to doing the review of issue status first

azaroth: if you follow that link you will see all the non-editor-action or postponed issues
... there are only 10 of them
... the range selector is splitting out #93

<fjh> so, after one more call we should have completed the model issues?

azaroth: from the bottom up
... #19 - agreement was to publish a new set of drafts and get feedback from the chair of the Security group
... so it's blocked until we get a new set of drafts out

<fjh> W3C Security Interest Group - https://www.w3.org/Security/wiki/IG

azaroth: #80 - JSON-LD frame is partly done
... there's a frame for annotations, but not for the lists of annotations
... #93 - multiple selectors. we're discussing later today
... if you have a group of selectors, is there a simpler way to do it than we currently have
... #95 - XPath Selector - new selector, can we use that on any media type? or just ones that say they support it?

fjh: what I'm trying to understand is what work is left or which ones are basically completed.
... it sounds like most or basically completed and just need some remaining discussion

azaroth: #102 - AS comparison - we need to make sure we're still lined up with their spec

fjh: I thought we were deferring #110

ivan: #110's on today's agenda

azaroth: #135 is the same as #93. if we solve #93, we solve #135
... #147 isn't a CR related issue
... #150 0-1 or 0-n string bodies is on todays agenda

<fjh> so we might resolve all the open model issues today, unless there are some that aren’t on the list

azaroth: #153 which tilgovi just added splits out Range from #95

fjh: there was an issue that was closed which folks wanted back open

azaroth: it's the language one
... #149


scribe: it's not about the body of the annotation, but about the meta data
... if you wanted to associate a label with the body, and want to state what language the label is in, then where do you put that?

fjh: do we need an open issue for that?

azaroth: I think it's out of scope

<azaroth> https://github.com/w3c/web-annotation/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3Aeditor_action

azaroth: now this list
... these are editor-action
... they're waiting on the editors to complete these
... I have most of today blocked out for the rest of them
... in terms of actual changes to the document--the pending ones are done (committed) the others are next
... the discussion the last couple weeks was to have this all wrapped up by the middle of march
... for getting all of our open issues resolved
... that would put us in good stead for implementations, testing, etc.
... to get through CR

<fjh> Walking through the issues was helpful, thank you.

azaroth: one very brief thing I want to raise about extension
... for example, if adding a new namespace to a serialization is important
... such as the label of the language of the body
... then it might be required to add a second context
... we say it must be a string and it must be the annotation context
... so extension at the annotation level is not possible

https://github.com/w3c/web-annotation/issues/150: 0-1 or 0-n string bodies

issue #79 there wasn't any consensus around the # of string which could be used

scribe: so at the moment it says 0-1
... so the question is should it be changed to 0-n

azaroth: i believe the body text property is only there to make the annotations as simple as possible

<fjh> eg: bigbluehat: +1 etc

azaroth: so as soon as you get away from that, then the appropriate way to do it is with body resources
... you'd use a resource per body

ivan: I don't know why an array of string is not allowed when you can have an array of bodies
... I'd like to keep it brief as it's not a major issue

azaroth: it came from the CSV group
... they wanted a completely fast structure
... as soon as you introduce an array, it's not flat

ivan: right. they don't want a complex object, when a string would serve the purpose

azaroth: your interpretation is they want strings. my interpretation is they want a single string.

nickstenn: it's a lot simpler to write a implementation that assumes if it sees this field it's a string
... you'd either have an implementation that is full RDF like
... or much simpler that assumes it's a string
... by allowing it for an array of strings, then the implementation become more complex.

PaoloCiccarese: while I understand ivan's point, why would I use multiple strings?
... so I'm not really sure. it's weird to have the 1 constraint, it does make the implementations simpler.
... I'm almost neutral as I'll never probably use this.

ivan: I would like to make a proposal and drive this to a close
... but I would caution that we're opening up something with nickstenn's comment
... about the implementation testing and obligations of clients
... there is already the need to test for a single body vs. multiple bodies
... this is similar, just for textual bodies

<nickstenn> for me the crucial point is that the proposed resolution doesn't make anything impossible

azaroth: I think that ivan's comment is a nice framing

<nickstenn> if you want multiple textual bodies, you use multiple bodies

azaroth: the baseline requirement is that you support this minimum requirement--and not the regular body structure
... if you support the regular body structure, then you don't really need the simple bodyText property

ivan: we implemented bodyText for the users
... my understanding was that a conformant implementation has to do both.
... we need to have a discussion about what is a conformant implementation

azaroth: I'll take an issue to raise the conformance issue

nickstenn: we did discuss, but I think drop the idea of conformance levels

<PaoloCiccarese> +1

nickstenn: if the only conforming implementation is one that does all the things, then we're limiting the likelihood of implementations

<fjh> +1

<azaroth> PROPOSAL: Use the current 0-1 strings for bodyText, and disallow arrays of strings

nickstenn: realistically, as client-side in the browser, implementing a full RDF stack, supporting multiple body types is not realistic for an initial implementation

<tbdinesh> +1

<takeshi> +1

<nickstenn> +1

<fjh> +1

<azaroth> +1

<ivan> -1

<PaoloCiccarese> +1

<davis_salisbury> +0


<bjdmeest> +0

<ivan> for the records: my -1 is not an objection

<scribe> scribenick: dwhly

RESOLUTION: Use the current 0-1 strings for bodyText, and disallow arrays of strings

https://github.com/w3c/web-annotation/issues/93: Multiple Selectors

azaroth: 135 was exactly same issue
... there's a lot of discussion on this one
... selectors should be able to be chained, for instance fragment + xpath selectors
... there are implementations, hypothesis, queensland, etc. this is not a new thing

<azaroth> https://github.com/w3c/web-annotation/issues/93#issuecomment-173398909

azaroth: there are three use cases
... 1) refine fragment selector w/ text selector
... 2) two alternative selectors
... 3) mixing the two
... there was discussion around whether it was valuable or not

ivan: initially there was a proposal by rob
... within a selector you can have subselectors and so on, which encode the series of things you want to do
... sounded straightforward, but there was annother proposal
... to encode the same information by hugo
... don't know how to characterize it
... was coined as the "inverse model", started w/ selectors, ended w/ resource

<azaroth> https://github.com/w3c/web-annotation/issues/93#issuecomment-173962602

ivan: origins in functional programming
... debate ensued, matter of taste

<ivan> https://github.com/w3c/web-annotation/issues/93#issuecomment-174291171

ivan: jacob supplied some examples, i formatted them, seemed unrealistic
... debate ended by discussion around practicality, intuitive

<ivan> https://github.com/w3c/web-annotation/issues/93#issuecomment-175080258

ivan: one thing may tip the balance, related to discussion we may have today
... based on my desire to have selectors expressed as a fragment identifier
... for usages that require a URL
... that can be done simply w/ proposal of rob, impossible w/ hugos
... balance tips in favor of original proposal
... about 3 weeks ago the discussion died out
... we need to decide between rob's original or hugos

azaroth: the distinction is that the original to take broadest first and refine, hugos is to start /w most specific and broaden

ivan: becomes more complex w/ more specific examples

azaroth: the comment from ivan, formatted made it much easier to see
... what do people think?

PaoloCiccarese: question ... [missed it]
... in the case that i do a text quote
... and now I want to have references in the document
... that could be a ref to the position or the occurrence
... where would we expect that information to go
... the 2nd proposal is combining position and text quote
... and they are supposed to be alternative
... doesn't stop me from using them in combination
... use case 1 in combination
... use case 2 is one or the other
... use case 3 is a combo

nickstenn: are we trying to combine the algorithm into the data model
... when hypothesis fails to use a selector, that we can check such as a text selector
... that selector doesn't become discarded, may become the start point for a fuzzy search
... any hierarchy is perhaps too much.

PaoloCiccarese: when are two selector really alternatives
... i might still have two completely different selectors
... for exactly thes same reason that nick said
... if i have a number even if its fuzzy its still what it is
... doesn't imply i can't still look at them and make sense
... in between the two approaches, i like this one

shepazu: i'm sympathetic to nick
... on one hand we need to balance notion of interoperability w/ innovation tricky in standards
... don't think there's a prob data model having an order
... but perhaps it shouldn't dictate
... it's a set of data and the UA treats it as appropriate

<nickstenn> does anyone have a concrete example of where more selector structure is necessary?

shepazu: don't think we should dictate what the UA does

ivan: i'm completely lost by this line of argument
... we have selectors which are refinements
... not an algorithm
... not a choice between xml or html
... simply a refinement of selectors

shepazu: when you're making a list you're doing for a reason

ivan: there yes, we can say if its a list or a set, but that's not what we're talking about... it's a series of refinements
... i select something w/ a selector and then subselect

azaroth: so i'm sympathic w/ nick, it is an algorithm a simple one
... we have already accepted the use case for this
... the issue is whether we stick with what we have or make it simpler
... i have listed to doug's argument about innovation
... doesn't say you have to implement the algorithm.
... if you can interpret differently, do so

... new selectors are ok too

azaroth: no impact on innovation

<shepazu> (I think we're saying mostly the same thing on that point, actually)

nickstenn: you'll be shocked to know that i vote for the simplest thing
... i'm not sure i understand the use case, annotations have targets, selectors identify them
... what do subselectors do?

azaroth: let me quickly try to illustrate, epub is a zip file
... has a URI, html docusments
... in order to accurately select ... need to say, here is a URI, then an HTML file, then a selector

so, either we have an epub specific selector, or we have more generic general purpose ones

<nickstenn> or you have two selectors next to one another?

<azaroth> scribenick: azaroth

nickstenn: Needs more discussion

ivan: Yes

PaoloCiccarese: Okay with subselector, I see the epub use case. Wondering how it compares to scope
... Was using that to say this image in this html document
... slightly different but similar

shepazu: Saying contradictory things. This is how we selected this thing in the document. Describing an algorithm that you first do one thing, then the next.
... If not prescribing UA behavior, that's fine. If describing the order in which the selections were made, okay. But need to be clear what restrictions we're putting on UAs
... sounds increasingly like a set of instructions
... UA that makes the selection and the one that interprets it

<fjh> why is it bad to define a method for selection refinement that is easy to express, like a unix pipe

<fjh> what is the summary of the concern with the proposal?

shepazu: restriction on the one that makes it

fjh: Don't understand the concern, as to whether its wrong to include at all, or whether there's a more generic way


<fjh> if we express the concern clearly it may resolve easily


<ivan> trackbot, end telcon

Summary of Action Items

Summary of Resolutions

  1. Minutes of the previous call are approved: https://www.w3.org/2016/02/12-annotation-minutes.html
  2. Use the current 0-1 strings for bodyText, and disallow arrays of strings
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.144 (CVS log)
$Date: 2016/02/19 17:22:13 $