Meeting minutes, 2016-09-30

Minutes are here:

https://www.w3.org/2016/09/30-annotation-minutes.html

Text version below

Cheers

Ivan

----
Ivan Herman, W3C
Digital Publishing Technical 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

30 Sep 2016

   [2]Agenda

      [2] http://www.w3.org/mid/03c701d21a9f$8bbf54a0$a33dfde0$@illinois.edu

   See also: [3]IRC log

      [3] http://www.w3.org/2016/09/30-annotation-irc

Attendees

   Present
          Benjamin Young (bigbluehat), Rob Sanderson (azaroth),
          Ivan Herman, Sarven Capadisli (csarven), Tim Cole , TB
          Dinesh, Dan Whaley, Jacob Jett, Shane McCarron

   Regrets
   Chair
          Tim, Rob

   Scribe
          TimCole, azaroth, Jacob

Contents

    1. [4]Issue Updates
         1. [5]Issue 355
         2. [6]issue #357
         3. [7]issue #358
         4. [8]issue #360
    2. [9]Testing, CR time planning
    3. [10]Annotation in HTML Note
     __________________________________________________________

   <azaroth> trackbot, start meeting

   <trackbot> Meeting: Web Annotation Working Group Teleconference

   <trackbot> Date: 30 September 2016

   <azaroth> Chair: Rob_Sanderson, Tim_Cole

   <csarven> In the process of joining the call.

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

     [11] https://www.w3.org/2016/09/16-annotation-minutes.html

   <TimCole> scribenick: TimCole

   <azaroth> +1

   +1

   <ivan> +1

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

     [12] https://www.w3.org/2016/09/16-annotation-minutes.html

Issue Updates

   <azaroth> Git:
   [13]https://github.com/w3c/web-annotation/issues/354

     [13] https://github.com/w3c/web-annotation/issues/354

   azaroth: The appendices need to be marked informative rather
   than left blank defaulting to normative
   ... azaroth has made updates showing all except extension as
   informative

   ivan: if C is left normative then we have to test.

   azaroth: a good reason not to leave C normative
   ... propose all vocab appendices be informative

   ivan: still requires editorial action, correct?

   azaroth: correct

Issue 355

   <azaroth> Git issue:
   [14]https://github.com/w3c/web-annotation/issues/355

     [14] https://github.com/w3c/web-annotation/issues/355

   azaroth: this is in relation to TPAC discussion about CG, WG,
   IG making changes to namespaces, because namespace docs are not
   normative
   ... however, these changes could affect normative sections and
   constraints
   ... propose adding a comment to namespace clarifying our
   intended direction for document, requiring changes have to come
   through a WG

   ivan: not sure how to say properly
   ... hypothetical- a new publishing WG next year decides it
   needs to define a new selector
   ... unless this new selector references the Annotation specs,
   couldn't add to oa namespace

   azaroth: yes, they can add to their own namespace, but not ours

   ivan: are we going to far the other direction?
   ... can we be more wishy washy

   bigbluehat: one of the groups interested in this is the Soc Web
   WG
   ... they have a term that they would like to LDP (for
   notifications) and they are having a problem getting this done
   ... vocab extension discussion is growing
   ... so we need to leave open to eventual solution

   azaroth: would ivan's wording, e.g., extension must come from a
   WG that has established expertise

   <ivan> for example, "Any changes to this document MUST be from
   a Working Group in the W3C that has established expertise in
   the area"

   azaroth: we can't enforce, but we should make our feelings
   known

   bigbluehat: we need to be clear whether we want to allow CGs to
   add extensions.

   <bigbluehat> +1 to ivan's wording..."established expertise"
   being sufficiently vague, but also exciting ;)

   csarven: probably would be best to leave to WG, not CG

   <azaroth> +1 to Ivan's wording as well

   csarven: we need confidence that the group making the extension
   has knowledge and is committed, which is more likely to come
   with WG rather than CG or through a note

   <Jacob> +1 from me as well

   csarven: should do our best to preclude random extensions and
   changes

   <bigbluehat> +1 to proposing ivan's wording as a resolution

   <rhiaro> +1 ivan's wording from the sidelines

   azaroth: any objections to Ivan's wording?
   ... none heard, let's move forward with this as an editorial
   change

   ivan: where does this text go?

   azaroth:

   <azaroth> Git Issue:
   [15]https://github.com/w3c/web-annotation/issues/357

     [15] https://github.com/w3c/web-annotation/issues/357

   azaroth: just into the namespace document

