Web Annotation Working Group Teleconference

minutes approval

<ivan> mintues : http://www.w3.org/2015/01/28-annotation-minutes.html

RESOLUTION: minutes approved

Use cases

paoloC: benjamin and I have been discussing the latest use cases, related to reviews
... we added a page called "reviews as annotation"
... essentially related to a user that wants to review a particular resource
... we should allow for mechanisms such as aggregations of reviews of a single resource from multiple places
... this brought up the topic of motivations, which is later on today's agenda

<paoloC> https://www.w3.org/annotation/wiki/Reviews_as_Annotation

paoloC: in this specific case the presence of a proper review motivation could allow for searching and filtering

bigbluehat: could we hear from RayD?

RayD: I didn't quite understand how the motivation solves the query problem

paoloC: motivation would address the issue that you have different kinds of annotation on a given resource (comments, +1, pictures, etc.)
... but a "reviewing" annotation would provide the ability to filter down to only those which are reviews

RayD: absolutely, but how do we even find all the annotations in the first place?

paoloC: this sounds like it could be a requirement for the protocol part

RayD: there may be a need for a mechanism where if I create an annotation on a resource then I can notify that server [of the resource] that I created that annotation

<Jacob> So I'm confused, is this a question about querying and retrieval results or one of aggregation?

RayD: otherwise if I'm a user and I want to get all the annotations for a given resource I need to know where they are before I can query with them

paoloC: this covers quite a lot -- possibly federation of annotations, notification of publishers that an annotation has been created, etc.

shepazu: I acknowledge that this is a useful piece of functionality.
... and this group can try to provide mechanisms that make some aspects of this easier
... but it's not a solvable problem in terms of standards

<RayD> disagree that it is not a solvable problem

shepazu: at most we can provide mechanisms
... but those mechanisms don't in and of themselves solve the problem
... the ecosystem that makes use of the mechanisms will do that
... to take the example -- we should provide a mechanism for notifying page authors that annotations have been created about their pages

shepazu: but if you're looking for a review of a paper that you're not the publisher of -- that doesn't mean that the publisher will reveal that information

... there could be another mechanism -- you could, for example, watch a given page ... but it's difficult to see how with a decentralised architecture we'll be able to design a mechanism which allows you track all annotations anywhere

<shepazu> +1 to Bill_Kasdorf

Bill_Kasdorf: to avoid the complications that could be implied by this use case, it could be useful to restrict the use cases to refer to a particular group or set of annotations

RayD: I think shepazu may be over-complicating the issue

<bigbluehat> +q

RayD: as far as I'm concerned we're talking about mechanism
... if the mechanism is provided, then in my book the problem is solved
... if a publisher refuses to republish, that's a problem that is clearly out of scope for the WG

<ivan> +1 to bigbluehat

bigbluehat: something that I think would help as paoloC and I collate use cases, is if the use cases could specify which piece of the standards processes they're addressed towards (from model, protocol, interface, etc.)

shepazu: there could well be different protocols here
... activity streams and LDP are different protocols for different use cases

ivan: we may end up with use cases that we cannot solve in this group, and that's ok

paoloC: as our problem is categorization -- search is one of the issues, notification, discovery, etc.
... protocol can be multiple protocols
... should we split protocol into "search", "notification", etc

<shepazu> (I'm assuming that the query would be querying a specific web resource, which may be an aggregator from multiple resources)

<bigbluehat> https://www.w3.org/annotation/wiki/Use_Cases#List

<bigbluehat> we're using tags ^^

<bigbluehat> +q

nickstenn: two things -- nervous about strictly categorizing use cases
... and yes, we should certainly consider splitting up the protocol, but perhaps not into the smallest possible pieces -- it's a question of the technical tradeoffs

<shepazu> +1 to have use cases apply to multiple deliverables, though I think there's value in being organizational

bigbluehat: the categorisation isn't strict -- they're just tags that flag up which deliverables a particular use case might cover

good good, just checking :)

<shepazu> +1

paoloC: should we provide an example of how a "review" annotation could be modeled with the current model?

bigbluehat: absolutely we should try to provide examples
... separately i think the "reviews as annotations" use case probably has multiple different use cases wrapped up within it

