[![W3C][1]][2]

# Web Annotation Working Group F2F San Francisco

## 22 Apr 2015

See also: [IRC log][3]

## Attendees

Present

    Frederick_Hirsch, Rob_Sanderson, Tim_Cole, Ray_Denenberg, Randall_Leeds,
Nick_Stenning, Paolo_Ciccarese, Gergely_Ujvari, Kristof_Csillag,
Takeshi_Kanai, Jon_Udell, Phil_Desenne_(Harvard_Observer), TB_Dinesh,
Benjamin_Young, Jake_Hartnell

Regrets


Chair

    Frederick_Hirsch, Rob_Sanderson

Scribe

    tilgovi, TimCole, tbdinesh, fjh, bigbluehat, jakehart

## Contents

  * [Topics][4]

    1. [Welcome, Agenda Review, Announcements][5]

    2. [LDP recap][6]

    3. [Client API][7]

    4. [Minutes Approval][8]

    5. [Agenda review and update][9]

    6. [Protocols][10]

    7. [Publishing][11]

    8. [RangeFinder API][12]

    9. [Search][13]

    10. [Meetings][14]

    11. [Data Model][15]

    12. [Other Business][16]

    13. [Adjourn][17]

  * [Summary of Action Items][18]

* * *

<trackbot> Date: 22 April 2015

<fjh> Agenda: [https://lists.w3.org/Archives/Public/public-
annotation/2015Apr/0118.html][19]

<azaroth> TimCole: [http://w3c.github.io/web-annotation/protocol/wd/][20]

<fjh> 1. Introduction, Scribe Selection, Announcements, etc

<fjh> Annotations at Europeana

<fjh> 2. Minutes approval

<fjh> 3. Client API

<fjh> Frederick to start, followed by implementation lessons and ideas (e.g.
Hypothes.is Nick et al), discussion

<fjh> break

<fjh> 4. LDP Recap

<fjh> 5. Protocol - update, next steps, FPWD?

<fjh> lunch

<fjh> 6 robust anchoring, find

<fjh> break

<fjh> 7 search

<fjh> 8 additional use case discussion - footnotes, web packaging, publishing
etc

<fjh> 9 Data model issue review

<fjh> 10 other business

<fjh> ScribeNick: tilgovi

### Welcome, Agenda Review, Announcements

<fjh> am Randall scribe then Tim

Dan Whaley: with Hypothesis

Kristof Csillag: with Hypothesis

Gergely Ujvari: with Hypothesis

Takeshi Kanai: I'm Takeshi Kanai, with Sony

<azaroth> Rob Sanderson, Stanford, co-chair with Frederick, co-editor with
Paolo on the model, editor for protocol (and happy to have a co-editor :) )

I am interested in implementing the outcomes for this device (holding tablet
device)

We are trying to also read Web documents on this device

Randall Leeds: I'm Randall Leeds, also with Hypothesis

Jon Udell: I'm Jon Udell, also with Hypothesis

<RayD> Ray Denenberg, Library of Congress

<tbdinesh> .present +TB_Dinesh

<TimCole> Tim Cole (TimCole), University of Illinois and a founding member of
the Open Annotation Community Group

Phil_Desenne: I'm Phil Desenne with Harvard University

bigbluehat: I'm Benjamin Young, I'm with Hypothesis. I like APIs.

<fjh> Annotations at Europeana

<fjh> [https://lists.w3.org/Archives/Public/public-
annotation/2015Apr/0103.html][21]

TimCole: There are a number of different people working on different pieces.
There has been annotation in Europeana previously, but there seems to be a

<scribe> scribe: tilgovi

<TimCole> There seems to be a new push to bring annotation into the core of
Europeana, which is good; glad they're paying attention.

fjh: Ivan is not here, but there's this whole space of ebook related stuff
that maybe we should address and other things that we need to revisit that we
haven't done

Does anyone else have anything to offer the agenda?

TB asked how this comes together with other things like social but I think we
have a pretty full agenda

bigbluehat: I wanted to know who was here yesterday. The social web is looking
at SOLiD, a social web linked data thing. I wanted to know if it came up at
all.

... the social WG is looking at several different protocols, but SOLiD seems
to have a lot of iteration and the most overlap with us because it's LDP

fjh: We're going to move on now, to the LDP recap

### LDP recap

azaroth: yesterday there was a meeting of the LDP WG, about the same number as
here today

... including Arnaud Le Hors from IBM and bar from Oracle, as well as myself
and Dinesh and Takeshi

... main work was finding out the status of what everybody is doing

<fjh> Patch

azaroth: relevant bits for us, the LD PATCH work is

... to send updates to a resource rather than completely overwriting it, like
SPARQL update and JSON PATCH and diffs

