See also: IRC log
<trackbot> Date: 15 July 2015
<fjh> Agenda: https://lists.w3.org/Archives/Public/public-annotation/2015Jul/0105.html
<azaroth> scribenick: chrisbirk
<azaroth> scribe: Chris Birk
fjh: we have regrets from Rob, Frederick and Ivan on 29 July, Doug are you able to chair that call or should we cancel now?
shepazu: I can chair
azaroth: ok, thanks
<fjh> proposed RESOLUTION: Minutes from 8 July approved, http://www.w3.org/2015/07/08-annotation-minutes.html
RESOLUTION: Minutes from 8 July approved, http://www.w3.org/2015/07/08-annotation-minutes.html
<fjh> https://lists.w3.org/Archives/Public/public-annotation/2015Jul/0082.html
bigbluehat: I think it might be saner to come at smaller deliverables
<azaroth> +1
<bigbluehat> w3.org/annotation
bigbluehat: social call reaction had a tough time digesting entire chart
<shepazu> http://www.w3.org/annotation/diagrams/annotation-architecture.svg
<TimCole> This? http://www.w3.org/annotation/diagrams/annotation-architecture.svg
shepazu: never intended SVG to represent protocol or any part of the spec. is a conceptual overview
bigbluehat: address other parts of the chart and break out other deliverables
<fjh> ACTION: fjh to work on roadmap [recorded in http://www.w3.org/2015/07/15-annotation-minutes.html#action01]
<trackbot> Created ACTION-22 - Work on roadmap [on Frederick Hirsch - due 2015-07-22].
fjh: we have some of these separated on the list. Need to be more explicit
<fjh> would ilke to see us discuss containers on today's call, believe Tim Cole had some thoughts on that
azaroth: containers / musts triangle need some clarity on requirements
<fjh> https://lists.w3.org/Archives/Public/public-annotation/2015Jul/0141.html
azaroth: would like to add query search mechanism on top of "follow your nose" discovery
... replying to list in deeper detail
shepazu: is the architecture diagram causing problems?
bigbluehat: it's not causing any problems, but need to be more clear on what we're covering.
<fjh> need to annotate the architecture diagram
<azaroth> +1 to non-normative overview doc
<fjh> +1 to architecture note
bigbluehat: HTTP API and client-side api broken out into sub-deliverables
<Zakim> azaroth, you wanted to ask re read/write separation
azaroth: a web resource would have a link header to discover a feed of annotations. Not the only method of discovery
... I separate discovery from search. If it's not linked to from somewhere it's search instead of discovery
bigbluehat: need to make sure we are explicit about vocabulary
<azaroth> +1
<Jacob> So separating browsing ([serendipitous] discovery) from search ([investigative] discovery)?
<azaroth> Jacob: Yep
bigbluehat: I'll add some user stories.
<Jacob> Makes sense to me. We do this in dig libs all the time. +1
<azaroth> Jacob: Right :)
<fjh> ACTION: shepazu to write use case about feed for discovery [recorded in http://www.w3.org/2015/07/15-annotation-minutes.html#action02]
<trackbot> Created ACTION-23 - Write use case about feed for discovery [on Doug Schepers - due 2015-07-22].
<fjh> ACTION: bigbluehat to write user story about discovery [recorded in http://www.w3.org/2015/07/15-annotation-minutes.html#action03]
<trackbot> Created ACTION-24 - Write user story about discovery [on Benjamin Young - due 2015-07-22].
<TimCole> need a use case focusing on discovery by relation of a SpecificTarget to a Resourcd -- happy to do this use case if no one else is covering
<fjh> ACTION: azaroth to write user story about discovery [recorded in http://www.w3.org/2015/07/15-annotation-minutes.html#action04]
<trackbot> Created ACTION-25 - Write user story about discovery [on Robert Sanderson - due 2015-07-22].
<bigbluehat> +1 to fjh writing down all the things
<fjh> these actions are all from different perspectives even though same actions
bigbluehat: I can get mine written in a week
<fjh> all have plan to complete actions in week
<Zakim> azaroth, you wanted to ask read/write separation
<fjh> another item to be clear about
<TimCole> +1 for distinguishing between reading and writing
fjh: saving reading / writing for next discussion
<Zakim> tbdinesh, you wanted to ask if we should separate annotation service from annotation repo
tbdinesh: would it make sense to separate annotation repositories from services?
shepazu: what's the distinction between the two?
<Jacob> API vs database?
<fjh> rssagent, generate minutes
<azaroth> Service as automated user agent?
<fjh> aggregation service?
tbdinesh: hypothes.is example of a service. How do I allow access to my annotations?
<fjh> tbdinesh: service - enables annotations, then publishes somewhere
<fjh> s/dbdinish: service/bigbluehat: service/
<bigbluehat> +1 to tbdinesh's desire for clarity around service (enabler of annotation) and repository (storage of annotation)
<fjh> +1 to clarity around service etc
<Jacob> +1 to clarity
<Zakim> azaroth, you wanted to note fragments as well
TimCole: how to find annotations on a region of an image vs. the image in general
azaroth: if you want to find annotations on a uri, get all annotations on resource and annotations on part of the resource
<fjh> agree
<fjh> concern is that use cases cover different paths to finding annotations, e.g. url of image vs url of section of image etc
<bigbluehat> TimCole: azaroth: earlier work on discovery: https://www.w3.org/annotation/wiki/Resource_Annotation_Discovery
bigbluehat: let's not optimize away redundancy just yet
<TimCole> +1 http
shepazu: bring up rangefinder next week
... not ready to publish yet, need to complete algorithm
<fjh> benjamin email https://lists.w3.org/Archives/Public/public-annotation/2015Jul/0083.html
<bigbluehat> azaroth: essentially, we'd be using "just" HTTP with only calling out the required Link headers, media types, etc.
<bigbluehat> azaroth: vs. more tightly defining what must be done in various cases.
azaroth: need to make a decision about exactly where on the spectrum of "use existing" to "completely defining everything" we want to be
<Zakim> fjh, you wanted to ask about constraining
<Jacob> fjh: I think that's right
fjh: core issue is that if we constrain it more, it's breaking interop
bigbluehat: erik saying adding MUSTs constrains HTTP and puts more work on developers.
<Zakim> azaroth, you wanted to assert it's not entirely true :)
azaroth: if we want to specify a system for creating annotation systems, and you say POST is optional, you cannot create annotations within spec
... tradeoff between what the standard says and what implementers are going to do.
shepazu: may not be able to resolve this within this group
<fjh> we have previously discussed asking the TAG, after updating the draft so it is as clear as possible
shepazu: get Mark Nottingham involved
bigbluehat: I'll try to characterize the two positions with help from azaroth
<fjh> ACTION: bigbluehat to characterize issue related to HTTP profiling and options to go forward [recorded in http://www.w3.org/2015/07/15-annotation-minutes.html#action05]
<trackbot> Created ACTION-26 - Characterize issue related to http profiling and options to go forward [on Benjamin Young - due 2015-07-22].
TimCole: would we require implementers to understand all specs involved?
bigbluehat: entire spec just for publishing own annotations is probably too much overhead.
... should be a place to point people who have annotations and want to publish that don't want to implement writeability
<TimCole> +1
chrisbirk: +1
<Jacob> +1
<tbdinesh> +1
<shepazu> +1
<TimCole> https://github.com/uq-eresearch/lorestore/blob/master/src/main/resources/OAConstraintsSPARQL.json
<fjh> thank you Chris Birk for scribing
