Web Annotation Working Group Teleconference

<azaroth> https://www.w3.org/annotation/wiki/Scribe_List

<azaroth> Any volunteers to scribe?

Administrative, Scribe, Announcements and Minutes Approval

<dwhly> i'm happy to scribe, but i've never done it before

<azaroth> Or shall we pick someone?

<ivan> scribenick: TimCole

fjh: Make your arrangements for TPAC soon.

<rayd> marriot not full monday night

approve minutes

<fjh> draft RESOLUTION: Minutes from last week approved

RESOLUTION: Minutes from last week 17 Sept are approved

Charter review

<fjh> see http://www.w3.org/annotation/charter/

fjh: Charter will run 2 years
... important to note that the Charter is public
... members and non-members do have different permissions, but we want to engage as many people as possible
... it's really simple, we are working in public
... we can still be respectful of people wanting to maintain details of implementation private
... for TPAC we will meet all day Tuesday
... value of annotation discussed in charter and are self-evident
... we are targeting particularly browser and reading systems
... need to cognizant of testing, interop, etc.
... first 2 deliverables build on work of OA CG
... short timeline, but OA CG gives a good strong

azaroth: Let's summarize briefly first, then go back through to ascertain interest

fjh: benefits sometimes to working separately, sometimes together
... first 2 deliverables --abstract model and serialization
... then HTTP API and Client Side API
... finally the robust link anchoring
... the last will be done in collaboration with Web Apps WG -- so probably a Task Force
... success criteria: we will have 2 'real' implementations (as is typical)
... implementations must be independent -- different underlying code libraries.
... we need to be clear about what is an 'implementation'
... for browser we may not expect a fully deployed in the browser
... out of scope is user interface
... if it makes sense we can combine documentation to cover the deliverables
... the charter lays out a timeline
... for example a working draft of the model by December
... working drafts should be complete, but don't have to be perfect
... in February next 4 deliverables, an aggressive timeline.
... by the end of next year we should have specs that are stable and in good shape
... implementations earlier are better since they inform us as we go along
... timeline suggests a possible f2f in February

Ivan: we put this into the charter, but f2f are more advice rather than requirements
... will be up to us to decide when we need f2f, should make decision later
... there is a rule that f2f date must be agreed in the group at least 8 weeks ahead of date for f2f

fjh: Dependencies and liaisons
... we have a large number of liaisons, we may be able to take advantage of TPAC to start these
... we also need to liaison with closely with DPUB IG

Ivan: we have good overlap with DPub IG which has close relations with EPub

fjh: not clear how best to liaison with the OA CG
... when should we ask for discussion on the CG?
... can we clear about what we need to discuss there rather than here

azaroth: we should relay information to CG as we can, but for discussion about work the WG is doing, best to do that on the WG lists

Paolo: agree. CG is good for acquiring implementation feedback, community clustering, use cases, CG a good venue for that
... leave the discussion about deliverables to the WG lists

<Jacob> +1 to Rob & Paolo's ideas

<azaroth> +1 to paoloC

fjh: participation, active is good, not active doesn't help
... we have a home page, but wiki is becoming important.
... if we do a resolution, it is provisional for 5 days. this gives people who couldn't make the call time to comment
... this approach obviates the need for some of higher overhead, more formal mechanisms for consensus

azaroth: please give a +1 for consensus, +0 don't understand, etc.

fjh: we will first do informal agreement to make sure everyone understands
... when we do bigger things, e.g., documents, we will do formal call for consensus
... if we use +1 approach the more formal approvals will flow naturally.
... not going into patent processes in detail, but please be aware of the terms and conditions
... these matter, please look at offline and be sure you understand.

Deliverables

azaroth: First deliverable is the Abstract Data Model, starting point is the OA CG model
... there were some things that are mature and some things that need more work

<ivan> +1

<paoloC> +1

<fjh> +1

<TimC> +1

azaroth: who is interested in abstract data model?

<Jacob> +1

<rayd> +1

<Kyrce> +1

<nickstenn> +0

<TimCole> +0

<Matt_Haas> +1

<JakeHart> +0

<bjdmeest> +0

<BillKasdorf> +0

<dwhly> +0

azaroth: 2nd deliverable is a vocabulary for expressing the data model

<paoloC> +1

<TimC> +1

<rayd> +1 vocab

<fjh> +1

<Kyrce> +1

<ivan> +1

<BillKasdorf> +1

<Matt_Haas> +1

<TimCole> +0

<nickstenn> +0

<bjdmeest> +1

<Jacob> +1

<JakeHart> +0

<MGU> +1

azaroth: 3rd model is serialization. there are some obvious choices and some less obvious choices like how does this play with HTML5

<fjh> +1

<ivan> +0

<nickstenn> +1

<Jacob> +1

<BillKasdorf> +0

azaroth: do we need a note element in HTML5, how does it work in RDFa

<JakeHart> +1

<paoloC> +0

azaroth: who is interested in serialization

<TimCole> +1

<Matt_Haas> +0

<Kyrce> +1

<bjdmeest> +1

<BillKasdorf> +1

<rayd> +1 serialization

azaroth: 4th topic is HTTP API

