Meeting minutes, 2014-12-03

Minutes are here:

text version below.

Thanks to Tim for scribing!


Ivan Herman, W3C
Digital Publishing Activity Lead
mobile: +31-641044153



              Web Annotation Working Group Teleconference

03 Dec 2014



   See also: [3]IRC log



          Doug_Schepers (shepazu), Paolo_Ciccarese (PaoloC), Rob
          Sanderson (azaroth), Frederick Hirsch (fjh), Nick
          Stenning (nickstenn), Dave Cramer (dauwhe), Time Cole
          (TimCole), Ivan Herman (Ivan), Ben de Meester
          (bjdmeest), Matt_Haas, Kyrce, Ray Denenberg (rayd),
          Dinesh, Maxence Guesdon (MGU), Benjamin_Young
          (bigbluehat), Jake Hartnell, Jacob Jett

          Markus Gylling

          Frederick Hirsch



     * [4]Topics
         1. [5]Administrative (Scribe selection, agenda review,
         2. [6]Minutes Approval
         3. [7]Annotating Specs
         4. [8]Data Model FPWD
         5. [9]Data Model namespace and context
         6. [10]Robust Anchoring
         7. [11]Use Cases
         8. [12]Discovery
         9. [13]Upcoming meetings
        10. [14]Adjourn
     * [15]Summary of Action Items

   <trackbot> Date: 03 December 2014

Administrative (Scribe selection, agenda review, announcements)

   <fjh> s;Agenda:.*;Agenda:


   <fjh> Agenda:


   <bigbluehat> fjh: can we include the call number + extension as
   a tel: URL in the agenda mails? :) would be handy!

   <bigbluehat> what's the command to associate # + name?

   <bigbluehat> thanks!

   <bigbluehat> bigbluehat: == Benjamin Young

   <bigbluehat> no worries! :)

   <fjh> mapping number to handle automatically


   <MGU> Sorry, y english is not good enough :-(

   <ivan> scribenick: TimCole

   <fjh> revised agenda


   fjh: reviewed the agenda

   <fjh> updated scribe list


Minutes Approval

   <fjh> proposed RESOLUTION: 19 November 2014 minutes approved:


   <ivan> +1

   shepazu: other groups don't do minutes approval on the call

   fjh: would prefer to keep doing it on the call

   RESOLUTION: 19 November 2014 minutes approved:


Annotating Specs

   <fjh> Call for implementations and participation, see


   <fjh> community group,


   fjh: Doug sent out email requesting implementation ideas /
   ... also a message went to CG

   shepazu: we want to be able to annotate our (W3C) own specs
   ... we want to start with Annotator
   ... we want to use other tools as they come forward
   ... discussion about which tool should not be something on
   which we spend time
   ... so we formed a spec annotation CG
   ... if you are interested in the software aspects (as distinct
   from standardization), should join the CG
   ... so please offer other tools, multiple implementations, ...

   fjh: One thing we need to know when we can start annotating,
   and if there are instructions for doing it

   shepazu: we hope to be ready by Friday
   ... this will be done on
   ... when you select something you will see the side bar
   ... annotate in using the sidebar (after logging in).

   fjh: any questions?

   azaroth: to clarify this will be a copy on
   rather than the master on w3c

   shepazu: we will encourage editor drafts on,
   but will also be able to annotate on

Data Model FPWD

   <fjh> Call for Consensus (CfC) to publish FPWD of Data Model


   <fjh> Transition request sent,
   .html (member only)


   fjh: no objections to publishing FPWD
   ... we want to get this published before the moritorium

Data Model namespace and context

   <fjh> oa namespace, JSON-LD context


   fjh: perhaps we can just change the landing page to reflect
   that we are now managing the context

   azaroth: we can update the context URI separately from the
   ... this would leave the previous context URI for the CG and
   would put the WG context at new URI

   ivan: we can work out the details by email

   <fjh> +1 to rob sending email to list with details

   ivan: Rob will write down his idea in detail and he and Ivan
   will make this happen

   <azaroth> ACTION: azaroth and ivan to discuss the details of
   migration offline [recorded in

   <trackbot> Created ACTION-2 - And ivan to discuss the details
   of migration offline [on Robert Sanderson - due 2014-12-10].

Robust Anchoring

   fjh: do we have anything new?

   shepazu: there is a lot to talk about.
   ... how do we wan to approach this?
   ... people on the call who want to talk about the topic
   ... if not, Doug will introduce it on the email list

   fjh: Maybe an email to the list and then a discussion on a call
   might be best.

   shepazu: wondering if people on the call today that have an
   interest in robust anchoring

   <ivan> +1

   <fjh> interested, not sure whether off call preparation is

   <fjh> believe so

   <azaroth> +1 to pre-call prep

   <fjh> +1 to having concrete proposal to work from

   paoloC: best to introduce and raise concrete examples to help
   frame productive discussion

   shepazu: volunteers to put together an initial draft for

   ivan: would like to hear more about what implementations do now
   ... what are the approaches, experience, positive and negative
   ... experience is a good place to start

   <fjh> ACTION: shepaz to provide robust anchoring architecture
   draft on list to give start [recorded in

   <trackbot> Error finding 'shepaz'. You can review and register
   nicknames at <[30]>.


   <fjh> ACTION: shepazu to provide robust anchoring architecture
   draft on list to give start [recorded in

   <trackbot> Created ACTION-3 - Provide robust anchoring
   architecture draft on list to give start [on Doug Schepers -
   due 2014-12-10].

   azaroth: there are a large number of examples from CG and
   elsewhere to draw on

   paoloC: would be happy to share experience gleaned over several
   ... we should be able to annotate HTML
   ... not easy to handle for several reasons
   ... for example the same document in different clients has
   different byte count, etc.
   ... so we use prefix and suffix to what you are annotating
   ... prefix and suffix a certain number of characters
   ... if subsequent re-matching works, then all good
   ... if not, increase length of prefix and suffix
   ... works for some changes elsewhere in the document if these
   don't change the prefix and suffix
   ... when match fails (because of document change) our client
   just shows the annotation on the side (orphaned)
   ... the idea of prefix and suffix also works well for
   cross-format use cases (annotate PDF, display in HTML)

   <fjh> paoloC: handles dom processing to convert tags to strings
   as needed

   paoloC: we have developed rules of thumb over time
   ... as Web pages become more complex, and as CSS affects
   presentation, so we try not to cross sections when calculating
   prefix and suffix
   ... sometimes may only be able to have a suffix
   ... these have been tuned on scientific papers, wikipedia,
   other content that our users annotate

   shepazu: questions - when trying to reanchor an annotation, do
   you change the context?

   paoloC: did some experimentation a few years ago
   ... first you tests right away
   ... then when you come back 6 months it no longer works
   ... you may be able to make a good guess, but often for
   scientific papers not always a good idea

   shepazu: poetry, lots of repetition, so you need to know which

   <fjh> paoloC: issue is that same word might appear often in
   technical paper, so hard to anchor without more information

   paoloC: even worse for legal documents

   <fjh> shepazu: also music lyrics

   paoloC: other tools use different approaches that may be better
   for such situations

   shepazu: not clear about approaches that work well for
   increasingly modern dynamic documents
   ... so not sure how much literature has dealt with these newer,
   very dynamic documents
   ... if an annotation engine wants to say this annotation would
   be better anchored with new anchors, do we still keep the old

   paoloC: most of the problems last few years have arisen trying
   to keep up, i.e., because of increasingly dynamic documents
   ... because of all the javascript now being used by publishers
   - making things harder

   <fjh> are ads a problem?

   paoloC: but sometimes you can get api access to the base
   ... not able to annotate flash
   ... technological challenge is great, things change
   ... re keeping track of new selectors, we have to be careful to
   track provenance, e.g., we have to keep track of what was
   initially annotated.

   <Zakim> fjh, you wanted to ask about rules of thumb

   <azaroth> +1 to the danger of changing selectors in some

   paoloC: it can be dangerous to change exactly what was
   annotated and the original selectors

   fjh: Paolo, do you have documentation we can share

   paoloC: some documentation shared with previously

   <fjh> paoloC: work with static docs, but javascript becomes a

   paoloC: an example of changes is how images are handled
   ... used to be a fixed size, now the image size changes when
   you mouse over
   ... so the annotation client alters the behavior of the page so
   that the image is always fixed size.

   nickstenn: what comes to mind in listening to this is how hard
   this is to do in general
   ... we need to keep in mind a number of considerations that
   haven't yet been raised
   ... how do these approaches work in non-Western languages
   ... not convinced we know what we're doing well enough to

   fjh: we should continue this discussion on the list, unless
   someone has a contribution now that we need to get started
   ... we don't yet have a robust definition of robust anchoring,
   but we understand that to make annotation work, we need to lay
   out the landscape

   <fjh> lets take this to the list

   Dinesh: for example versioning control; I anchor one version
   and that may be important
   ... that's all we can say at this point

   <nickstenn> My position: we should focus on what support we
   need in APIs and model for robust anchoring, rather than
   talking about algorithms

Use Cases

   <fjh> Call for use cases


   fjh: we have the call for use cases for Rob. We need to decide
   who else to send that call to.

   <azaroth> +1 to broader sharing

   <fjh> cross-format annotations
   ec/0005.html and


   fjh: we have from Paolo the cross-format use case
   ... there were use cases from the dpub IG

   paoloC: my point of raising cross-format use case is to help us
   keep in mind interoperability
   ... what can be done whether what domeo does makes sense, is a
   good starting point

   <bigbluehat> the dpub use cases are all linked from the wiki
   (and tagged using azaroth's tags) at


   paoloC: Benjamin Young and I worked on setting up the use case
   page - use cases should include concrete examples and should be
   clear about what areas the use case impacts

   <bigbluehat> sorry for the nit...there's a lot of us :-P

   paoloC: the cross-format use cases raises the possibility of
   annotating an identifier (that might not be a URI)
   ... for example annotating a doi or pii, i.e., a work that may
   have multiple representations, each with their own URL/URI
   ... these identifiers are a shortcut for associating an
   annotation with a work

   fjh: we should take this to the list and help us figure out
   what the WG wants to focus on.


   fjh: discovery is not explicitly in our charter, so we need to
   figure out if there's something meaningful that fits with us.
   Any quick thoughts?

   <bigbluehat> agree with shepazu

   shepazu: thinks discovery is part of the REST API
   ... this is being discussed in parallel in the Social WG

   <fjh> good to know, then we should start thinking about this
   more seriously

   shepazu: so we should discuss and coordinate closely with
   Social WG

   azaroth: agrees discovery is important to do
   ... but parts could be deferred until we have better and more
   use cases to help us understand the scope appropriate for

   rayd: summarizing from his email - doesn't want to impose a
   burden to deal with the full discovery
   ... but if we can define a mechanism for notification, i.e.,
   the ability to notify the owner of annotation target
   ... this would allow the owner of the target to take action as
   ... provided 3 use cases

   paoloC: volunteers to copy into the wiki

   <Jacob> This sounds familiar. Is it worth looking into the
   'expectation' use case again?

   paoloC: will interact with rayd to make sure we don't

Upcoming meetings

   shepazu: the diagram we've been using does cover notification -
   not explicit in the charter, but is something we have discussed

   <fjh> proposed RESOLUTION: no teleconference 24 December or 31

   shepazu: it may not be this WG that ultimately defines the
   discovery mechanism, but we need to be part of the process.

   RESOLUTION: no teleconference 24 December or 31 December

   fjh: defer decision on 17 Dec.


   <fjh> Thanks everyone!

   <ivan> trackbot, end telcon

Summary of Action Items

   [NEW] ACTION: azaroth and ivan to discuss the details of
   migration offline [recorded in
   [NEW] ACTION: shepaz to provide robust anchoring architecture
   draft on list to give start [recorded in
   [NEW] ACTION: shepazu to provide robust anchoring architecture
   draft on list to give start [recorded in

   [End of minutes]

    Minutes formatted by David Booth's [39]scribe.perl version
    1.140 ([40]CVS log)
    $Date: 2014-12-03 17:12:26 $


Received on Wednesday, 3 December 2014 17:13:37 UTC