Protocol

<ivan> scribenick: RayD

<shepazu> https://lists.w3.org/Archives/Public/public-annotation/2015Feb/0040.html

<nickstenn> http://w3c.github.io/web-annotation/protocol/wd/

...rob has put together an early draft of what the protocol should look like discusses a REST API

...for operations on annotations, referencing LDP

...to enable interoperability and Nick raised issue that the draft spec is a compromise between two points of view

...bulk users - internet archives, on one hand, and on the other hand user facing clients

<shepazu> (academic and scientific services)

...quite different needs. largely ones place higher importance on interoperability

<shepazu> +1 to nickstenn's categorization

proposal - split these two and consider the protocols separately.

<paoloC> +1

Ivan: understand what you say. if you have a client, fact that client might not use the protocol is normal

...issue comes up when you need to share annotations.

Paolo: require client to buy in to the protocol. server supports one protocol

...hard to ask developers to jump on to technologies they're not familiar with.

...each client will have it's own way of doing things.

nick: happy with us choosing to focus on the interoperability protocol.

...bulk data stores will need a way to to bulk annotations

tim: is there anything we can learn from other groups? other contexts?

ivan: comparison with CSV - don't see connection.

...don't need to use protocol if don't care abut interoperability

paolo: client to server protocol for guidance to new users.

...been looking at nicks work, inspiring, but not everyone's going to do that

...interoperability not just a matter of protocol, also a matter of model.

...annotation has to be formed so that it is understandable.

...i.e can't just stick it in a pdf

ivan: wonder how client side API comes into picture and how do two relate.

nick: closing word. won't address question about client side.

...concerned about how we define interoperability. Paolo's definition might be too broad.

...interoperability means two people reading the spec can talk to each other.

Data Model

ivan: there's a discussion about verbs vs nouns for motivations

paoloC: we had these discussions many times in Open Annotation
... most annotation systems talked about "types"
... we moved away from "types" to "motivations"
... Bob Morris at Harvard introduced the concepts of "goals" and "expectations" into Annotation Ontology

paoloC: in this framework the type was a noun, goals and expectations were all nouns

<Jacob> Bob Morris at Harvard

<Jacob> is the who

paoloC: but they were all different
... not sure why expectations didn't make it into the model, but we picked up motivations from SKOS
... we did go back and forth between nouns and verbs multiple times
... but overall I don't really mind -- these are just concepts with labels

<Bill_Kasdorf> +1 to types as nouns and motivations as verbs

<Bill_Kasdorf> . . . and that types are locally defined

TimCole: nouns for types makes a lot of sense, but motivations seemed like a special case of type that we wanted to keep "pure" -- there are so many meanings of rdf:type, and we didn't want to pollute the motivation namespace with those uses

RayD: for what it's worth, the current motivations aren't actually verbs, they are nouns -- gerunds.
... my proposal was not to suggest that we go back to RDF classes/types, but simply to go to the verb infinitive form rather than the gerund form
... what is substantive here is that I want to be able to filter "reviewing" annotations as a narrower class than a comment

paoloC: we can always attach multiple motivations

<Jacob> +1 for Ray's infinitive suggestion

paoloC: and thus can query using SKOS

<Jacob> or really +2 I guess...

paoloC: on a personal note the addition of "-ing" on the end of each motivation did seem like a bit much
... although I'd probably lean towards the short form
... i would just say that unless someone feels incredibly strongly we should probably not change them
... after all we're not going to be creating these annotations by hand

AOB

<shepazu> http://w3c.github.io/web-annotation/protocol/wd/

<shepazu> https://plus.google.com/u/0/113218107235105855584/posts/cx1C2LVxe8D?cfem=1

shepazu: I got a message on G+ [see above]

<raphael> For what is worth, I don't think we should discuss the naming of the motivations any further, and that we should not change their current naming

shepazu: the message raises a question about the protocol that's been published as a FPWD
... but it hasn't been approved for publication so it needs to be changed to an editor's draft
... are we inclined to published this right away?

nickstenn: I don't think Rob was suggesting that it was even close to ready for publication

<raphael> +1

<Jacob> +1