<paoloC> +1

<Jacob> +0

azaroth: this about interaction between annotation clients and tools

<fjh> +1 http api

<ivan> +0

<BillKasdorf> +0

<TimCole> +0

<bjdmeest> +0

<nickstenn> +1

<Kyrce> +0

<TimC> +0

<Matt_Haas> +0

<rayd> +0 api

<JakeHart> +1

<MGU> +1 http api

azaroth: 5th topic is javascript / Client side API for browsers and reading systems to implement to make it easier to implement annotation client

<ivan> +1

<nickstenn> +1 :)

<Jacob> +0

<Matt_Haas> +0

<TimCole> +1

<JakeHart> +1

<BillKasdorf> +0

<fjh> +1 client side

<paoloC> +1

<Kyrce> +0

<rayd> +0

azaroth: I am +1 on everything.

<bjdmeest> +1

azaroth: Final topic is robust anchoring, how do we know that when future user comes to resource they still know where the annotation is anchored

<dwhly> +1

<ivan> +1

<Kyrce> +1

<Matt_Haas> +0

<paoloC> +0

<fjh> +1 anchoring

<Jacob> +0

<rayd> +0

<bjdmeest> +0

azaroth: HTML is first topic, others as time allows

<TimCole> +0

<BillKasdorf> +0

<JakeHart> +0

<MGU> +1

<nickstenn> +1

Implementations in the Group

azaroth: Turning to implementations
... what is state of implementations you have or are developing
... these should demonstrate that features can be implemented (as opposed to exercises in futility)
... can it be implemented independently by separate parties

<paoloC> Annotopia

<paoloC> https://github.com/Annotopia

paoloC: at MGH we have been working in last 6 month on Annotopia -- open source OA annotation server
... allows you to save and retrieve annotations, have a dashboard for information about the annotations, etc.
... includes specalized annotations for biomedical use cases
... works with HTML, etc.
... Works with multiple clients
... will also support the annotator js format
... will also support text mining

<fjh> two client implementations, not sure of names

<TimC> Domeo and Utopia

paoloC: we will keep up with specs as developed by the WG

<TimC> Domeo is from MGH/Harvard

<TimC> Utopia is from Manchester

<fjh> fantastic

nickstenn: working on Annotator
... while Annotator is easily mappable to OA data model
... keen to make it more compatible
... first by making a client side implementation of OA data model, this will require working through serialization
... 2nd part is a server side implementation -- annotation storing, retrieving, etc.
... very interested in Client Side implementation goes.

<ivan> scribenick: azaroth

<TimCole> azaroth: will be extremely important for advancing client side implementations

<TimCole> paoloC: in our experience selectors are important for interoperability

TimCole: Not independent, using annotator codebase for our work on digitized book materials, both image and text
... backend is from U Queensland, updated to work as backend for annotator, plus image plugins
... use case is annotating scholarly materials, scholars of renaissance materials. Working in test at the moment.

<fjh> nick notes summary - 1) Annotator client-side work, 2) Server-side implementation, 3) Polyfill for whatever the DOM APIs end up looking like

azaroth: Stanford is also very keen to work with others, have ongoing engineering work to build a LD back end for annotations
... interest in cultural heritage materials, born digital scholarly materials, etc.
... want to make sure implementations are compatible, best of breed.

fjh: question: are we using things from other places -- how independent?

<nickstenn> Zakim: IPcaller.a is aron_

<fjh> TimCole: use plugins for extensibiilty, also forked annotator code

<fjh> … to handle images differently

<fjh> … implememtations overlap, makes maintenance a challenge

<fjh> … not wholly independent on client side, server side is more shared

yes, Lorestore

azaroth: logistics of workflows before closing, discuss more on the mailing list

Logistics

ivan: we have options at W3C for working collaboratively
... CVS still available, newer is github
... W3C also has a mercurial repository
... I would propose we agree to work on github for all of our documents

<MGU> +1 for github

<azaroth> +1 for github

<nickstenn> I'm +1 to git, +0 for GitHub

<paoloC> +1 for github

<Jacob> +1 for github

ivan: if we use github, user accounts are not bound to W3C, so each member must communicate by email to ivan their github account

<dauwhe> +1 for hg :)

<nickstenn> ...and -INT_MAX for CVS

<bjdmeest> +1 for github

ivan: we set up main branch as gh_pages
... do we need to discuss or can we agree now?

<nickstenn> question: is there a W3C backup of the GitHub repository?

<fjh> RESOLUTION: WG use github for repository

ivan: will set up a github repository this week.
... W3C has a tracker set up, advantage of tracker is bound to IRC

<Kyrce> Agree with you nickstenn re: backup

ivan: this allows us to setup actions etc. via irc and email
... the other possibility is to use github issue handling.

<azaroth> Apologies, I need to drop out for a different call

ivan: may need to discuss issue tracking on the email list this week

nicksteen via fjh: what is risk of losing data on github

<fjh> we should explore automating pull of github for w3c archive as backup mechanism

ivan: W3C is planning to capture periodically, but not in place yet
... real risk, if we keep local archives up to date, is minimal.

Adjorn

<ivan> trackbot, end telcon