Web Annotation Working Group Teleconference

Agenda Review, Scribe Selection, Announcements

fjh: getting started; will go through protocol doc and discuss where that is after the usual administratives (minutes approval etc.)
... then some open discussion; other topics from the group? announcements?

Minutes Approval

<fjh> proposed RESOLUTION: minutes from 8 April 2015 approved, see http://www.w3.org/2015/04/08-annotation-minutes.html

RESOLUTION: minutes from 8 April 2015 approved, see http://www.w3.org/2015/04/08-annotation-minutes.html

Protocol

<fjh> see http://w3c.github.io/web-annotation/protocol/wd/

Rob: will take questions as we discuss
... not many changes have been made, just fixed issues
... will walk through and discuss issues as they come up
... [in section 3]
... removed some of the focus on multiple containers as we are only worrying about one container
... annotation graph now within a single container, document discusses support for POST, GET (for description of container), & OPTIONS
... some additional requirements (carry over from previous version) come from the LPD spec
... target uri can be static and can be referenced
... LDP group doesn't mention requirement for ... [missed it] ... as it was mentioned elsewhere
... 3.1.2 container retrieval requirements
... must say what kind of container (LDP basic container)
... recommend adding a label so that if a user agent needs to show something to a human it has something to display
... fleshed out the large containers section; omit annotation uris, container size caps, & paging responses
... e.g., can set a header on the request that will omit the triples describing the container
... preferred method is to add pages to the response; LDP specifies three different ways for this but only one is useful to us, the maximum member count
... walking through the examples, ask for a container with no more than 2 annos
... client gets the first page, drops off the prefer header, and then pages through until it comes to canonical annotation forms
... has a different type, i.e., page and not container
... the page header links through the various pages, allowing the client to link back and forth among the pages, allowing for automated walking through the pages

Tim: understand the page return, what is the case for the container size caps; why do we need to support it?
... is it separate from the paging responses?

Rob: Size cap and paging are separate options, size cap lets one bypass the paging response altogether
... allows folks to decide which, could drop the size caps if it is not needed
... if no dynamic response is needed vis a vis paging, then could just link between the containers rather than the headers
... use the size cap to prevent additional annos to be added to full containers

Tim: should think about this, could use a platform that doesn't employ LDP at all for folks that don't want to use LDP

Ray: Could clarify by noting that the three strategies in the document are "strategies" by adding such text to the headings in the doc

Paolo: was imagining when one or the other was used; if want to browse the annos in the container, can usually use paging but if I want the latest annos then might not want to use pagination
... how is the criteria for the annos dictated?

Rob: container contains a list of annos; i.e. container contains anno1, contains anno2, etc.
... if there are only a certian number of annos that target a specific target uri, then we need a way to constrain the response so only the pertinent annos in the container are returned
... if we had some method for filtering / searching that would also service this use case but that section of the doc is TBD

Paolo: would expect to use a mechanism like this one where an ordering criteria could be added

Rob: use case: ordering the response

Paolo: response with unordered set [of annos] not useful for all use cases

fjh: under the impression that we would pick one of the methods to support

Ray: optional features a concern because they are a barricade to interoperability

<fjh> I think we will need filtering/search based on target domain, and/or target domain + partial path; will we ilmit the options, think we should, presume paging being a note not an issue

Ray: wondering if these are features of the protocol or more like strategies of how to employ the protocol?

<fjh> can still have normative language in protocol spec, but we should check if this works

Ray: are they user guides, if yes then should be broken out into a user doc along with all of the specs that users need to employ them

Rob: can add another normative segment that says that the container must be supported
... use case: want to see all of the annos in the container
... can make paging mandatory but is it too high of a barricade to entry / uptake?

<fjh> to clarify, is doug suggesting paging be in a different/later spec?

<fjh> I submit this hypothesis - if filtering is available, paging might not be necessary if we get the filtering right

Doug: Can we put it into a later doc, i.e., version 1 that everyone supports, version/level 2 that weren't sure were necessary for version 1, i.e., a formally iterative approach to spec development to garner a round of feedback to determine when things we think might be necessary are necessary

Rob: disagree that we should leave out things that are known to be required but are hard is a good strategy

<fjh> what would be error case if paging were not supported and there was no cap? large page?

Rob: can leave out things like paging to version 2

<RayD> I disagree with doug that optional features are a problem, for example a cap

Rob: will need paging regardless

Ray: disagree that mentioning these in the spec will cause any interop problems
... mention that paging / filtering can be solved by developing a protocol for SRU, can come up with a simple profile that will save some work

<RayD> http://www.loc.gov/standards/sru/

fjh: seems that if filtering is done correctly then maybe paging isn't necessary
... don't understand why it is necessary server side

Rob: imagine a large container full of lots of annos, would still need paging to go through the 10s of thousands of annos
... still need paging with filtering

Doug: to what extent are these docs meant to solve particular use cases and to what extent is the doc specifying features

Rob: paging a feature
... omit anno a feature and container size cap a developer use case

Tim: agree that options can be problematic for interoperability

<fjh> +1 to limiting optional features

Tim: but, some kind of way to deal with containers that get to big is a necessity for the protocol
... e.g., OAI-PMH faced this issue
... in that case as the repositories grew the clients that harvested metadata didn't, so there was a lag between implementation of features that aided with scaling up
... would like to see a single solution for this rather than three, would prefer paging to the others

Paolo: would prefer both containers and paging so that it is possible to just peek in the container
... ok with just having one solution as a start though
... e.g., text mining use case, produces tons of data, so paging is very helpful to manage the data

Rob: proposal: remove the container size cap, and require both omit anno uris and paging

Paolo: if I only want 10 annos, on page 1, and there are other pages but the server still gives back multiple pages and so need to get 'page 1'
... another q, if search is implemented, generating perfect pagination details might not be possible, because cannot always tell what the last page is going to be
... counters will not always reflect actual numbers, because they are imperfect

Rob: next would always have to be true, first would have to be known but last can be unknown
... can we drill into the optional features, should they be specified?
... answer will impact the documents

F2F Agenda

Ray: want to add something to agenda for next week?

<fjh> https://www.w3.org/annotation/wiki/Meetings/f2f/SF_Q1_2015

fjh: determining the best way to make use of the time; can work through issues that we have stuff for on the calls so should focus on more ambiguous things like robust anchoring, possibly protocol, fpwd (for same), etc
... possibly using a use case like foot notes
... may be an unconference type of meeting where various issues get worked through
... can get additional topics from Hypothes.is, Rob, Doug, Ivan, others, waiting for some feedback from list

<ivan> same here

fjh: would help to know ahead of time, what folks want to focus on so time can be allocated

<azaroth> Any proposals are welcome!

Ray: would like to know if there is interest in search requirements and an approach for it; may or may not be useful

<azaroth> +1

fjh: good topic, would be helpful and appropriate
... anything else for f2f agenda?

Adjourn