See also: IRC log
<ivan> mintues : http://www.w3.org/2015/01/28-annotation-minutes.html
RESOLUTION: minutes approved
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
... 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
<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.
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
<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