W3C home > Mailing lists > Public > public-annotation@w3.org > February 2015

[admin] Draft minutes from today's teleconference, 2015-02-25

From: Frederick Hirsch <w3c@fjhirsch.com>
Date: Wed, 25 Feb 2015 12:58:57 -0500
To: W3C Public Annotation List <public-annotation@w3.org>
Message-Id: <D8E35973-A535-46BE-9FD2-C940A72FEFB3@fjhirsch.com>
Attached are draft minutes from today's teleconference, 2015-02-25. Thanks to Dan for scribing.

Please send any corrections to the list. 


regards, Frederick

Frederick Hirsch
Co-Chair, W3C Web Annotation WG



# Web Annotation Working Group Teleconference

## 25 Feb 2015

See also: [IRC log][3]

## Attendees


    Frederick, Hirsch, Ray_Denenberg, Doug_Schepers, Dan_Whaley,
Kyrce_Swenson, T.B._Dinesh, T.B.Dinesh, Dave_Cramer, Jacob_Jett, Matt_Haas,
Benjamin_Young, deirdrelee


    Rob_Sanderson, Ivan_Herman, Raphaël_Troncy, Paolo_Ciccarese,
Ben_De_Meester, Maxence_Guesdon


    Frederick Hirsch



## Contents

  * [Topics][4]

    1. [Agenda Review, Scribe Selection, Announcements][5]

    2. [Minutes Approval][6]

    3. [RangeFinder API][7]

    4. [Annotation Feeds][8]

    5. [Protocol Implementations][9]

    6. [Adjourn][10]

  * [Summary of Action Items][11]

* * *

<trackbot> Date: 25 February 2015

<fjh> Agenda: [https://lists.w3.org/Archives/Public/public-

### Agenda Review, Scribe Selection, Announcements

<fjh> ScribeNick: dwhly

fjh: main topic is rangefinder api

... … implementations

<fjh> JSON-LD Introductory videos [https://lists.w3.org/Archives/Public

<fjh> LDP F2F likely to be 21st April

fjh: not sure what's going on w/ LDP f2f

shepazu: doesn't seem like there were a lot of LDP folks that could attend

... what's azaroth's role?

fjh: Ashok is working on this, wanted to share that this is being considered

### Minutes Approval

<fjh> proposed RESOLUTION: 18 February 2015 minutes approved adding Rob as co-
chair to minutes

<fjh> [http://www.w3.org/2015/02/18-annotation-minutes.html][14]

**RESOLUTION: 18 February 2015 minutes approved adding Rob as co-chair to

### RangeFinder API

<fjh> [http://w3c.github.io/web-annotation/rangefinder-api/][15]

shepzau: discussions w/ tilgovi influenced approach

... at TPAC introd findtext API

... struggled w 2 architectures

... 1) treating this as a method on the element

... 2) having it as its own object, can execute it multiple times

... went with option 2

... went with attributes vs setters

... each selector is an attribute

... poorly described at this point, wanted to get something out.

... given all the selectors you'd kick off the search.

... (technical description complicated to transcribe)

<fjh> shepazu: hope you don't have to use multiple incremental searches, with
appropriate selectors can return result in one pass

shepzau: a fjh: main design feature is that it has to meet the use cases and
simple searches

... right now the find dialogs in browsers aren't exposed to developers

... a goal is to unify the search capabilities and expose these to browsers

... do we want to have strict case matches, fwd backwards, etc.

... do we want to have unicode mapping from o to o umlaut....

<fjh> [http://w3c.github.io/web-annotation/api/rangefinder/][16]

shepzau: these are the kinds of things that can allow browsers to implement

shepazu: one thing i didn't add was wraparound

... to the top of the search tree. it's the dom subtree in which we are

<Zakim> fjh, you wanted to ask about finding best match

shepazu: there are two ways of determining if we have all the results

... if you have wraparound you can do a detect if the result is same as

... doesn't handle changing documents

... and also doesn't handle realtime

... changes

... particularly realtime insertions that could affect the search term

... propose that he adds how you can tell that you've finished a search

csillag: in your intro you mention that there might be an application with
content that could be searches and not searchable.

... text could be bigger than the DOM tree for instance

... with PDFjs

... do we want to support this use case?

shepazu: my impression is that the API should not address this use case.
obviously this deals with specifying an element to search.

... the application itself could be aware that the entire document has not
been presented, and could create multiple rangefinder instances.

... could try to look ahead to find things that hadn't been searched

... there are a number of techniques you could use to work around.

csillag: do we want to support several applications working together?

<fjh> what is the use case for applications working together?

shepazu: if they're both in the same document then the rangefinder would work
as you would expect.

... if they're in two separate frames....

csillag: not asking about that

shepazu: if they're both in the same document. they could instantiate multiple
rangefinders to target the specific areas.

... and display the results the as needed

fjh: i don't understand the multiple application use case.

csillag: let me restate. do we want to make it possible for applications to
implement the native search capability.

shepazu: that's a browser UI question. up to individual browsers. not for us.

csillag: do we want to provide capability that could augment the browser's
native search. we might want the browser to search inside the document. we'd
need another api that could inform the browser where the actual searchable
content lies.

... this is the same as the two application situation.

shepazu: i want to split out the discussion. you're talking about a couple
different things.

... common knowledge in W3 circles.

... there is a separation between chrome/UI features and DOM features.

... in the past browsers have been insistent that we not try to describe
things that are UI features.

... i think there would be a lot of resistance to that.

... that's a non-starter. there are two paths forward

... 1) you can do what they do today, which is to override the native search
capability. if I use ctrl-F in google docs, then gdocs grabs the keys and does
it itself.

... what i propose is a compromise, we expose the functionality, but that we
override the native search functionality.

... if that's successful, then possibly we come to

... 2) browsers decide on their own to expose this functionality and expose an
API for developres

... for example, not every browsers UI let you do case matching, wrap around,

... it could be that if they implement this, they add those elements

... it would be a very different API if we had a different way to push results
into the browsers native API

csillag: ok, forget that, lets focus on the other.

... (missed the question)

shepazu: we can either have multiple rangefinders, or we can have one whose
parent contains both.

... i don't know what you mean by multiple applications

... either they're friendly and they expose their APIs. it's up to the
applications expose their search capability.

fjh: good questions, but can you write these downs and submit to the mailing

shepazu: can i add one thing to the minutes...

... kristof reminded me that we assume that everything we're searching for is
in the DOM, but we could have a big body of text that hasn't been inserted

... we might want to search that instead.

<csillag> We are doing lots of fun things with pdfjs

<csillag> not sure what you are asking

shepazu: one of the optimizations that pdfjs makes is that it doesn't render
the DOM all at one things

... but it already has all the content in memory

... so, it searches within the bytestream as a look ahead... and then informs
PDFjs this is the part they want to navigate to.

fjh: 1) yeah makes sense, 2) is this a v2 feature?

