Meeting minutes, 2016-02-26

Minutes are here:

https://www.w3.org/2016/02/26-annotation-minutes.html

text version below.

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

26 Feb 2016

   [2]Agenda

      [2] http://www.w3.org/mid/CABevsUHPphbug7QnmHNfjiwcugFyJtGJGOERouHQXYZ5qfGxPw@mail.gmail.com

   See also: [3]IRC log

      [3] http://www.w3.org/2016/02/26-annotation-irc

Attendees

   Present
          Ivan Herman, Frederick Hirsch, Rob Sandersion (azaroth),
          Tim Cole, Benjamin Young (bigbluehat), Jacob Jett, Doug
          Schepers (shepazu), Davis Salisbury, Paolo Ciccarese,
          Ben De Meester, Chris Birk, TB Dinesh, Takeshi Kanai

   Regrets
          Dan Whaley

   Chair
          Rob Sanderson

   Scribe
          Tim Cole

Contents

     * [4]Topics
         1. [5]Scribe Selection, Agenda Review, Announcements
         2. [6]Minutes Approval
         3. [7]Logistics
         4. [8]XPath Selector
         5. [9]Range Selector
         6. [10]issue #177
         7. [11]Dates in the model
         8. [12]Multiple Selectors, States
     * [13]Summary of Action Items
     * [14]Summary of Resolutions
     __________________________________________________________

   <ivan> trackbot, start telcon

   <trackbot> Meeting: Web Annotation Working Group Teleconference

   <trackbot> Date: 26 February 2016

   <azaroth> trackbot, start meeting

   <trackbot> Meeting: Web Annotation Working Group Teleconference

   <trackbot> Date: 26 February 2016

Scribe Selection, Agenda Review, Announcements

   <azaroth> scribenick: TimCole

   <azaroth> scribe: Tim_Cole

   azaroth: Let's review agenda...
   ... first logistics, then a few issues, then AOB
   ... anything else?
   ... any announcements?

Minutes Approval

   <azaroth> PROPOSED RESOLUTION: Minutes of the previous call are
   approved:
   [15]https://www.w3.org/2016/02/19-annotation-minutes.html

     [15] https://www.w3.org/2016/02/19-annotation-minutes.html

   RESOLUTION: Minutes of the previous call are approved:
   [16]https://www.w3.org/2016/02/19-annotation-minutes.html

     [16] https://www.w3.org/2016/02/19-annotation-minutes.html

Logistics

   <azaroth> Register:
   [17]https://www.w3.org/2002/09/wbs/73180/anno-f2f-berlin-2016/

     [17] https://www.w3.org/2002/09/wbs/73180/anno-f2f-berlin-2016/

   azaroth: Reminder. Please register for WG f2f using the link in
   the chat

   <azaroth> Wiki:
   [18]https://www.w3.org/annotation/wiki/Meetings/F2F_Berlin_2016

     [18] https://www.w3.org/annotation/wiki/Meetings/F2F_Berlin_2016

   azaroth: also posting the link to the wiki page
   ... even if not going, please complete the registration
   questionaire so we know.

   ivan: IAnnotate is posting a list of hotels recommended by MS,
   etc.

   azaroth: we should make sure we get link and circulate...

   ivan: Doug or I can do a work around for individuals.
   ... if you can't get to questionaire, please send W3c user name
   to to Doug and Ivan

