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