... it's complicated already, can we simplify.

csillag: we can keep it simple if we define the extension points.

... could provide the text we want to search on.

... extension point would allow overriding the text we want to search on.

... pdfjs could provide the whole text for instance.

shepazu: two possible extension points 1) here's a block of text you want to
search on

... 2) not an extension point actually. this app is not designed to be the
sole search capability. it's designed to be an instance.

... the extension point is actually not in the application itself but in the
way it was designed.

fjh: Kristof I think it would be very helpful for you to send an email with
your issues and ideas to the list, so we can consider and see if we've missed

<Zakim> fjh, you wanted to ask about need for html canonicalization for
whitespace or selector canonicalization

fjh: i was looking at examples at end of doc. will these work in various
cases, whitespace, line breaks, parsing, etc.

shepazu: two ways to answer: 1) yes, the DOM4 or HTML5 spec has a normalize

... i need to make this more explicit. there's a big part of the spec that's

... the algorithms are missing.

... 2) you might want to search in a white space sensitive way.

... search for two spaces separated by another word. not sure how difficult
that would be.

... not sure the use cases justify it.

fjh: as a developer i don't need to worry about normalization.

shepazu: i need to explain it in the docs.

... honestly, I could walk through the issues. it's more important to work
through issues i know are unaddressed.

fjh: matter of using algorithms that already exist

shepazu: there is a lot of prior art on this.

... i'm not qualified to read all the literature.

... more efficient to get this to the state where it's credible and then ask

... levenstein is still alive!

... more than most other W3C specs this is in a space with a lot of

dwhly: there's a list at the bottom of our fuzzy anchoring blog post

shepazu: this isn't done there are huge gaps.

... i'd much rather receive annotations than emails

### Annotation Feeds

<fjh> [https://lists.w3.org/Archives/Public/public-

shepazu: benjamin sent a message on this, benjamin?

bigbluehat: i've added some wiki pages one for annotations feeds, one for [

... i'd love to find other prior implementations for atom feeds

... right now I'd just like to collect and gather them

... i'll drop the links in the chat

<bigbluehat> Annotation Feeds wiki

fjh: the search related to feeds looks like it can get complicated. do we want
to delve into this?

bigbluehat: sure, lorestore included their own search endpoints

<fjh> so we can keep this simple with focus on annotation feed format and
possibly simple discovery

<bigbluehat> Existing Protocol Implementations wiki

fjh: when we say discover what are we saying?

bigbluehat: that needs discussion... there are a lot of places to provide the

... it's helpful if we can separate that.

... they could all be shipped as separate thngs.

... if you have your own CMS that implements it, etc.

... we can expect that people will ship their own annotations as a feed....

fjh: don't want to ask questions... oh i do have one more

<fjh> fjh: do you think topic maps might be relevant to organizing annotations

shepazu: i think the idea of topic maps has become superceded by hashtags and
other things

<fjh> shepazu: superseded by tagging

shepazu: the advantage of a topic map it's a defined vocab. and enables

... but not sure it's common practice

### Protocol Implementations

<fjh> Lorestore, [https://lists.w3.org/Archives/Public/public-

<fjh> Protocol Reference Work: Annotopia [https://lists.w3.org/Archives/Public

### Adjourn

## Summary of Action Items

[End of minutes]

* * *

Minutes formatted by David Booth's [scribe.perl][22] version 1.135 ([CVS

$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/02/25-annotation-irc

   [4]: #agenda

   [5]: #item01

   [6]: #item02

   [7]: #item03

   [8]: #item04

   [9]: #item05

   [10]: #item06

   [11]: #ActionSummary

   [12]: https://lists.w3.org/Archives/Public/public-

   [13]: https://lists.w3.org/Archives/Public/public-

   [14]: http://www.w3.org/2015/02/18-annotation-minutes.html

   [15]: http://w3c.github.io/web-annotation/rangefinder-api/

   [16]: http://w3c.github.io/web-annotation/api/rangefinder/

   [17]: https://lists.w3.org/Archives/Public/public-

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

   [19]: https://www.w3.org/annotation/wiki/Existing_Protocol_Implementations

   [20]: https://lists.w3.org/Archives/Public/public-

   [21]: https://lists.w3.org/Archives/Public/public-

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

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

Received on Wednesday, 25 February 2015 17:59:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:32 UTC