XPath Selector

   <azaroth> Github:
   [19]https://github.com/w3c/web-annotation/issues/95

     [19] https://github.com/w3c/web-annotation/issues/95

   <azaroth> draft:
   [20]http://w3c.github.io/web-annotation/model/wd2/#xpath-select
   or

     [20] http://w3c.github.io/web-annotation/model/wd2/#xpath-selector

   azaroth: the issue is a proposal to add an XPath Selector

   <azaroth> proposal:
   [21]https://github.com/w3c/web-annotation/issues/95#issuecommen
   t-186344208

     [21] https://github.com/w3c/web-annotation/issues/95#issuecomment-186344208

   azaroth: will let us use XPath within in DOM-based targets,
   including HTML

   <ivan> +1 for it, it seems to be a no brainer...

   azaroth: questions, comments

   fjh: Does XPath have features that we want to exclude from
   being used as a Selector

   azaroth: yes, functions could get messy
   ... but hesitation about restricting is that then implementers
   would have to shut down bits of the standard XPath libraries
   they want to use

   <bigbluehat> shepazu: same difference

   shepazu: if you want to do what fjh suggested, you could simply
   identify the parts of XPath implementers should use

   <fjh> +1 to suggesting portions to use, otherwise at ‘your own
   risk’

   shepazu: that would not require implementers to shut down bits
   of XPath libraries

   ivan: I don't know that we need to get into the issues about
   what parts of XPath to use

   <bigbluehat> [22]https://www.w3.org/TR/xpath/

     [22] https://www.w3.org/TR/xpath/

   ivan: if implementers get over-complicated, that's their
   responsibility

   <azaroth> (+1 to Ivan)

   shepazu: but we do want to make sure that we have
   interoperability

   fjh: at a minimum there should be a warning to use XPath
   intelligently

   azaroth: trying to decide what we want people to use is
   overkill and could set precedent for CSS and other technologies
   that we want to use as selectors
   ... we are not suggesting you don't do SVG animation when using
   SVG selector

   <bigbluehat> +1 to our not curtailing what "XPath" means in our
   spec

   azaroth: we took out a OA CG restriction on SVG selectors

   <davis_salisbury> +1 to not curtailing

   <tbdinesh_> +0

   <fjh> fine with a warning and not curtailing

   <shepazu> -0

   <PaoloCiccarese> -not sure what the danger is

   azaroth: a warning for selectors like XPath, CSS, SVG seems a
   reasonable compromise

   <shepazu> (the danger is lack of interoperability)

   <azaroth> PROPOSAL: Accept XPathSelector, as written up in the
   Editor's Draft ; add a warning to CSS, XPath and SVG to use as
   intended

   <azaroth> +1

   <tbdinesh_> should we have page authoring guidelines for well
   behavedness re annotations

   <ivan> +1

   <PaoloCiccarese> +1

   <fjh> +1

   <takeshi> +1

   <davis_salisbury> +1

   RESOLUTION: Accept XPathSelector, as written up in the Editor's
   Draft ; add a warning to CSS, XPath and SVG to use as intended

Range Selector

   <azaroth> Github:
   [23]https://github.com/w3c/web-annotation/issues/153

     [23] https://github.com/w3c/web-annotation/issues/153

   <azaroth> Draft:
   [24]http://w3c.github.io/web-annotation/model/wd2/#range-select
   or

     [24] http://w3c.github.io/web-annotation/model/wd2/#range-selector

   azaroth: this selector has a start point and end point
   (described by individual selectors) and everything in between
   is selected.
   ... this aligns well with how ranges are done in DOM
   ... makes it easy for implementers familiar with this use in
   DOM
   ... still have time to remove from draft a little further on if
   new concerns arise

   <ivan> +1

   azaroth: any comments?

   PaoloCiccarese: we had a long discussion about these in the CG.
   ... if we look at example #27, does this suggest range selector
   replaces existing selectors?

   <azaroth> Github:
   [25]https://github.com/w3c/web-annotation/issues/177

     [25] https://github.com/w3c/web-annotation/issues/177

   azaroth: now it is an addition, not a replacement, but see
   issue #177...
   ... let's see what people think about range first, then look at
   possible merging

   <azaroth> PROPOSAL: Accept RangeSelector as written in editor's
   draft

   <ivan> +1

   <azaroth> +1

   <bigbluehat> +1

   <davis_salisbury> +1

   <takeshi> +1

   <fjh> +1

   <PaoloCiccarese> +1

   RESOLUTION: Accept RangeSelector as written in editor's draft

