- From: Ivan Herman <ivan@w3.org>
- Date: Fri, 19 Feb 2016 18:25:35 +0100
- To: W3C Public Annotation List <public-annotation@w3.org>
- Message-Id: <0C4D7D15-AD20-48A5-BEEE-96D19E04E8DB@w3.org>
Minutes are here:
https://lists.w3.org/Archives/Public/public-annotation/2016Feb/0120.html <https://lists.w3.org/Archives/Public/public-annotation/2016Feb/0120.html>
text version below
Cheers
Ivan
----
Ivan Herman, W3C
Digital Publishing Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704
[1]W3C
[1] http://www.w3.org/
Web Annotation Working Group Teleconference
19 Feb 2016
See also: [2]IRC log
[2] http://www.w3.org/2016/02/19-annotation-irc
Attendees
Present
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,
Regrets
Randall_Leeds, Tim Cole
Chair
Rob_Sanderson
Scribe
bigbluehat, dwhly, azaroth
Contents
* [3]Topics
1. [4]Scribe selection, agenda review, announcements?
2. [5]Minutes Approval
3. [6]Outstanding Issue Review
4. [7]https://github.com/w3c/web-annotation/issues/150:
0-1 or 0-n string bodies
5. [8]https://github.com/w3c/web-annotation/issues/93:
Multiple Selectors
6. [9]Adjourn
* [10]Summary of Action Items
* [11]Summary of Resolutions
__________________________________________________________
Scribe selection, agenda review, announcements?
<fjh> Agenda:
[12]https://lists.w3.org/Archives/Public/public-annotation/2016
Feb/0120.html
[12] 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:
[13]https://www.w3.org/2016/02/12-annotation-minutes.html
[13] 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:
[14]https://www.w3.org/2016/02/12-annotation-minutes.html
[14] https://www.w3.org/2016/02/12-annotation-minutes.html
Outstanding Issue Review
<tbdinesh> persent+ tb_dinesh
<azaroth>
[15]https://github.com/w3c/web-annotation/issues?utf8=%E2%9C%93
&q=is%3Aissue+is%3Aopen+-label%3Aeditor_action+-label%3Apostpon
e
[15] 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 -
[16]https://www.w3.org/Security/wiki/IG
[16] 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
[17]https://github.com/w3c/web-annotation/issues/149
[17] 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>
[18]https://github.com/w3c/web-annotation/issues?utf8=%E2%9C%93
&q=is%3Aissue+is%3Aopen+label%3Aeditor_action
[18] 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
[19]https://github.com/w3c/web-annotation/issues/150: 0-1 or 0-n
string bodies
[19] https://github.com/w3c/web-annotation/issues/150:
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
[20]https://github.com/w3c/web-annotation/issues/93: Multiple
Selectors
[20] https://github.com/w3c/web-annotation/issues/93:
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>
[21]https://github.com/w3c/web-annotation/issues/93#issuecommen
t-173398909
[21] 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>
[22]https://github.com/w3c/web-annotation/issues/93#issuecommen
t-173962602
[22] https://github.com/w3c/web-annotation/issues/93#issuecomment-173962602
ivan: origins in functional programming
... debate ensued, matter of taste
<ivan>
[23]https://github.com/w3c/web-annotation/issues/93#issuecommen
t-174291171
[23] 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>
[24]https://github.com/w3c/web-annotation/issues/93#issuecommen
t-175080258
[24] 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
Adjourn
<fjh> if we express the concern clearly it may resolve easily
fjh++
<ivan> trackbot, end telcon
Summary of Action Items
Summary of Resolutions
1. [25]Minutes of the previous call are approved:
https://www.w3.org/2016/02/12-annotation-minutes.html
2. [26]Use the current 0-1 strings for bodyText, and disallow
arrays of strings
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [27]scribe.perl version
1.144 ([28]CVS log)
$Date: 2016/02/19 17:22:13 $
[27] http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm
[28] http://dev.w3.org/cvsweb/2002/scribe/
Received on Friday, 19 February 2016 17:25:49 UTC