issue #357

   azaroth: from testing, should it be allowed to have TextualBody
   as the source of a SpecificResource
   ... technically it should be allowed (a TextualBody is a
   Resource)
   ... but current language seems more constraining in how
   TextualBody is used
   ... allowing would make it possible to use styleClass and
   renderedVia on TextualBody
   ... also a TextualBody of Anno A may become the Target of Anno
   B

   ,,, does this need to be clarified?

   ivan: yes we acknowledge that it is allowed, but don't change
   the document

   <Jacob> +1 to ivan

   <bigbluehat> +1

   ivan: if we start looking at use cases, we could end up in a
   lengthy discussion

   <azaroth> scribenick: azaroth

   TimCole: It came from some real annotations at Princeton, they
   were using purpose this way. I pointed out they didn't really
   have to. Some early testing discussions was that we didn't
   really want this. We can change the tests, and happy for people
   to ask questions that might be clarified in email or later
   documents
   ... As Rob says, the model doesn't conclude this either way,
   and there'll be some confusion around purpose as there's two
   ways to handle purpose in the model

   <TimCole> scribenick: TimCole

   azaroth: proposal, make sure tests allow, but no change is
   really needed in the specs. These are edge cases and we now
   know how we feel about this
   ... result is we close the issue (Ivan has done).

issue #358

   azaroth: this is just a bug
   ... the context has a different term than we have in the model
   ... fix is to change term in context
   ... context is not normative, so we should be able to modify
   now without an additional process

   ivan: also found a couple of issues with the context document,
   so let's fix these as soon as possible
   ... also found issues with the namespace document

   <azaroth> Git:
   [16]https://github.com/w3c/web-annotation/issues/359

     [16] https://github.com/w3c/web-annotation/issues/359

   ivan: so let's change and Ivan will update

   azaroth: the other issues are #359 and #353

   <azaroth> Git:
   [17]https://github.com/w3c/web-annotation/issues/353

     [17] https://github.com/w3c/web-annotation/issues/353

   azaroth: #353 is a duplicate of one Greg already submitted
   ... so editors will fix (azaroth) and pass on to Ivan
   ... azaroth will close

issue #360

   <azaroth> git:
   [18]https://github.com/w3c/web-annotation/issues/360

     [18] https://github.com/w3c/web-annotation/issues/360

   latest issue is about use of rights

   azaroth: not clear from an ip perspective what an annotation
   is, so what is the rights statement conveying
   ... second statement was we said that the statement must be a
   uri but can it be a json instead?
   ... bodies and annotation each can have separate rights
   statements
   ... do we need to make any changes, beyond responding to
   clarify what the annotation is

   <bigbluehat> add a license to target in the example also?

   <bigbluehat> the text is great

   <bigbluehat> or maybe expand the example to show multiple
   bodies?

   ivan: text fairly clearly says what the rights statements
   applies to
   ... maybe one or two words can be editorial altered but...

   azaroth: second part -- must be iri, can it be embedded json?

   <bigbluehat> can we say Resource?

   azaroth: not certain what they meant be embedded json
   ... is it a description of a resource? or something random?

   ivan: think what was meant is that in some cases we want a
   complex resource there
   ... e.g., a blank node with some properties

   <azaroth> " There may be at exactly 0 or more rights statements
   or licenses linked from each resource, and the value must be an
   IRI. "

   azaroth: didn't want to overcomplicate the rights statement, so
   went with an iri rather than "resource"

   ivan: can respond that this was intended

   TimCole: we tested it that way too

   ivan: then we can respond that changing from iri would be a
   normative change which would complicate the CR
   ... is this important enough to reopen the CR to make a
   normative change?
   ... if there are valid use cases here, we record them in git
   with an eye towards revising in version 2
   ... Rob please respond to him so that the issue is properly
   closed