issue #177

   <ivan> [26]https://github.com/w3c/web-annotation/issues/177

     [26] https://github.com/w3c/web-annotation/issues/177

   azaroth: we now have 2 ways to select the same span of text
   (second is using range selector)
   ... do we need both?

   ivan: I think text position selector will be widely used and
   therefore important to keep

   <bigbluehat> +1 to leaving it as is

   ivan: but duplication worth it to keep this very simple
   approach.

   PaoloCiccarese: Text miners need the less verbose option when
   you doing annotations at scale
   ... Similar issue with data selector
   ... so I am okay with keeping text selector because of
   compactness, not sure we want 3.

   azaroth: difference between text pos selector and data pos
   selector is that one works on underlying (e.g., without tags)

   <fjh> +1 to leave as is

   azaroth: possibly we could merge with a flag to indicate
   whether we are working on the text stream or 'binary' stream

   ivan: would prefer to keep separate, i.e., leave as it is

   <azaroth> PROPOSAL: Keep TextPosition, DataPosition and Range
   Selectors despite some overlap

   PaoloCiccarese: agree the way you interpert is different, so
   merging might make worse than having overlap

   <azaroth> +1

   <bigbluehat> +1

   <PaoloCiccarese> +1

   <ivan> +1

   <takeshi> +1

   +1

   <davis_salisbury> +1

   RESOLUTION: Keep TextPosition, DataPosition and Range Selectors
   despite some overlap

Dates in the model

   <azaroth> Github:
   [27]https://github.com/w3c/web-annotation/issues/141

     [27] https://github.com/w3c/web-annotation/issues/141

   <azaroth> Draft:
   [28]http://w3c.github.io/web-annotation/model/wd2/#lifecycle-in
   formation

     [28] http://w3c.github.io/web-annotation/model/wd2/#lifecycle-information

   <azaroth> Draft:
   [29]http://w3c.github.io/web-annotation/vocab/wd/#json-ld-consi
   derations

     [29] http://w3c.github.io/web-annotation/vocab/wd/#json-ld-considerations

   azaroth: addressed at 2 points in the draft
   ... useful to look at JSON-LD context document which lays out
   how we've done the mapping
   ... issue - XSD dateTime requires you to have time with time
   zone
   ... proposal is to use the W3C Date Time Format
   ... one catch is that Prov requires XSD DateTime
   ... so since we already accepted using W3C DTF, the implication
   is that we are going to change generated (et al.) to map to AS
   rather than Prov
   ... so proposed changes to our context document

   ivan: I don't fully agree with how you got there, but okay with
   end result
   ... that being said, I don't think that because we use labels
   from an external vocab we have to use their data types

   azaroth: ivan is saying that we could continue to map to Prov
   and still use W3C DTF

   ivan: yes, I don't think it is necessary to require XSD
   DateTime because Prov does
   ... but if we like AS for other reasons, that's fine

   azaroth: yes, AS does make sense here, unless others see it
   differently
   ... any one want to retain these two mappings to Prov?

   <ivan> +1

   <azaroth> PROPOSAL: Replace prov terms with terms from other
   vocabularies (dcterms, activity streams)

   +1

   <azaroth> +1

   <ivan> +1

   <davis_salisbury> +1

   <tbdinesh_> +1

   azaroth: this is only an issue for the RDF stack users (JSON
   unchanged)

   <PaoloCiccarese> +1

   <fjh> +1

   <takeshi> +1

   RESOLUTION: Replace prov terms with terms from other
   vocabularies (dcterms, activity streams)

