See also: IRC log
<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
<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
<tbdinesh> persent+ tb_dinesh
<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
https://github.com/w3c/web-annotation/issues/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: 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
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
+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
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
fjh++
<ivan> trackbot, end telcon