Testing, CR time planning

   TimCole: CR ends today
   ... not certain that we have 2 implementations of everything to
   be tested
   ... what would be realistic to get the testing done
   ... just made some changes that tweak the tests

   <ShaneM>
   [19]https://w3c.github.io/test-results/annotation-model/README.
   md

     [19] https://w3c.github.io/test-results/annotation-model/README.md

   ivan: looking at the model report (from Takeshi), 1st block are
   the required features
   ... 2nd block is optional?

   TimCole: 1st block determines that specific resource wasn't
   misused
   ... 2nd block determines that specific resource was used
   ... textual body also implemented now
   ... once we have Rob's implementation and Europeana's
   implementation then we will be very close to 2 implementations

   ivan: can see two fails (content locator and id must match) and
   (target iri)

   azaroth: these are bugs in line to be fixed
   ... https still getting it, as for paging, not enough
   annotations to test yet

   ivan: will everything be ready to start the last round of
   testing[?] by the end of October?

   azaroth: can take the output from the protocol servers and
   reuse for testing the model

   TimCole: embedded textual body only has one implementation
   ... body value

   azaroth: generated we will get from the protocol servers

   TimCole: but not part of exit criteria
   ... embedded textual body, choice, independents, specific
   resource, list

   have implementations of choice but not independents or list

   azaroth: that's ok, they are marked at risk

   ShaneM: want to confirm that things are being removed because
   of implementations and not the lack of tests

   TimCole: these were marked at risk because while we have use
   cases, no one is implementing, not related to tests

   ivan: by last week of October, editorial changes should be done
   ... know that some things are pending (from today), these must
   absolutely be done

   <ShaneM> Note that I ened to modify wptreport to allow rolling
   up of results.

   ivan: then tests and reports as we discussed
   ... once these are done then we can move one

   TimCole: still implementing the changes in how we test
   optionals and report optionals

   ShaneM: one of these written, not yet committed

   TimCole: only issue is that there may not be enough
   implementations of bodyValue

   ivan: we're still waiting for Europeana

   <csarven> I'll have to revisit
   [20]https://github.com/csarven/mayktso to see how close it is
   to being a WAP implementation.

     [20] https://github.com/csarven/mayktso

   TimCole: reference implementation = a by-hand annotation based
   on the model

   <tbdinesh> yep

   TimCole: in the report columns it is labeled AI, EB is Illinois
   working implementation (for the Emblematica DigLib)

   ivan: if we get an implementation from dinesh and europeana
   then that will be 5 or 6 implementations for the model
   ... if europeana implements the protocol then we'll have three
   implementations of that

   <ShaneM> I have removed the AI columns from the model result
   report.

   <Zakim> ShaneM, you wanted to ask about removing things from
   spec

   azaroth: one thing to note, Rob will be at Europeana in 2 weeks
   time, so can talk directly to Antoine

Annotation in HTML Note

   TimCole: would like to start the html discussion
   ... haven't created the skeleton note yet, doing it this week

   '... assuming that there are only 2 approaches that will be
   described

   scribe: embedding annotations as json+ld in a script tag

   <ShaneM> I wonder how Benjamin's work does it?

   scribe: and embedding via rdfa (by someone else)

   <csarven> [21]https://github.com/csarven/dokieli is one

     [21] https://github.com/csarven/dokieli

   <csarven> err

   <csarven> [22]https://github.com/linkeddata/dokieli is one

     [22] https://github.com/linkeddata/dokieli

   ivan: can we merge this into one note?

   csraven: do we really need a note on rdfa serialization? is
   this to make it easier for people to use the vocab to implement
   rdfa?

   TimCole: the idea is to point to examples of how the vocabulary
   is useful even if the annotations are stored/transmitted
   directly in html
   ... leaving it to someone else to look at in the future

   ivan: the note is not an implementation in the terms of
   testing, intended for users
   ... so that they can see how annotations can be used in/with
   html

   <Zakim> ShaneM, you wanted to mention web platform and
   annotations

   ShaneM: review ongoing for the web platform working group
   ... punts the find text api to the annotation working group

   ivan: there is no work going on it, is not in our charter

   csraven: use case for dokeili is using rdfa
   ... for use with services that are not explicitly annotation
   services
   ... might be good to come up with more use cases for rdfa
   serialization for the note
   ... might be helpful

   TimCole: useful for people to see, use case csraven has
   outlined is compelling

   ivan: don't want to make too much of a deal out of it, at a
   stage where work is winding down
   ... enough for the note to describe the use case as an example
   of usage
   ... goal is to signal that a future working group could address
   embedding annotations into html more formally
   ... but don

   <csarven> Ack ivan, thanks.

   ivan: want to provide to much emphasis on it right now

   s /provide to/provide too

   TimCole: going to create the skeleton of the note and add in
   the json+ld

   <csarven> Happy to lead the RDFa bits

   ivan: should do conver the json+ld into turtle and put it into
   the document too
   ... can use turtle in html too

   <csarven> Sure

   <ivan> trackbot, end telcon

Summary of Action Items

Summary of Resolutions

    1. [23]Minutes of the previous call are approved:
       https://www.w3.org/2016/09/16-annotation-minutes.html

   [End of minutes]
     __________________________________________________________


    Minutes formatted by David Booth's [24]scribe.perl version
    1.144 ([25]CVS log)
    $Date: 2016/09/30 16:11:36 $

     [24] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [25] http://dev.w3.org/cvsweb/2002/scribe/