<bigbluehat> SoLiD API proposal (based on LDP) from the Social Web WG:
[https://github.com/linkeddata/SoLiD][22]

azaroth: but for linked data, where we might have blank nodes, and other
things

... that has all the boxes checked to go through to technical recommendation

... However, the third part, LDP Paging, does not

... At the moment, there's only one implementation, and the framework for a
test suite

... but needs a second implementation and test implementation to demonstrate
interop

... The status at the moment is that it would be published as a WG note,
rather than a TR

... If we want to make normative references to that, if we as a WG think
that's the right way to go for paging through sets of annotations, that would
help us a lot in the future because then it could be a TR that we could refer
to

... The other thing addressed was the rechartering process. We tried to gauge
interest in the different topics that had come up for a second round of work.

... The topics that were most interesting were discovery (of containers,
endpoints), which we need here, and extensiblility, so if there were a new
capability that a server implemented there might be a way to link to that
documentation of what it can do

... There was a lot of discussion about filtering and query, which we've been
discussing here as well, and it's promising that that is ranked highly

... The third area was access control

... Seems like all of the LDP 1.1 focus would help us in the Annotation WG

... Unnerving issue is that the current chair cannot commit to being a chair
in the future WG, so we would need to find a new chair before we could
continue

<Zakim> fjh, you wanted to ask about benefit of referencing LDP, interop
benefits, risks

fjh: I've been asking myself "what is the benefit/risk of having a dependency
on LDP?"

... if what we're deploying is mostly just some REST then what do we get

... my understanding is that some of what's in LDP we don't need

... my suspicion is that if paging is a note there will be no interop testing

... so we have to make interop testing for that

azaroth: For the basic containers there is a test suite and we would be able
to bridge a lot of tests and implementations

... I think it's worthwhile. Especially on the last call, we discussed that
paging may simply fall out naturally from querying or relate more strongly to
paging than the general LDP paging

... other advantage is that we wouldn't need to specify all of the base level
interactions like what is PUT, POST, etc

... Really just a profile of that where what you're seeing is an annotation

fjh: if it hadn't been done, I would be concerned about creating a dependency
if we were going to do it anyway

shepazu: because this isn't my area (that part of the stack) I'm not really
comfortable knowing if LDP and ActivityStreams... where they overlap, compete,
etc

... I know there were people who attended the annotation workshop from the US
gov't who said 'we have to do ActivityStreams'

... is ActivityStreams in the same space as LDP or not?

fjh: There were three ways social was looking at doing protocol, LDP,
ActivityStreams, and Micropub, so the LDP stuff would be a profile like what
we're doing

... I'm not familiar with SOLiD

bigbluehat: SOLiD spun out of the last Social WG F2F, possibly mixing in some
SPARQL stuff

fjh: I thought micropub was the one that had legs in the group

bigbluehat: the group is pretty fractured, but micropub has an Achilles heel
because it has no JSON-LD semantics

... so you would have to map it to an ActivityStreams output

... whereas the LDP-based one is JSON-LD, is AS2.0 ... James Snell has an
implementation, and then there's SOLiD which pulls in other things

... James' stuff is just LDP + AS2.0, but both use AS2.0 as currently written

... the other two have no knowledge of AS2.0, so there's a whole lot more work
to do to map it to the document that's been made so far

fjh: what is the time frame fro SOLiD?

bigbluehat: they are having a F2F in May in Paris.

... that was stuck on the board as a deadline for a fleshed out presentation

... they're getting decent iteration of it

### Client API

fjh: we have a bunch of stuff in our charter, some stuff we haven't talked
about much

... so one of the ideas for this F2F is to get those things moving

... one of the topics is the client side API, we should talk about what we're
trying to do and what the assumptions are

... I think we're talking about JavaScript using Web IDL

... I think we're talking about JavaScript using Web IDL

... The reality is that it just goes to JS now, but we still use it all over
the W3C anyway

... but that's what I think script interface means... JS described by Web IDL

... events means HTML5 Events

... "in a browser" means we're talking about asynchronous interfaces that
probably use Promises

... reading system is another item in the list

... I think that means we want support for offline and synchronization, but we
should talk about how far we have to go in that work

... I'm not sure what a plugin means except that it's an incremental
deployment strategy

... to do the implementations without getting browser buy-in immediately

... So what's the core functionality of the API?

... I think it includes some basics that are similar to the protocol but it's
not the protocol

... I don't think Social WG has a client protocol in the same way, so when
they say Client API they mean the protocol

... We want to allow to do things in a client application, something different
from but integrated with the protocol

... I think you're working with the JS in the page you're at, which has
security implications

... Doug has work on a robust anchoring API, we'd probably want to integrate
with that

... Local caching seems important, whether it's in the API, I don't know

... The authentication, OAuth, seems important, I don't know if it's ours but
maybe we have to make recommendations

... then search, which is probably an API method as well

... We have to do sensible HTML5 integration, which means a bunch of best
practices for writing APIs

<bigbluehat> on the earlier API note, here's James Snell's LDP-based
ActivityStreams API code: [https://github.com/jasnell/dandus][23]

fjh: you should be able to have a server-side implementation and still do
stuff, a client API is not required in that sense

... I was thinking about the IndieWeb work and noting the requirements there
about server software simplicity, but I think this doesn't impact the client
API

... There's a lot of stuff going in with privacy in different W3 groups, and
one thing that has emerged over the years is the idea of user control

... sharing with the server expectations about retention and re-use of data

... we might want an extension point but I'm not sure we need to do much

... Do we need to say anything about UI implementation support in the API?

... Do there need to be methods to help associate CSS stuff with the
presentation?

... Do we need to integrate with social? I think it's beyond what we need to
worry about at the beginning.

... There's a list of requirements in a document from paoloC that might also
apply to the API

... What's the target URI, path, we have to be able to make these statements
in the API

... I'm hoping this will dovetail a bit with what nickstenn has been thinking
about

<fjh> [https://lists.w3.org/Archives/Public/public-
annotation/2015Apr/att-0121/ClientSideAPI.pdf][24]

<azaroth> Link to the requirements from DPUB use cases: [http://www.w3.org/TR
/dpub-annotation-uc/#requirements][25]

nickstenn: to be clear, I don't have a slide show that answers any of the
questions that fjh just asked

... this is not a piece of work with hours of investment, but it's a thing
we've been playing with on and off at Hypothesis

... it's one piece of what we're talking about

<nickstenn> [https://docs.google.com/presentation/d/1ZKSZyLbEFqwYaG32cFJwcXQjj
iU2ZzQguDmyhKfaTdY/edit#slide=id.p][26]

nickstenn: What I'm going to talk about is a little project that came out of
questions around how we make Annotator part of an interoperable ecosystem and
part of the work doing here rather than doing its own thing

... this component is supposed to answer, "What is the smallest, useful, low-
level component in a client-side API for annotation?"

... I'm talking about something that might be useful across different
applications but is not expansive in scope

... when we say "client side" API we envision something that would ultimately
be used in JS from the DOM APIs

... by "low-level" we mean that standardized APIs in clients should be lower-
level than you might at first think, because it's less likely that you'll
build something wrong even if other people have to do more work to make it
more useful

<azaroth> +1 to nickstenn

nickstenn: but if you give something higher level where there isn't access to
the nuts and bolts it may end up not getting used

... What I mean by 'annotation application' I mean some piece of software that
creates annotations, whether the user sees it that way or not

... for example, it could be the code that Medium uses to create annotations

... it could be an extension that lets you see who is tweeting about the
current document

... the point is that the state of the annotation applications lives with them
(in this diagram)

... DOM Annotations is supposed to be a layer over the document where the
current state of annotations on the document can live

... the idea being that the application(s) can use that and potentially see
the annotations created by other annotation applications

... When I say "state", I am specifically talking about the state of
annotations attached to a document at a current point in time in a given "page
load"

... Not storage, not retrieval, not persistence

... This is like when you open the inspector and see the styles and DOM
elements

... as a developer, you might ask, "How do I attach annotations to (parts of)
the document?", "How do I retrieve annotations associated with (same)?"

... and, to riff on what fjh said, most HTML APIs are event based

... so, "How can I be notified when annotations are attached/changed/removed"
even by pieces of software I don't control

... DOM Annotations tries to answer some of these questions

<JakeHart> [https://github.com/nickstenning/domannotations][27]

nickstenn: "straw man" proposal, pick holes in it:
[https://github.com/nickstenning/domannotations][27]

... This is all it is, it's not large

... currently implemented as a polyfill, in the sense that you load a library
and it attaches stuff to existing pieces of the DOM API

... it is intended to mimic existing APIs

... one of my questions is: "is that a good idea"

... some argument from consistency says "yes" but whether that's the best
practices at this point is not clear

... Three functions on the document object (we can argue about whether that's
the right thing):

... createAnnotation(), no arguments

... as document.createElement() creates an element but doesn't attach it to
the document, this is essentially just a constructor

... getAnnotations(), at the moment takes an array of Nodes, is the querying
part

... it asks what annotations are attached to the nodes

... lastly, removeAnnotation() is probably fairly obvious

... In the current implementation, Annotations are first class objects just as
Nodes and Elements are

... At the moment, they don't do anything interesting, just enough to work

... they have two methods, addTarget() and addBody()

... Targets are also, currently, first-class objects you must, yourself,
construct that reference parts of the DOM

... If you are familiar with the Range APIs...

... a "Text" target might be a wrapper around a Range

[https://dom.spec.whatwg.org/#ranges][28]

nickstenn: There are also some events: 'annotation{create,change,remove}'

... these are fired on the Document

... 'annotationcreate', it's worth noting, at that point nothing is attached
and there is no data for the annotation

... 'annotationchange' says it changed, someone added a target / removed a
target, etc

shepazu: At that point, would the event bubble or would it simply be on the
Document?

nickstenn: At the moment it's simply on the Document

... the first time I did this I made it bubble, but there are problems we can
discuss with that

... 'annotationremove' is probably straightforward

fjh: I assume this means that I could have an event handler, and then update
the server if I want persistent storage

... so the event model is elegant in allowing you to do these things as you
see fit

nickstenn: precisely

TimCole: so if I remove it, I'm removing it from "this document" and it says
nothing about what's happening on a server

nickstenn: Yes. There is a distinction between change and remove vs update and
delete.

... change and remove happen within the document, but update and delete are
user actions with effects elsewhere

... it may well be that removal denotes that you want to delete it, but it may
not

shepazu: conversely, if someone made an annotation, remotely, and they delete
it, it wouldn't be removed in your local document

azaroth: as well as the persistence layer, you would need this for the user
interface layer

nickstenn: some of these discussions we might want to have more informally

... "how would you write a persistence module that watches these events and
saves annotations elsewhere"

... "how would a user interface module that wants to draw highlights on the
page and remove them"

fjh: I like that it's simple and it's consistent with what I've seen about
events

... is Server Sent Events a rec?

nickstenn: Again, that is something you as an implementer might integrate with
this API to handle events from a server

... <demo>

<bigbluehat> Server Sent Events specification:
[http://www.w3.org/TR/eventsource/][29]

<bigbluehat> EventSource is the browser-side API name for dealing with Server
Sent Events

nickstenn: When I select text, I use the same methods to detect the selection
that I do in Annotator

... but then I create an annotation (using the createAnnotation API)

... The highlighter, though, is a separate component, that listens to the
annotationchange event and enumerates the targets and draws some highlights

... At the moment, this is a polyfill, so it's kind of a hack on a stick, so
they are DOM CustomEvents

... this would be something we actually specify in WebIDL

... when I click on a node, I'm using the getAnnotations API to get the
annotations on that node

... and then using the removeAnnotation to remove the annotations

... the highlighter then listens to the annotationremove event, and removes
the highlight

<bigbluehat> text/event-stream is the Media Type for the text format sent from
the server: [http://www.w3.org/TR/eventsource/#text-event-stream][30]

shepazu: With the getAnnotations, let's say there are two annotations that are
on a particular span

... what if I wanted to get all the annotations on a particular section?

... the node that I'm clicking on has annotations with it as its target

... does it also work for getting all annotations within a node

nickstenn: what you have described is "given a node, show me the annotations"
but a lot of real world applications might want "given a chunk of the
document, give me all the annotations"

... I think the answer to that is that it's low level, and getAnnotations
takes a list of DOM nodes

... you can use existing DOM APIs to enumerate the nodes in a paragraph and
then pass that

... If anyone wants to know what's going on under the hood, I can walk them
through the code

... It's worth stressing this is a low-level API it is not meant to be pretty

... there are lots of edge cases you need to address if you're writing an
application that uses this

... but the advantage is you can serve all scenarios, even if it is more work

... This is not intended to help with storage, persistence, or retrieval.

... it is not intended to help with fuzzy anchoring, or taking a serialized
annotation and finding a bit of the document.

... and it is not necessarily intended to help with serialization

... that is one of the more interesting questions, I think, trying to
understanding how the serialization would work

... is there a way we could do it completely orthogonally to this piece

... This is merely a reflection of the "annotation state"

... Open questions for the group

... does this "smell" right? should it be imitating other APIs with, for
instance, createAnnotation API

... Events vs Mutation Observers?

... This deals with "reified state", references to bits of a live DOM thing...
is this the right thing for it to be doing?

... How does serialization work?

... Lastly, this is not a bulk API. Does it need a bulk component? How would
we find that out? What performance testing would we need to do to find out?

shepazu: First, thank you for putting this together.

<fjh> orthogonality is good

shepazu: I think it's orthogonal to something other things like the
RangeFinder, I like how you went low-level

... another reason to do that is because you can compose it up into other
things

<fjh> modularity, testability etc are useful

shepazu: that's very much the trend the right now

... things like the CSS Houdini project is trying to give CSS more explicit,
lower-level components, so I think your instinct is right

... I think it does smell okay

... in your model, is the event only sent when someone does something via
script? or does it also change when the underlying DOM changes?

... If I have a target and that target goes away... that's when you start
getting into mutation

... This thing is a meta-thing on top of the document, so it doesn't change
the document itself, so you wouldn't get into loops

... but for utility sake, if the target of an annotation changes I might want
an event, but then it might get us into mutation observers

nickstenn: I don't have a whole answer, but at the moment the events are
triggered by user (script) actions on the annotation only

... for the benefit of people who have not run into this before, let's say you
do have a long document and things are popping into and out of existence as
you scroll, that's a real example of where you might attach an annotation to a
document and then the piece of document where that is attached just disappears

... that at the moment does not cause any problems, because the annotations
are attached to the DOM elements

... and if the elements are released the annotations go away

... If you have a reference to the node, you can get the annotations,
otherwise you can't use the API to get to the annotations

shepazu: what if I create a node, create an annotation, and then attach the
paragraph to the annotation as a target, and then insert that into the
document

... does the node have to be in the document

fjh: A big thank you for all this work, it helps move stuff forward.

... my instinct is you're doing the right thing

... you want to keep it simple and we can do separate specs to build on it

... we want it to be testable, modular, usable, so I think it's the right
approach

... I would suggest when we have a draft spec we can run it by the TAG and get
feedback, so I think we can ask the right people and get feedback in no time

<Zakim> fjh, you wanted to ask about server integration

fjh: Just because we do one thing that's simple doesn't mean we can't do other
things on top

TimCole: Right now you have the annotation, addTarget and addBody, right now
those are the only two methods

... the fact that the target can encompass multiple nodes is interesting

... the next question is, what's the functionality for multiple targets or for
removing a node within a target, are any of those things there yet or are they
priorities?

nickstenn: A couple questions in there

<fjh> I recommend we start simple

nickstenn: other properties, absolutely. If we're going to have an Annotation
class it needs to actually support the pieces of the model

... multiple targets, this does multiple targets

... you can do addTarget multiple times

... If I remember correctly, addTarget gives back the Target object and then
you can remove that object

... and what happens if the piece targeted changes, I don't think that matters
until serialization time

... and that is why DOM Annotations doesn't, in the general operation, need to
worry about that

paoloC: I have a few points. My first impression was "this is really neat".

... my second reaction is that I'm worried about the complexity of the model
and that possible the body and the target are open ended

... I'm sure we can extend to accommodate this

... how do you feel about complex highlighting, overlapping, nested, all these
complications

... is that all still orthogonal?

nickstenn: I think that is a completely separate issue

... DOM Annotations lets you attach as many annotations as you like to the
same piece of the document

paoloC: But if you have not nested annotations you have to break them down in
the document

nickstenn: I think you have to be careful not to consider it the same as
creating highlights in the document

... this is a separate problem

paoloC: then I was worried about the dynamicity of the documents.

... I agree that the part that could be hard is the storage

nickstenn: My personal mental model of how we're going to do this stuff is
that we may have to think about storage as being a bit more of an op log
approach than a CRUD approach

... someone is creating annotations in a changing document, the storage
component might simply be watching that and then by some heuristic might
decide at some point that we're at a place where we can save that off to a
remote server

... if you like, you create the annotation once and that's the right
annotation and then it's the responsibility of the persistence component to
know that the annotation might need to be updated when the annotation does
change

paoloC: I'm worried about actions and the difference between document pieces
loading and document pieces getting deleted

... I think if we had to use this in a framework I would have to duplicate
some functions in the code

... talking in particular about ReactJS

tbdinesh: The way I see an annotation happen is that there are first
selectable objects

... if you can't select you don't have targets

... could be text but there are lots of other things

... so what is it that makes something annotateable?

... is how we select something

... I'm not sure this is the smallest

nickstenn: I think you're right, if you can't select a piece of a document you
can't annotate it

... to address the issue directly, I think that's true, but there is an extent
to which that is not the problem of this component

... how does the user interface work? not the problem of this component.

... what this component needs is a Target object, which is some domain object
that provides a reference, if you like, to the thing you have selected

... possibly also a way of serializing that

... and what this deals with is Targets that are themselves Nodes in an HTML
document

tbdinesh: would it be simpler if you didn't do selection across the DOM
elements

nickstenn: so you're saying that the ability to create a target that spans
multiple elements in the document means this isn't the simplest thing

... I think that's interesting

<fjh> how does fit with create body first then add targets model?

nickstenn: my gut tells me when a user annotates an HTML document they're not
thinking about elements and the DOM tree

... they're thinking about a "logical document"

... if I'm using MS Frontpage it might span 500 elements for no apparent
reason

... that's why a target can refer to a range, which can span multiple nodes

shepazu: Target is not yet defined, as far as I can tell. It might be a Range
or it might be a section of a 3D document.

... I can't pass an event on the 15th second of a video, but we can target
that

tbdinesh: I think we need to think a little bit lower

nickstenn: I think we're all saying the same thing

tbdinesh: this is to do with elements that are not part of the document

... one thing we do is to make annotations that are navigable for a page that
is not accessible

... (talking about accessibility)

... You change the page through your annotation, and that is the page your
annotations work on

nickstenn: I think what you're describing is annotations of things that don't
exist exactly in the document

tbdinesh: To clarify, there's a DOM Element and it's not identified as part of
the navigation

bigbluehat: I think there are more pieces that aren't presented here, and this
is the DOM surface area, which comes and goes with the DOM state machine

... there's got to be other pieces

... there's a growing contingent that want to get rid of the DOM state
machine, and want a different sort of expression

... but for the thing that we have, I think this works well

nickstenn: the thing to do is for us to identify the use case we're
describing, make sure that the use case is recorded, so we can ask "is the
thing that we've built going to cover the use case"

fjh: "Are we clear on what the goal is"

<fjh> Scribe: TimCole

nickstenn: from an accessibility perspective you may wish to annotate parts
that are not in the document

<fjh> Much thanks to Randall for excellent scribing

shepazu: let's i have an image in my document, but no alt tag. now i want to
attach a description for accessibility

<RayD> (lost connection, rejoining)

shepazu: this is an annotation. you would create an annotation attach to image
and add a body which is the description

tb: I annotate to change the DOM in order to support accessibility

bigbluehat: use case coverages -- paolo and i do use cases, mostly protocol to
date. need help on client-side use cases

... what doesn't DOMAnnotations handle, i.e., non DOM State Machine
annotations

<nickstenn> the use case to capture from above was "Annotate elements that
aren't in the document in order to indicate that they *should* be. As a blind
person, I want to let the page author know that a <nav> element should be
present in the document, so that I can navigate with a screenreader."

bigbluehat: what about all the annotations I got from the DOM, and now I want
to do client-side persistence.

... what are the additional pieces we need to address?

<Zakim> azaroth, you wanted to ask about multiple targets and destroyed nodes

azaroth: when the node is destroyed, would the annotation be destroyed?

... want to have multiple targets, one which is in view, the other goes out of
view, what happens to the annotation

nickstenn: the annotation doesn't go away until the target count go to zero

azaroth: in the process of adding targets, the problem is that if your first
target goes off screen before you get to the second target. There is no longer
an annotation to which you can attach target2

<fjh> discus son of whether annotation is lost when attached to DOM if page
scrolled beyond the point of that annotation

shepazu: the annotation is temporarily stored in the DOM, but the annotation
application could maintain the annotation even when the part of the DOM to
which it is attached has gone out of scope

... but my annotation application could still be stored in the application and
the application than reattaches it to the DOM when the node comes back in
scope

csillag1: trying to imagine going from current model to DOM Annotation

... current system handles some of these use cases because it operates at a
level above the DOM

<azaroth> Situation to check back in on: An annotation that is being created
should have two or more targets. The annotation is created, the first target
is created and added. Then the page is scrolled such that the first target is
out of the viewport and the element gets destroyed before the second target is
added. [+]

csillag1: so the client application could talk both to the DOM Application and
to another module, the anchoringManager

nickstenn: one example is annotation of PDF using js. When you do this not all
of the pages of PDF are available at the same time

<azaroth> Two things to determine: Is the annotation object's existence
maintained by the JS application's reference to it, even if the DOM node is
destroyed? And (2) are there sufficient events that the annotation's first
target can be persisted or re-created when the element is recreated by
scrolling back to it.

nickstenn: I would argue that annotating all occurrences of spatula in a PDF
is out of scope for the Client API

... you could still do this using pdf.js in conjunction with an annotation
ClientAPI

shepazu: need to understand what is done by the Client Application and what is
done by the Annotation Client API

nickstenn: if you are building an annotation application, you will have to
keep track of nodes that come in and out of the DOM, not expect the ClientAPI
to do this

fjh: how do we talk about this?

<fjh> need to capture that work may be required to match low level API and DOM
model to user use cases, need to clarify use cases

shepazu: in order to accomplish the goals of the user, we need to break it
into its constituent mechanical parts

<fjh> example - user wants to annotate all instances of a word in document,
yet only portion of document displayed

shepazu: there will be lots of moving parts

nickstenn: DOMAnnotation is a library to be used by an Application

fjh: the Application builder has to deal with matching the user use cases to
the capabilities of the underlying library and DOM implementation.

tb: accessibility use cases- does it make sense to have blank node targets?

... say I want encryption for my annotations

... what is inside the annotation is only relizable after decryption.

<fjh> encryption is another example of application logic vs underlying library

nickstenn: another example - it should be the user right to annotate documents
over which they have no control, and they may want to do so in a way that may
not be visible to document owner

<tilgovi> I think this a great example of where privacy issues that fjh
alluded to become real

nickstenn: so there are some serious security issues and use cases

... for example, I am a human rights lawyer investigating abuses and looking
at a document on a company website

... I do not want people to run javascript on their page that sees my
annotations on that document

... another example, i can run code on a page to determine whether links are
purple or blue (visited / unvisited)

... that is a privacy violation.

... how do we a DOM scope in which a user can create annotations not visible
to javascript already on that page

<fjh> issue - DOM scope for user to create annotations that are not visible to
hosting server page

shepazu: conversely how do allow page javascript to see annotations that I've
attached to the DOM

nickstenn: invite someone from WebAppSec

shepazu: so this is important that one option should allow annotations to be
created without modifying the DOM

tb: in other cases you do want to be able to modify the DOM

shepazu: so, should be able to modify the DOM or not according to the needs of
the users

tb: another use case - re-narration.

... this allows users to see alternative narrations that they can understand
better

... different renditions of a page

<fjh> also suggest we invite privacy interest group as well

tb: we tend to get shutdown notices because it looks like phishing

nickstenn: the issue is that we're using annotations to re-write pages for
some users

bigbluehat: there are other, possibly more appropriate technologies that could
do this (XSLT)

tb: took us through an example page

... so here's a page in English

... here's a way to get to this page rewritten in a different language

... so can this happen at the client (to avoid server being blocked)

nickstenn: this is essentially a translation use case

... I don't think this poses any issues for us

... so on the client I can mutate the page once I load it

... so as a user I can apply an extension to do this same thing

... so yes, an annotation applications should be able to do this.

tb: another use case is cascading annotations

... so a user can see the first layer of annotations

<fjh> server side only annotation system might not work, in that annotations
could replace text and then page treated as phishing attack (?)

tb: and then can see a second generation of annotations

... this is about how annotations of the same target are dealt with

bigbluehat: like an RSS feed for annotation

nickstenn: this is an interesting model of how annotations are related to
other annotations, but this is higher level than the annotation ClientAPI

... there doesn't seem to be a problem here, but we need to check it to make
sure

bigbluehat: as a reader i want to aggregate annotations of a target, and then
I may want to see only the net result of applying all of these annotations

... please add use cases to the wiki

... we need specifics, e.g., annotations as transformations

<bigbluehat> [https://www.w3.org/annotation/wiki/Use_Cases][31]

shepazu: comments on DOMAnnotation - re the question about how does Nick's
proposal work with mutations of targets?

... my intuition is that in order for an application to detect that a target
has mutated, perhaps we should use the mutation observation rather than
something annotation specific

... so when a mutation observer event is raised, the annotation client can
check if the target has changed

nickstenn: should annotation change events fire whenever an annotation may
have changed? Right now they don't. If a word in the middle of the target
happens, no annotation change event fires.

... not a design decision but an implementation choice

<fjh> we need to document the use cases in enough detail before detailing
solutions; however understanding the solution space in advance can also be
helpful

nickstenn: I suspect that the answer to your question is either annotation
application builder wants to know when serialization of annotation has
changed, alternatively you could set your own mutation observer monitoring

... we should try to answer this by looking at specific use cases

<fjh> nickstenn: developer use cases should be focus

shepazu: when something doesn't have to be annotation specific we should favor
that approach.

<fjh> principles - doug - when not necessary to have annotation specific
solution try to use general solution

shepazu: is there a generalizable use case for specific set of events you
describe, i.e., more generalizable than just annotations? If we can make it
generalizeable

... we should.

... if we have a footnote mechanism where the footnote is in the DOM, can we
characterize it as an annotation.

... so when a footnote is created or comes into scope, can we use the
annotation Client API to handle footnotes

<azaroth> +1 to Doug's question

<fjh> is question to convert existing footnote into annotation later?

paoloC: or you considering adding microdata to the DOM as a kind of change
that would trigger an event of interest to annotation API

azaroth: should embedded annotations of things in the page trigger the
annotation API?

fjh: are you suggesting that a document containing footnotes would then be
treated as annotations when loaded?

shepazu: yes, you could load a wikipedia article with references (notes) and
so we could treat these as annotations

... don't know if this a good idea, but we should talk about it

nickstenn: related Rob's question, if you have annotations (clearly labeled)
as such embedded in a document, should annotation events fire?

<fjh> issue - how can annotations embedded in doc be handled by client API,
also can heuristics be used to recognize footnotes

bigbluehat: Aaron and I are the only ones other than Nick who has used
DOMAnnotation. There are additional pieces of a complete annotation client API
- we need to decide what those other pieces are

<fjh> bigbluehat: define boundaries, what is provided by browser vs what
application needs to do

bigbluehat: we need to decide where these other pieces live, e.g., in the
browser, on the server, between servers, etc. client side API is probably not
sufficient.

... so DOMAnnotations doesn't address plain-text annotations, image
annotations, etc.

... so in a similar fashion that we have named things in the data model, we
know need to clarify our nomenclature.

fjh: we can benefit from going back to Web IDL, etc.

bigbluehat: so in using DOMAnnotations I had to go to back to XPath and so on
to find the target in order to give it to DOMAnnotations

fjh: so I have to execute the protocol and then handle all sorts of additional
steps before I hand it off to DOM Annotations

bigbluehat: which ones are ours to worry about and which are elsewhere

nickstenn: we can formalize DOMAnnotations, but concurrently we can also
define the other pieces

bigbluehat: need to map out what's left

... DOMAnnotation is one piece of an annotationAPI

<Zakim> azaroth, you wanted to ask if annotations can be referred to in
Annotation#addTarget()

azaroth: DOMAnnotations, an annotation is created, can that annotation then be
used as a target for a later annotation?

nickstenn: how do we decide what target types are in scope?

... more specifically what target types are in scope for DOMAnnotations

shepazu: is the annotation created by DOMAnnotations addressable as a DOM
node? and should DOMAnnotation be able to have targets outside the DOM?

nickstenn: DOMAnnotations does not support the full annotation model, and we
should not try to support through this API targets outside a rendered document

<fjh> need to clarify scope of each work item, e.g. DomAnnotations on specific
rendered document

azaroth: so for a reply to an annotation you might need a separate API that
works at a higher level to allow access to the annotations outside the DOM

nickstenn: using DOMAnnotator to annotate annotations opens the door to
annotate almost anything outside the DOM

tilgovi: DOMAnnotations is meant to address a subset of the data model
supported use cases

<fjh> open question of degree of annotation functionality is to be supported
by DomAnnotation and need to document

shepazu: what about the use case of annotating a node that has been created
but not added to the DOM (yet)? It would be useful to allow creation of
annotation that may have to do with something not attached to the document but
related should be okay

<fjh> need clarity on required model and limit to features

nickstenn: my implementation says that a target is a first class object that
refers to nodes in the DOM that I can query.

... as implemented targets are things that have list of DOM nodes

shepazu: we may need to define an annotation object as having more flexible.

bigbluehat: let's take DOMAnnotations and attach to use cases, see what use
cases are not covered, and then deal with those.

fjh: actions. Nick will write up DOMAnnotations up to an informal spec

**RESOLUTION: Proceed with DOMAnnotations based on Nick's initial work**

<fjh> **ACTION:** nick to prepare initial draft of DomAnnotation [recorded in
[http://www.w3.org/2015/04/22-annotation-minutes.html#action01][32]]

<trackbot> Created ACTION-10 - Prepare initial draft of DOMAnnotation [on Nick
Stenning - due 2015-04-29].

<fjh> **ACTION:** bigbluehat documenting use cases [recorded in
[http://www.w3.org/2015/04/22-annotation-minutes.html#action02][33]]

<trackbot> Created ACTION-11 - Documenting use cases [on Benjamin Young - due
2015-04-29].

<fjh> **ACTION:** azaroth to add creating buckets for client side annotation
support to next agenda [recorded in [http://www.w3.org/2015/04/22-annotation-
minutes.html#action03][34]]

<trackbot> Created ACTION-12 - Add creating buckets for client side annotation
support to next agenda [on Robert Sanderson - due 2015-04-29].

<MiguelAraCo> My name is Miguel Aragón, and I'm a member of the LDP Working
Group

<shepazu> I'm Doug Schepers, W3C, one of the staff contacts for this WG

<bigbluehat> I'm Benjamin Young, Developer Advocate for Hypothes.is.

### Minutes Approval

<fjh> [http://www.w3.org/2015/04/15-annotation-minutes.html][35]

<JakeHart> My name is Jake Hartnell, and I'm a designer / front-end engineer
at Hypothes.is.

**RESOLUTION: Minutes from 15 April approved.**

### Agenda review and update

fjh: should discuss what it will take to release protocol as FPWD

... need to talk about search, including SRU

... talk about Robust Anchoring

shepazu: would like to do something similar to what Nick did in explaining
where we are

fjh: protocol, footnote, anchoring, search

### Protocols

<fjh> Scribe: tbdinesh

<fjh> ScribeNick: tbdinesh

azaroth: we have a very draft version of the protocol. do we want to discuss
and go through how it works now?

<azaroth> [http://w3c.github.io/web-annotation/protocol/wd/][20]

fjh: in the end there was a query section that need to be removed

... my comments would be to get rid of ??

... get rid of blah blah and activity streams

... target of assertions is the server

... ?

bigbluehat: rob, perhaps you could do an elevator pitch

<azaroth> [http://w3c.github.io/web-annotation/protocol/wd/][20]

bigbluehat: what does it not do and a bit about what it does

<fjh> remove notifications and query section, remove mention of activity
streams, remove 'blah blah blah' text, add clarification of test assertion
targets (server)

azaroth: the purpose of the protocol is to allow clients to communicate with
the server

... to create to delete.. assumes REST as the core principle

... in order to avoid such questions LDP platform exists

... 1st section about containers. containers taken from the LDP spec

... LDP does not use REST for such as how do you find containers that exist

... full tech reco on undating a PATCH

... you can update it with PUT - but to change you do a PATCH

... LD PATCH but there are other PATCH such as json PATCH

... SLUG my_annotation CAN rather than SHOULD

paoloC: i am currently using a RESTful approach

<fjh> i/.*very draft version.*/Topic: Protocols

paoloC: in my case i use an approach to insert new annotations - is that done
with a PATCH

... i need to understand annotation vs a container

azaroth: i see container as an end point where annotations are mainted

... you cannot use PATCH to update all of the annotations in a container

paoloC: if you want to replace all items

azaroth: you need to do one by one

paoloC: to update an annotation with in a set, it goes into an it. that would
not be possible?

azaroth: that's correct

... we need to talk about what are the operations to perform such things

TimCole: 3.1.1.1 is there a size cap to page

azaroth: lets do it away

... i think the question is if the LDP grp publishes paging as note? we shd
formatively define it

shepazu: there is no impl

azaroth: as Ray was saying we might pull of paging

TimCole: i have an annotation server. i might have data for annotations

... is there any virtual?

azaroth: say you have URI example.org/ will create /1 /2 what ever

TimCole: we don't have an impl today. can we do this without modifing..

... am just wondering if we go to FPWD right away

... it not really that forbidding but it looks a bit

fjh: publishing as often as possible - i was suggesting

paoloC: i feel uncomfortable going ahead with knowing - if you dint what does
that mean for us - do we want to go with it

bigbluehat: there are a few LDP impls. Apache has 5 i think

... if you have LDP server xy or z these are the tweaks that we make..

... in many cases there will be 1000s of anno in a collection

... we are thinking of 1 per user

... i think we need a discovery mechanism

... my atom feed say my edit location is ..

... we should prefer json PATCH over LD but both should be possible

... we also need to define some sematics around containers - how do they come
into being go out of being..

azaroth: agree. if we can find one that is 95% available we make that ..

... js side to impl client side is trivial

bigbluehat: i can propose some rephrasing

azaroth: json PATCH yes. we shd look at various PATCH formats

... defining new containers.. LDP has a way to do that

... there is a preferred header as an interaction model (so can choose)

Mitar: annotation could have children annotations like css cascading

... annotation can have membership triples.. with related containers?

azaroth: these are the reasons we shd keep LDP as one of the things

bret: server is going to support the protocol if atleast..

... my view you can profile it as an annotation container. if so they don't
have to go discover (??)

... with respect to discovery there is mech for discovering resources

bigbluehat: in a more is distributed.. like with bloggers.. they need to
discover they were there

... from the blog post you need to discover if its part of the bigger
collection.then here is how atom feed is editable.. adom mostly ripped off of
rel

... hopefully there is feed format

... but those shd not assume that they are within ok-url??

???: abt search

scribe: you guys are aware of the new hpc? search

bigbluehat: briefly currently in the protocol .. right now you come to
protocol;l doc and say ah i want to use sparql.

... if that was separate i an pick and choose

paoloC: have a lot to say. hv been anno sets since very very very long time

... they have a lot to say. you can org anno in whatever criteria you want

... like playlists

... the reality it cannot be a single concept. can be very powerful

... i heard SPARQL i heard graphs

... ?? same annotation can belong to mult containers and can have mult uris

... the way it gets impl in sparql is diverse and even assumption on that can
be complicated

... annotation can belong to mult containers and it may not be my
annotations.. so what does change mean?

Mitar: containers contain relationships as a member

... you can go all the way and say i dint want.. blh blh

paoloC: is this in the protocol

azaroth: its not and i will..

TimCole: you don't want to rewrite it

azaroth: 4 sent so we have something readable

... ... you can direct, indirect, playlist like , .. it would be diff
interaction than creating an annotation

paoloC: i don't want to reparse the entire set

entire

<azaroth> ScribeNick: azaroth

tbdinesh: How do you discover a container dynamically?

<fjh> Scribe: fjh

<scribe> ScribeNick: fjh

tbdinesh: how to discovery containers when encrypted

<scribe> Scribe: tbdinesh

<scribe> ScribeNick: tbdinesh

azaroth: 3.1.3? discover of anno containers

... there are a few way you can link to . if the owner of an image wants to a
spec container you can link it and follow that link

... containers can point to other containers

<fjh> ScribeNick: tbdinesh

azaroth: if you have entire server with 1000s of containers you can link to
known other containers for you

... we can easily get rid of the rec?

... potential options such as well known uris

... [ ] redirects to .. bejamin do you want to speak up against it

bigbluehat: there was this piece that was proposed to avoid discover. it was
dotwell-known instead of dot well known

... making it hard to discover

... i would be -1 on using it. discovery from anno is an optional thing

bret: uri in the annotation did not seem to be optional

azaroth: in json-ld terms

... that is one of the areas i made some additional req on top of LDP

fjh: so i thought i set my own person anno server

... seems logical to me that i want to retrieve annotations for a specific
domain

... is this an annotation set - i am confused. my usecase is about easily
retrieve and manage anno on a given domain

... shd the protocol allow me to deal with specific domain

azaroth: will get rid of any notion that hinted that there is only one
container

TimCole: some people want to do it by name of person some by tags some by url

bigbluehat: that is why uri are imp there is no way we will fig it out - all
cases

paoloC: when ilook for annotations i query give me all anno that target that

azaroth: it does provide a use case for how to provide mult containers

shepazu: whole idea of uri being opaque bothers me

azaroth: client shd not read meaning into the stricture of the uri

<bigbluehat> Web Axiom [https://hypothes.is/a/5DScCXXnTNeJ0uBWpu1cyg][36]

;ast two ??? ares dwhly to shepazu

bigbluehat: james snells ldp based impl - he is doing the same for activity
streams - we dont want to require the context not rdf.. then we assume one. do
ldp container impl let you write plain old json objects

Mitar: you can actually do whatever you want to write

... at least carbon ldp impl impls.. you cannot replace cannot mess with them

bigbluehat: shall we rob do similar change

... container types: we might want to be clear about which ones we rec ppl use

azaroth: at the moment we only have basic ones

TimCole: i wonder if discover section should be called something else

fjh: yes be specific about the item, such as Container Discovery

shepazu: i am assuming one of these containers.. like the tags. my use case is
aggergators. i want to find the top comments from 15 diff anno services having
to do with ... i am like trolling .. looking for (i am not proposing ratings)
maybe for this site 5 is a good and the other 15 reshares. how would i be able
to solve that using your protocol_

azaroth: to me its an annotation set?

shepazu: i am not talking abt that part. what could an aggregator do to
selectively..

azaroth: i think it leaves in the search part and server interaction protocol

fjh: what action

azaroth: when we talk about search we keep this use case in mind

shepazu: we could make a note specifically geared towards aggregators.

<fjh> need to get aggregators to create set

Rayd_: i post an annotation and it will be on your servers right

azaroth: yes if it is a container

Rayd_: i can anno anything i want but no one else can get that

... whats the purpose

fjh: for me to create anno and not share

azaroth: i could have an image in my stanford domain say rob.jpg

... client would know this person wants me to post it there. normally i want
to post it some where. there is no hard linking.

TimCole: the resource of the anno may not know what the anno.

fjh: there is no guarantee that the target will remain

azaroth: i will rewrite to: any reco uri and can exist on any server anywhere

Rayd_: i think there shd be sec in the doc showing various scenarios

azaroth: an example at the begging would be good

shepazu: i look at an aggregator as it would store anno and dupl from else
where

... search engine is not holding holding the annotations.

bigbluehat: could be the protocol. could be feed format. could be more than 1
anno and it looks like this

paoloC: related to ebooks but in general there shd be criteria that shd tell
me if it can be published in a diff context

... index but does not store is prob okay

<fjh> s/stoer/store/

shepazu: lots of torrent search engines tell what the context is but do not
store

... that's why uri is very playable.. it goes away after a while

fjh: 2.5 hrs until 5 and we have 3 topics

... from process point of view it shd be published but we are not ready at all
today

<fjh> **ACTION:** azaroth to update Protocol draft based on F2F discussion
comments [recorded in [http://www.w3.org/2015/04/22-annotation-
minutes.html#action04][37]]

<trackbot> Created ACTION-13 - Update protocol draft based on f2f discussion
comments [on Robert Sanderson - due 2015-04-29].

<fjh> **ACTION:** shepazu to add aggregation use case to wiki [recorded in
[http://www.w3.org/2015/04/22-annotation-minutes.html#action05][38]]

<trackbot> Created ACTION-14 - Add aggregation use case to wiki [on Doug
Schepers - due 2015-04-29].

<fjh> Do we have counter-proposals to the Protocol

<fjh> Do we have volunteers to work on implementations to vett the Protocol
draft

<fjh> Tim Cole has group working on this, bigbluehat plans to work with James
Snell's draft to work on protocol as well

bigbluehat: my plan is to use james snel's code to impl protocol

fjh: if its not comprehensible enough we are not ready

<bigbluehat> scribe: bigbluehat

### Publishing

<fjh> ScribeNick: bigbluehat

TimCole: ...publishers want to be able to include footnotes in digital
publications

... had conversations with HTML5 about "footnote"

... no reason to use the model

<shepazu> thread on footnotes: [https://lists.w3.org/Archives/Public/public-
digipub-ig/2015Feb/0090.html][39] and blog post on requirements:
[http://davidmacd.com/blog/html51-footnotes.html][40]

TimCole: do we (annotation WG) have any concerns about this as a use case?

fjh: had a conversation with social web

... "everything's an annotation"

... he's sort of right

... but does it need to be?

TimCole: the concern I would add is that if we make a tag for footnote, people
would use it for all kinds of things

fjh: will they?

TimCole: we told them to hold off until we talked about it

... they end up having to solve some of the same problems (if they use the
tag)

... where do they put it? what goes into it?

fjh: that's not the author's problem, it's the implementors

TimCole: go ahead and use it then, and we can turn it into something richer?

azaroth: our primary use case is third party annotations

... party 3 talking about party 1's things.

... if party 1's talking about party 1's things, if they want to use
annotations, great!

shepazu: but what if I'm annotating something I made, but don't have control
over

azaroth: then you're not the publisher

shepazu: concerned by the "anything can be an annotation" argument

... I want to shut that down

... so it's clear what we're focused on

... I'm concerned that people think that we think that anything is an
annotation

... it doesn't have to be, so I want to keep the scope focused

... two things:

... - the digital publication working group

... "annotations are too heavy; we need something lightweight"

... (context is accessibility)

... I explained more, and think it didn't end up being an issue

... I linked earlier to the email thread and blog post that included more
footnote use cases

... let's say I have a document and navigate to and from the footnote

... how do I know what to go back to if the footnote is used multiple times

fjh: you could use a ibid?

shepazu: that's not very webby. people don't want to

<fjh> make three footnotes, use ibid

shepazu: CSS is also looking at footnotes and end notes

... where do we put these, how do we render them

... I'd like us to consider a <note> element

... it would contain all the things to serialize to the data model

... but in markup

JakeHart: this is something I feel strongly about

... footnotes are actually talking about something external

... and in annotation, something like an easy to use <note> element would help

... I come from publishing, and people there write markup

... if it maps back to something more powerful, all the better!

... they're often talking about external things

... it's important to map citations

... references

... in a more intelligent way

... so a footnote, note, element would be very helpful

... perhaps even comments about things that happen in the scholarly paper, etc

... I'd love something like a footnote, note element

... coming from the publishing world, are scared (rightly or wrongly) of the
complexities

paoloC: in Domeo, we've parsed all the footnotes and notes and stored
annotations

... the reason why we did all this work, we wanted to build networks of
citations, etc, all in the same way

... while doing that I realized "sure, all these things can be annotations"

... but I only did it when I really needed it

... and not push people to use annotations for everything

... some of these footnote issues are bad UI

... you don't need to scroll to the bottom of the page and come back

... it's not paper

... someone who publishes the resource

... can look at my annotations and knowing I'm the author can make my
annotations part of the content

... if we get annotation into the publishing process, we'd be entering a
forest

... where it's already overused / abused

... if it's already well defined, we shouldn't try to replace it

fjh: I think you were saying a footnote would be markup, and not technically
an annotation

paoloC: correct, but you should be able to parse it, change it, re-express it

fjh: the reasons for markup seem to be that it's legible, easier, something
people already do

... people don't just say "here's some markup" but "here's the model"

... if we got into that part of it, we could help define these tags in a way
that's compatible with our data model

TimCole: it is HTML5

shepazu: the HTML WG rather

... HTML WG is probably going to be a smaller group

... HTML Interest Group (IG) is a task force, larger group to route the other
pieces of HTML

fjh: so it's not going to be fixed in HTML5...HTML-whatever

... not sure who to talk to

shepazu: I'm not sure either

TimCole: they've not come back with more info

... this came up in digital publishing 'cause this is where it happens

... my sense, though, is that communication has died off about it between
those groups

azaroth: think we're in consensus that there should be a way to map markup to
the model

... so that everyone doesn't have to figure out how it was done, write string
parsers, etc,

... so to what extent do we have to be a part of it to point to how we'd like
it done

<shepazu> [http://www.w3.org/community/openannotation/wiki/RDFa][41]

<fjh> proposed RESOLUTION: support for markup to support footnotes but
consider noting relation to annotations

shepazu: so, I started this some time ago

... before the WG started

... it's not defined whether we go to them or they come to us

... I think we'll be asked, but we could also go to them and say

... "does this thing meet your needs"

... I found my RDFa attempts very frustrating

... I think we should have a friendlier way

... I consulted with experts

... and still got it wrong

fjh: I thought we'd go the other way where the markup came from the markup
related groups, and then we map it to the data model

shepazu: we're saying the same thing. as long as it maps, we're OK

fjh: I put a proposed resolution in the chat

... we should record some sort of decision

<paoloC> Examples of RFDa markup
[http://www.w3.org/community/openannotation/wiki/RDFa][41]

fjh: it sounds like we have consensus around markup

azaroth: let's clear the queue before we decide

takeshi: in Japan there's a special annotation

... Ruby Annotation

... to provide the pronunciation guide for Kanji

... on the Kanji

<fjh> [http://www.w3.org/TR/ruby/][42]

<JakeHart> FYI: Kanji are Chinese Characters.

takeshi: it helps younger readers to express the Kanji

shepazu: does everyone understand the Kanji problem?

... Kanji is not pronounceable directly

... the other kana's are

... and Ruby allows you to attach kana to Kanji to explain how to pronounce it

azaroth: is focusing on this going to help us know how to provide other
annotations?

takeshi: specifically, the Ruby Annotation has appeared on specific, unknown
words

... in the case that we need the representation, the ruby tag should be used

fjh: I'm loosing how this connects to the discussion

shepazu: some people feel we should consider changing to annotations for these

fjh: it's confirming the same thing we're thinking with footnote for mapping
markup to the model

azaroth: it shows how we might do it in markup

shepazu: we might talk to Mike Smith and Fantasai

... they understand Ruby really well

<azaroth> bigbluehat: fantasai

tbdinesh: the HTML group will only consider markup

... something is a <nav> for instance

... so let's say you have some deal with an annotation

... where it goes from a note, to a footnote, to ruby

... we called it annotation before, but now it becomes a tag

fjh: we are different than the other groups because we're thinking of
annotation first, and then other serializations

azaroth: I think we should look at the proposal and then break

<fjh> proposed RESOLUTION: rough consensus to support using markup for
footnotes but with review to make sure details enable mapping to annotation

<JakeHart> +1

<azaroth> +1

<shepazu> +1

+1

proposed RESOLUTION: rough consensus to support using markup for footnotes but
with review to make sure details enable mapping to annotation

<TimCole> +1

shepazu: azaroth are you coming to the hack days? I was going to hack on an
HTML proposal

azaroth: not sure I'll make it

<fjh> **ACTION:** TimCole to talk with digital publishing group re consensus
(and Rob) [recorded in [http://www.w3.org/2015/04/22-annotation-
minutes.html#action06][43]]

<trackbot> Created ACTION-15 - Talk with digital publishing group re consensus
(and rob) [on Timothy Cole - due 2015-04-29].

azaroth: I'd like an action on TimCole and myself to talk to the dpub group

breaking until 3:15 pm

<JakeHart> Scribe: jakehart

### RangeFinder API

<fjh> ScribeNick: JakeHart

<shepazu> [https://docs.google.com/presentation/d/1eTsTlPCoIiJzk5q3JIJ6BFneWE9
FtXnRHaIgKcLVN4g/edit#slide=id.g99fce293a_0_25][44]

<shepazu> [https://docs.google.com/presentation/d/1eTsTlPCoIiJzk5q3JIJ6BFneWE9
FtXnRHaIgKcLVN4g/edit?usp=sharing][45]

shepazu: I'm not personally sold on the Rangefinder API being the right thing.
This is a strawman.

What is the lowest-level API we can define to find the location of a portion
of a DOM document based on a set of selectors?

Use Cases:

Anchoring annotations:

locating text (for example) between sessions even when the text (or its
context) may have changed

Finding text:

exposing the browser’s native find-in-page

There are some constraints:

Performance, Simplicity, Low level, Only works on current document

Questions:

Should it iterate over the document, or find all matches in one pass?

What should the return value contain?

What is useful information for this to give back?

Should we have a separate edit-distance API?

How closely should we map to the data model?

Strawman spec: [https://specs.webplatform.org/rangefinder/w3c/master/][46]

Please annotate!

Orthogonal Goals:

Defining a URL syntax that lets you link to a document fragment, given a
rangefinder API

shepazu: it would be nice if I give it a simple URL.

Styling the range once you’ve found it, without modifying the DOM

i.e. without injecting spans for highlights.

nickstenn: I just thought I would state that in response to the first
question, you can take an API that iterates and turn it into something that
can find all in one pass.

fjh: what was your question?

I missed it.

<fjh> I asked what rationale given was for find-all

azaroth: question about separate edit-distance API.

<azaroth> Is the edit distance API option to be combined with the finder API
as an argument, or as lots of separate finders?

The URL syntax relates to the discussion about fragment identifiers.

Are you thinking about an approach where you can pass in range finder
arguments in the URL?

^^ TimCole

shepazu: talking about svg fragments.

mySVG.svg#svgView(0,10,100,10)

^^ Example?

TimCole: You wouldn't try to overload #?

shepazu:

<fjh> shepazu: example !view(..) or !text=" "& start=10

Find a symbol that's not commonly used...

TimCole: the publishing group would like to be able to get to places in
documents.

"Don't break the web."

<fjh> idea - follow up on function query parameter

Parameters on the URL scheme are things that should be dealt with the
rangefinder API.

<shepazu> [https://specs.webplatform.org/rangefinder/w3c/master/][46]

tbdinesh: I missed the rational for edit distance.

<fjh> shepazu: the quick brown fox is now the quick brown box, so how to match
without edit distance

shepazu: Documents change, what if a publisher corrects a small error?

<fjh> shepazu: might decide to limit RangeFinder to text

bigbluehat: scrolling through the URI spec, fragment identifiers are mapped to
media types...

... thinks we should explore a URL syntax

<fjh> isn't there a length limit on URLs?

shepazu: the browser could use the rangefinderapi to resolve the URL.

bigbluehat: there are several needs for how to express something additional
about a URL in a single line of text.

Is this something we should define?

shepazu: it is not specifically in our charter to define a URL syntax.

TimCole: you can mint a service that takes the three things and turns them
into a URL... like a link shortener.

azaroth: this could work with anything without messing with URL structure.

... moving from URL syntax.

<paoloC> [http://www.w3.org/TR/its20/][47]

<fjh> NIF 2.0 [http://persistence.uni-leipzig.org/nlp2rdf/ontologies/nif-core
/nif-core.html][48]

paoloC In terms of URI selection they have theory on how to select text.

paoloC: ^^

... we should explore that work.

shepazu:

I would like some feedback on the list.

If people think that this the right kind of direction... then if they could
tell me what kind of return value would be useful.

fjh we need to figure out what we need to do and how.

shepazu: please give feedback

[https://specs.webplatform.org/rangefinder/w3c/master/][46]

shepazu: do people think I'm going in the generally right direction?

tilgovi: I like the idea of exposing the browsers find functionality for
programmatic access.

<tilgovi> I am skeptical of the generalizability of edit distances for fuzzy
search

tilgovi: we might be able to do something simpler.

Which might allow us to prototype this in user space.

my major concern is about the range of possible meanings for distances and
thresholds.

fjh: it would be valuable to create a new draft.

nickstenn: if we don't know how this going to work in practice we should do
some experimentation first.

tilgovi: thinks finding ranges is the right direction.

<fjh> paoloC: worked on fifteen distance algorithms, for google refine, only
one used inthe end because of performance reasons, ppm

<tilgovi> That bolsters my confidence in the utility of a single algorithm

<paoloC> [https://github.com/OpenRefine/OpenRefine/wiki/Clustering-In-
Depth][49]

<tilgovi> Even if it's not useful for every single case

fjh: the message is performance matters and sometimes flexibility doesn't
matter so much.

paoloC: what mattered is it had to work in the browser.

shepazu: if ppm was good enough, maybe that is what we should standardize.

<paoloC> Original code [https://code.google.com/p/simile-vicino/][50]

tilgovi: two performance related thoughts.

One way to avoid locking the browser would to be include a timeout in the API.

The other thing about performance, especially if this is about anchoring
annotations, it may be that performance improvements for checking for multiple
things in one pass. Performance could be huge...

<tilgovi> s/improvents for/could be improved by/

### Search

azaroth: the search question comes up as necessary for us to solve to have a
useful client server interaction

... to avoid having to load 10,000 annotations on the client just to find two
relevant annotations.

... if we propose something to LDP it could likely be well recieved.

... There is lot's of prior art here.

... Open search: an atom based search.

<TimCole> [http://www.loc.gov/standards/sru/][51]

<fjh> [http://zing.z3950.org/cql/intro.html][52]

azaroth: Solar: well adopted platform, has it's own query parameters.

... We should come up with use cases and tick them off.

<TimCole> [http://www.opensearch.org/][53]

azaroth: then let's discuss a rational and defensible approach for a proposal.

fjh: CQL has a lot of nice things in it.

... worth looking into more.

... not sure how it would fit since it's all text based.

<fjh> CQL text based, offers simple syntax for query, powerful including
proximity, yet would need to define index sets

<fjh> rayd: querying, sorting, filtering, result set all requirements to
consider

<fjh> ... paging

fjh: if you are going to come up with a query spec, you want it to be able to
query, page, and return a result set...

bigbluehat: search method proposal

<bigbluehat> [http://tools.ietf.org/html/draft-snell-search-method-00][54]

bigbluehat: Snell's most recent rfc proposal.

<fjh> sounds like this is important but we would still need to define search
query details, result set, paging etc?

bigbluehat: concerned about crafting or selecting a query language for
annotation.

<bigbluehat> ...there are simple use cases that don't require a "query
language"--find me all annotations for a resource could look like sending in
just that resource identifier to an endpoint (either in the URL, or wherever)

<azaroth> +1 to TimCole

<Zakim> azaroth, you wanted to suggest CQL as posted query with SEARCH verb

<TimCole> at this point in spec and community development we should limited
our self to a very locked-down profile that specifies exactly what kinds of
searches are supported, a limited number sort options

<TimCole> and a limited range of what can be returned.

<bigbluehat> RayD: can you drop any and all links you have for these things.
:) would be super helpful

TimCole: we've got to think of things that work well on dated servers.

<fjh> **ACTION:** rayd to provide summary of sru level 1 for group to enable
considering approach [recorded in [http://www.w3.org/2015/04/22-annotation-
minutes.html#action07][55]]

<trackbot> Created ACTION-16 - Provide summary of sru level 1 for group to
enable considering approach [on Ray Denenberg - due 2015-04-29].

<azaroth> proposal was to write a straw person document that uses the SEARCH
verb to transport a restricted CQL query

bigbluehat: the primary use case is finding all the annotations for this uri.

<azaroth> and enumerate the potential query patterns as part of that against
the known use cases for search

bigbluehat: Maybe we can spec a smaller thing that is not search?

<fjh> +1 to bigbluehat of having method to obtain annotations for specific
resource without requiring search

bigbluehat: if i give it the URI it comes back with the feed location.

... that could be shipped sooner. You're not doing a search.

... then search could be layered on top of that.

azaroth: SIU, CQL, OMIPQH

... every ones hates OMIPQH.

... could feeds actually be linked to?

<azaroth> OAI-PMH

The concern with lists of feeds is that you need to be able to enumerate the
feeds.

TimCole: OAIPMH allows hierarchical sets.

<azaroth> Rob's concern: Impossible to enumerate the list of possible feeds,
and potentially useful combinations of query patterns

<azaroth> For example still need to be able to construct a URL syntax that
includes the target of the annotation

<azaroth> Which is then a URL pattern for searching

fjh: we need to follow up on this.

... we need to know when our next meeting is.

... are we going to meet next wednesday.

... we will meet on April 29th.

### Meetings

takeshi: can we talk about the data model.

<takeshi> [https://gist.github.com/tkanai/e2984cfa14cf099baa94][56]

<fjh> will meet next Wed 29 April

### Data Model

<fjh> issue - text offset works in some languages but not others, e.g.
Javascript but not Python etc

takeshi: concern that the offset will work in certain programming languages
but not in others.

<tilgovi> +1

takeshi: to use the offset we need to make clear definitions.

... IMO the python type of counting system is good.

... the result of the Javascript offset counter is not acceptable.

<tilgovi> nickstenn: explains that string lengths are not a straightforward
thing when multi-byte character encodings that do not used a fixed number of
bytes are in use

fjh: so what's the solution?

nickstenn: we need to be precise about how offsets are calculated.

<tilgovi> takeshi: requests that we are precise about what we mean for text
offsets and that we are careful not to cause too much performance penalty

nickstenn: IMO the most logical way of counting things is to normalize to
count from the full composed form.

... this is expensive though.

*fully

<shepazu> [http://www.w3.org/International/docs/charmod-norm/][57]

bigbluehat: "Can we just rename it the almost offset?"

nickstenn: we should have this as an agenda item on another call.

<fjh> **ACTION:** fjh add offset issue to future agenda item [recorded in
[http://www.w3.org/2015/04/22-annotation-minutes.html#action08][58]]

<trackbot> Created ACTION-17 - Add offset issue to future agenda item [on
Frederick Hirsch - due 2015-04-29].

<shepazu> "Character Model for the World Wide Web: String Matching and
Searching" [http://www.w3.org/International/docs/charmod-norm/][57]

TimCole: this is illustrating the softness of selectors.

shepazu: there is a draft spec for this called "Character Model for the World
Wide Web: String Matching and Searching" [http://www.w3.org/International/docs
/charmod-norm/][57]

... it talks about normalization and tries to clarify many of these issues.

... this is crucial for rangefinder.

<paoloC> [http://persistence.uni-
leipzig.org/nlp2rdf/specification/core.html][59] section "Definition of
Strings"

shepazu: if we encourage implementations to use character normalization, it
doesn't matter what Javascript does.

### Other Business

fjh: any other business?

<fjh> Thanks to Hypothes.is for hosting this meeting

<fjh> Thanks to the working group for active participation in this F2F
meeting!

shepazu: since it seems like we're going to be making more specs it would be
cool if we could publish on web platform

... should we have a twitter account for the wg.

?

shepazu: we would tweet when we publish a specification.

... I'll set something up.

... "#IagreewithBenjaminYoung."

### Adjourn

## Summary of Action Items

**[NEW]** **ACTION:** azaroth to add creating buckets for client side
annotation support to next agenda [recorded in [http://www.w3.org/2015/04/22
-annotation-minutes.html#action03][34]]

**[NEW]** **ACTION:** azaroth to update Protocol draft based on F2F discussion
comments [recorded in [http://www.w3.org/2015/04/22-annotation-
minutes.html#action04][37]]

**[NEW]** **ACTION:** bigbluehat documenting use cases [recorded in
[http://www.w3.org/2015/04/22-annotation-minutes.html#action02][33]]

**[NEW]** **ACTION:** fjh add offset issue to future agenda item [recorded in
[http://www.w3.org/2015/04/22-annotation-minutes.html#action08][58]]

**[NEW]** **ACTION:** nick to prepare initial draft of DomAnnotation [recorded
in [http://www.w3.org/2015/04/22-annotation-minutes.html#action01][32]]

**[NEW]** **ACTION:** rayd to provide summary of sru level 1 for group to
enable considering approach [recorded in [http://www.w3.org/2015/04/22
-annotation-minutes.html#action07][55]]

**[NEW]** **ACTION:** shepazu to add aggregation use case to wiki [recorded in
[http://www.w3.org/2015/04/22-annotation-minutes.html#action05][38]]

**[NEW]** **ACTION:** TimCole to talk with digital publishing group re
consensus (and Rob) [recorded in [http://www.w3.org/2015/04/22-annotation-
minutes.html#action06][43]]


[End of minutes]

* * *

Minutes formatted by David Booth's [scribe.perl][60] version 1.135 ([CVS
log][61])

$Date: 2009-03-02 03:52:20 $

   [1]: http://www.w3.org/Icons/w3c_home

   [2]: http://www.w3.org/

   [3]: http://www.w3.org/2015/04/22-annotation-irc

   [4]: #agenda

   [5]: #item01

   [6]: #item02

   [7]: #item03

   [8]: #item04

   [9]: #item05

   [10]: #item06

   [11]: #item07

   [12]: #item08

   [13]: #item09

   [14]: #item10

   [15]: #item11

   [16]: #item12

   [17]: #item13

   [18]: #ActionSummary

   [19]: https://lists.w3.org/Archives/Public/public-
annotation/2015Apr/0118.html

   [20]: http://w3c.github.io/web-annotation/protocol/wd/

   [21]: https://lists.w3.org/Archives/Public/public-
annotation/2015Apr/0103.html

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

   [23]: https://github.com/jasnell/dandus

   [24]: https://lists.w3.org/Archives/Public/public-
annotation/2015Apr/att-0121/ClientSideAPI.pdf

   [25]: http://www.w3.org/TR/dpub-annotation-uc/#requirements

   [26]: https://docs.google.com/presentation/d/1ZKSZyLbEFqwYaG32cFJwcXQjjiU2Z
zQguDmyhKfaTdY/edit#slide=id.p

   [27]: https://github.com/nickstenning/domannotations

   [28]: https://dom.spec.whatwg.org/#ranges

   [29]: http://www.w3.org/TR/eventsource/

   [30]: http://www.w3.org/TR/eventsource/#text-event-stream

   [31]: https://www.w3.org/annotation/wiki/Use_Cases

   [32]: http://www.w3.org/2015/04/22-annotation-minutes.html#action01

   [33]: http://www.w3.org/2015/04/22-annotation-minutes.html#action02

   [34]: http://www.w3.org/2015/04/22-annotation-minutes.html#action03

   [35]: http://www.w3.org/2015/04/15-annotation-minutes.html

   [36]: https://hypothes.is/a/5DScCXXnTNeJ0uBWpu1cyg

   [37]: http://www.w3.org/2015/04/22-annotation-minutes.html#action04

   [38]: http://www.w3.org/2015/04/22-annotation-minutes.html#action05

   [39]: https://lists.w3.org/Archives/Public/public-digipub-
ig/2015Feb/0090.html

   [40]: http://davidmacd.com/blog/html51-footnotes.html

   [41]: http://www.w3.org/community/openannotation/wiki/RDFa

   [42]: http://www.w3.org/TR/ruby/

   [43]: http://www.w3.org/2015/04/22-annotation-minutes.html#action06

   [44]: https://docs.google.com/presentation/d/1eTsTlPCoIiJzk5q3JIJ6BFneWE9Ft
XnRHaIgKcLVN4g/edit#slide=id.g99fce293a_0_25

   [45]: https://docs.google.com/presentation/d/1eTsTlPCoIiJzk5q3JIJ6BFneWE9Ft
XnRHaIgKcLVN4g/edit?usp=sharing

   [46]: https://specs.webplatform.org/rangefinder/w3c/master/

   [47]: http://www.w3.org/TR/its20/

   [48]: http://persistence.uni-leipzig.org/nlp2rdf/ontologies/nif-core/nif-
core.html

   [49]: https://github.com/OpenRefine/OpenRefine/wiki/Clustering-In-Depth

   [50]: https://code.google.com/p/simile-vicino/

   [51]: http://www.loc.gov/standards/sru/

   [52]: http://zing.z3950.org/cql/intro.html

   [53]: http://www.opensearch.org/

   [54]: http://tools.ietf.org/html/draft-snell-search-method-00

   [55]: http://www.w3.org/2015/04/22-annotation-minutes.html#action07

   [56]: https://gist.github.com/tkanai/e2984cfa14cf099baa94

   [57]: http://www.w3.org/International/docs/charmod-norm/

   [58]: http://www.w3.org/2015/04/22-annotation-minutes.html#action08

   [59]: http://persistence.uni-leipzig.org/nlp2rdf/specification/core.html

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

   [61]: http://dev.w3.org/cvsweb/2002/scribe/