See also: IRC log
<trackbot> Date: 22 April 2015
<fjh> Agenda: https://lists.w3.org/Archives/Public/public-annotation/2015Apr/0118.html
<azaroth> TimCole: http://w3c.github.io/web-annotation/protocol/wd/
<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
<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
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
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
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
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
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
<azaroth> Link to the requirements from DPUB use cases: http://www.w3.org/TR/dpub-annotation-uc/#requirements
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/1ZKSZyLbEFqwYaG32cFJwcXQjjiU2ZzQguDmyhKfaTdY/edit#slide=id.p
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
nickstenn: "straw man" proposal, pick holes in it: https://github.com/nickstenning/domannotations
... 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
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/
<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
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
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]
<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]
<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]
<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.
<fjh> http://www.w3.org/2015/04/15-annotation-minutes.html
<JakeHart> My name is Jake Hartnell, and I'm a designer / front-end engineer at Hypothes.is.
RESOLUTION: Minutes from 15 April approved.
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
<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/
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/
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
;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]
<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]
<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
<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 and blog post on requirements: http://davidmacd.com/blog/html51-footnotes.html
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
<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
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/
<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]
<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
<fjh> ScribeNick: JakeHart
<shepazu> https://docs.google.com/presentation/d/1eTsTlPCoIiJzk5q3JIJ6BFneWE9FtXnRHaIgKcLVN4g/edit?usp=sharing
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/
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/
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/
<fjh> NIF 2.0 http://persistence.uni-leipzig.org/nlp2rdf/ontologies/nif-core/nif-core.html
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/
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
<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/
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/
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/
<fjh> http://zing.z3950.org/cql/intro.html
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/
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
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]
<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.
takeshi: can we talk about the data model.
<takeshi> https://gist.github.com/tkanai/e2984cfa14cf099baa94
<fjh> will meet next Wed 29 April
<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/
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]
<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/
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/
... 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 section "Definition of Strings"
shepazu: if we encourage implementations to use character normalization, it doesn't matter what Javascript does.
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."