Multiple Selectors, States

   <azaroth> Github:
   [30]https://github.com/w3c/web-annotation/issues/93

     [30] https://github.com/w3c/web-annotation/issues/93

   <azaroth> Draft:
   [31]http://w3c.github.io/web-annotation/model/wd2/#sub-selectio
   n

     [31] http://w3c.github.io/web-annotation/model/wd2/#sub-selection

   azaroth: primary issue is 93, but see also see 135
   ... last time we were leaning towards proposal to use
   subSelector better than status quo
   ... proposal preferred to inverse alternative
   ... suggestion that it was unnecessary
   ... proposal says to write up subSelector proposal and then
   discuss as new issue whether to take it out

   TimCole: OA CG added multiplicity late to reduce ambiguity and
   reduce opportunities for misunderstanding
   ... helped that same construct could be used for selectors and
   resources used as targets / bodies
   ... Given reconsideration of multiplicity in general, I am okay
   with the idea of replacing Choice,
   ... does add ambiguity in that you have no way certain to
   identify the preferred alternative,
   ... but this seems an acceptable amount of ambiguity
   ... Similarly I am okay with replacing list with nesting

   <azaroth> Agree that we've lost preferred alternative for
   choice

   TimCole: However, if I understand correctly, subSelector and
   subState are intended to be recursive
   ... so why not just adjust the definition of selector and state
   to allow recursion and avoid 2 new properties
   ... the objects that can appear as selector and subSelector
   values (i.e., their range) is identical
   ... the only difference is in domain, the domain of selector is
   SpecificResource,
   ... while the domain of subSelector is essentially selector or
   subSelector.
   ... I would rather see us simply broaden the definition of
   selector and state to allow recursion
   ... the only real advantage of the subSelector / subState
   properties is it makes clear that other
   ... specifiers do not nest. This can be stated. And if we ever
   change our mind, no new properties need
   ... to be added, just up date the definitions to allow.
   ... The proposed solution seems to leave open the door for
   considering this idea of simply allowing
   ... nested recursion of selector and state, but if we get to
   the point of a CR with subSelector and subState
   ... we will have in essence precluded doing this since the
   sub-properties will by then be in general use
   ... so I in favor of the proposed solution if we very quickly
   revisit whether we need explicit new
   ... properties or can make do by simply adjusting the
   definition of selector and state

   ivan: we have agreed to flag a feature as 'at risk'
   ... so we have the right to remove the feature before going to
   the next step
   ... but regardless I don't understand for not having

   azaroth: one reason to have is to differentiate selector and
   state as potentially being chained.
   ... but also the semantics are a little different
   ... so you are applying the subSelector to a result (not made
   explicit) rather than on a source
   ... not lying down in the road, but preference is to have a
   different term to make semantics clear and also to
   differentiate selector or state from other specifier

   <davis_salisbury> Sorry folks, need to go.

   azaroth: not entirely sure what Nick was after, but if Nick (or
   Tim) wants to open an issue about need for subSelector and
   SubState, can do so.

   PaoloCiccarese: let's make more concrete
   ... assume a 3-D model
   ... assume I rotate the model (State?)
   ... now I apply a subSelector to select the region of the
   rotated view

   <azaroth> oa:refinedBy ?

   PaoloCiccarese: we could have called it refiner instead of
   subSelector

   azaroth: another example is selecting inside a zip file

   PaoloCiccarese: Data is also a good use case, since it may take
   multiple steps to find the right granular

   <PaoloCiccarese> I would not

   <azaroth> PROPOSAL: Accept overall model, change
   subSelector/subState to refinedBy

   <PaoloCiccarese> +1

   <azaroth> +1

   TimCole: if we go refinedBy, we would not need separatre
   subSelector and subState

   <ivan> +1

   +1

   <tbdinesh_> +1

   PaoloCiccarese: just to confirm, I can have a chain of them
   (recursion)

   azaroth: yes

   RESOLUTION: Accept overall model, change subSelector/subState
   to refinedBy

   <ivan> trackbot, end telcon

Summary of Action Items

Summary of Resolutions

    1. [32]Minutes of the previous call are approved:
       https://www.w3.org/2016/02/19-annotation-minutes.html
    2. [33]Accept XPathSelector, as written up in the Editor's
       Draft ; add a warning to CSS, XPath and SVG to use as
       intended
    3. [34]Accept RangeSelector as written in editor's draft
    4. [35]Keep TextPosition, DataPosition and Range Selectors
       despite some overlap
    5. [36]Replace prov terms with terms from other vocabularies
       (dcterms, activity streams)
    6. [37]Accept overall model, change subSelector/subState to
       refinedBy

   [End of minutes]
     __________________________________________________________


    Minutes formatted by David Booth's [38]scribe.perl version
    1.144 ([39]CVS log)
    $Date: 2016/02/26 17:32:04 $

     [38] http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm
     [39] http://dev.w3.org/cvsweb/2002/scribe/

Received on Friday, 26 February 2016 17:37:12 UTC