14:48:45 <RRSAgent> RRSAgent has joined #annotation
14:48:45 <RRSAgent> logging to http://www.w3.org/2015/05/13-annotation-irc
14:49:02 <azaroth> Present+ Rob_Sanderson
14:49:27 <azaroth> Regrets Frederick_Hirsch, Ray_Denenberg, Ben_De_Meester
14:52:25 <azaroth> Regrets+ Dave_Cramer
14:52:38 <azaroth> Regrets+ Bill_Kasdorf
14:54:14 <Kyrce> Kyrce has joined #annotation
14:59:44 <tbdinesh> tbdinesh has joined #annotation
15:00:15 <ivan> Present+ Ivan_Herman
15:00:36 <paoloC> paoloC has joined #annotation
15:01:11 <azaroth> Present+ Kyrce_Swenson
15:01:14 <TimCole> TimCole has joined #annotation
15:01:20 <azaroth> Present+ Matt_Haas
15:01:31 <TimCole> Present+ Tim_Cole
15:02:42 <azaroth> Present+ TB_Dinesh
15:02:55 <Kyrce> Present+ Kyrce_Swenson
15:03:17 <azaroth> Present+ Doug_Schepers
15:03:22 <Matt_Haas> Matt_Haas has joined #annotation
15:03:43 <azaroth> Present+ Paolo_Ciccarese
15:03:48 <TimCole> Present+ Janina_Sarol
15:03:59 <Matt_Haas> Present+ Matt_Haas
15:04:27 <tbdinesh> Present+ TB_Dinesh
15:05:34 <shepazu> is anyone having problems joining the WebEx?
15:06:14 <tbdinesh> i cant hear anyone on my android webex app. no java on laptop
15:07:57 <stain> Stian joined
15:08:03 <takeshi> takeshi has joined #annotation
15:08:04 <stain> Present+ stain
15:08:12 <bigbluehat> Present+ Benjamin_Young
15:08:13 <stain> Present+ Stian_SoilandReyes
15:08:18 <stain> (is it wikinames?)
15:08:27 <shepazu> takeshi, can you hear us?
15:08:37 <stain> Present+ Stian_Soiland-Reyes
15:08:37 <takeshi> Present+ Takeshi_Kanai
15:08:41 <takeshi> No!
15:08:53 <azaroth> In the webex app, did you connect to the audio?
15:08:58 <stain> azaroth: you might have three of me then as I have a - in my surname.. :)
15:08:59 <azaroth> On the 'quick start' tab
15:09:07 <shepazu> takeshi, did you click on the "connect to audio" button?
15:09:13 <azaroth> there should be a button for connecting, either via the computer or dialing in
15:09:37 <takeshi> Yes, I clicked the button.
15:10:13 <stain> I'll scribe
15:10:36 <stain> just remind me of the names.. preferably using the Zakim queue!
15:10:49 <davis_salisbury> davis_salisbury has joined #annotation
15:10:57 <shepazu> takeshi, maybe try starting it again?
15:11:03 <davis_salisbury> present+ davis salisbury
15:11:32 <stain> scribe: stain
15:12:02 <tbdinesh> i know another Davis in Bnaglore
15:13:27 <shepazu> takeshi, still not able to connect?
15:13:40 <stain> scribenick: stain
15:14:13 <shepazu> takeshi, you clicked "Call using computer"?
15:14:29 <azaroth> RESOLUTION:  Teleconference minutes from 6 May 2015 approved, see
15:14:29 <azaroth> http://www.w3.org/2015/05/06-annotation-minutes.html
15:15:04 <stain> TOPIC: Protocol:  Authentication Requirements?
15:15:39 <stain> Agenda: https://lists.w3.org/Archives/Public/public-annotation/2015May/0029.html
15:16:21 <stain> For the protocol Requirements for authenticatoin and authorization. For model, look at annotation sets and ordering of list.
15:16:25 <stain> zakim: ^^
15:16:41 <stain> zakim: On the use cases on which of the possible ways to ordering.. actually as the.. (?)
15:16:58 <stain> (sorry, I'm mixing up nicks with z)
15:16:59 <takeshi_> takeshi_ has joined #annotation
15:17:46 <stain> azaroth: ..also any cross-over work with social networking group
15:18:12 <stain> TOPIC: Protocol:  Authentication Requirements?
15:18:20 <stain> azaroth: how does authentication relate to the protocol?
15:18:40 <stain> azaroth: working on the protocol draft, there was no mention of authentication or authorization
15:19:00 <stain> azaroth: we would not want a protocol where anyone can mess with anyones annotation
15:19:12 <stain> azaroth: so we would need to address a&a
15:19:40 <stain> azaroth: discussion about the proposal (?), brainstorm, requirements, how it is in your own systems
15:19:54 <stain> azaroth: interactions between clients and server via (??)
15:20:09 <stain> azaroth: @paoloC - what are the Domeo requirements?
15:20:26 <stain> paoloC: We started some time ago with working with pharmaceutical companies, which have 3 requirements
15:20:32 <stain> paoloC: we integrated with LDAP for users/groups
15:20:35 <stain> paoloC: both needed
15:20:58 <stain> paoloC: step 1 was to include an API key, a low-level entry, to detect the client, and system just trusted client
15:21:03 <stain> paoloC: then moved to OAuth
15:21:19 <stain> paoloC: retrieve users through LDAP on server and client, and use OAuth for authentication
15:21:42 <TimCole> q+
15:21:45 <stain> paoloC: the LDAP is just the way we retrieve the user.. the authentication layer is separate
15:21:52 <azaroth> ack TimCole
15:22:06 <Zakim> Zakim has joined #annotation
15:22:20 <stain> TimCole: Do we need a authentication protocol? Finding a way that the annotation are associated with a user. Not trying to get into how the user is determined
15:22:43 <stain> paoloC: there are two issues - the model is already including Who created the annotaion.
15:22:56 <stain> paoloC: so technically the OAuth should check the credential against the payload
15:23:04 <stain> paoloC: or the payload might not include author, this can be added by server
15:23:40 <stain> paoloC: obviously the annotatoin includes the author already, so the requirement could be light.. communication should happen through an authenticated layer and check annotation against it
15:23:55 <stain> paoloC: this works unless you allow users to send in annotatipns made by other people
15:24:12 <stain> paoloC: this might sound weird, but I might want to enter an annotation that is said by someone else
15:24:32 <stain> paoloC: so he is the Author, but I am adding the Annotation
15:24:40 <stain> (e.g. Creator vs. Author  ?)
15:24:48 <stain> azaroth: so as a first step.. (?)
15:24:57 <shepazu> q+
15:25:02 <azaroth> ack shepazu
15:25:02 <paoloC> yes, Stian, in fact I was using PAV for that
15:25:10 <tbdinesh> tbdinesh has joined #annotation
15:25:14 <stain> shepazu: another similar thing where there might be more than one person annotating under the same username
15:25:20 <paoloC> q?
15:25:21 <stain> shepazu: I don't think it's a huge deal
15:25:22 <stain> q+
15:25:23 <paoloC> q+
15:25:32 <stain> shepazu: who has logging credentials.. provenance can be different
15:25:42 <azaroth> ack stain
15:25:44 <stain> accounts vs people
15:25:52 <azaroth> scribenick: azaroth
15:26:08 <paoloC> q-
15:26:10 <azaroth> Stain: Have a lightweight requirement, hard to determine author vs annotator
15:26:19 <azaroth> ... permission schemes are hard and could be out of scope
15:26:27 <azaroth> ... rely on existing mechanisms, server specific
15:26:30 <azaroth> q?
15:26:31 <bigbluehat> +1
15:26:44 <azaroth> scribenick: stain
15:26:52 <stain> azaroth: could paoloC tell us more about the OAuth workflow?
15:27:28 <stain> paoloC: we use libraries that does OAuth, and then OAuth combines the API Key of the client and a secret key of the user, which generates a user key for the transaction.. this expires now and then so you have to handshake again
15:27:45 <stain> azaroth: right, that workflow of the key exchange
15:27:56 <stain> paoloC: that comes down to the technology used.. there is usually machinery for that
15:28:08 <stain> paoloC: all you need to do then is to match the key to the person
15:28:18 <TimCole> q+
15:28:26 <azaroth> ack TimCole
15:28:30 <stain> paoloC: but if you have to implement OAuth yourself as a provider, then it's a bit more work!
15:28:53 <stain> TimCole: (?) reauthorization? Who is authorized to read an annotation vs. update or delete
15:28:58 <paoloC> q+
15:29:02 <azaroth> s/reauthorization/read authorization/
15:29:10 <stain> my apologies
15:29:29 <stain> TimCole: what do we need to add to the protocol to support that basic level of authorization?
15:29:52 <stain> TimCole: (?)
15:29:58 <azaroth> ack paoloC
15:29:59 <paoloC> Example of permissions (derived from Annotator) https://github.com/Annotopia/AtSmartStorage/wiki/Model-Permissions
15:30:28 <stain> paoloC: I think that's a good point.. when we start with Annotopia I looked at Annotator which says what is possible or not.. I added just one think
15:30:56 <stain> paoloC: in Annotator you can say Who can read it, update it, delete, admin it. Users and groups. In Domeo I also added Comment.
15:31:09 <stain> paoloC: if you think of cases where you do not want comments.. e.g. say CNN might shut down comments on a particular article
15:31:23 <stain> paoloC: and I wanted a similar feature.. you can read this annotation.. you can't edit or delete.. and you can't comment on it
15:31:27 <shepazu> q+
15:31:34 <stain> paoloC: but of course in the open world assumption anyone could annotate it
15:32:17 <stain> paoloC: but you could refine this better.. the actual authentication technology is probably more temporal, OAuth is popular right now, but who knows in 5 years
15:32:17 <azaroth> ack shepazu
15:32:34 <stain> shepazu: another permission is to Share
15:32:41 <stain> shepazu: I'm not sure we mentioned that.. and what does it mean?
15:33:06 <stain> shepazu: If I Share it.. am I just republishing? Can I change something? Or can I just say what *I* say?
15:33:14 <paoloC> q?
15:33:16 <stain> shepazu: sharing is kind of quoting.. you might want to permit sharing without edit
15:33:17 <paoloC> q+
15:33:23 <paoloC> share or embed?
15:33:32 <paoloC> that is related also to copyrights?
15:33:36 <stain> shepazu: I don't think this works too well for aggregation and confededatoin
15:33:39 <stain> shepazu: tumblr model
15:33:45 <stain> shepazu: you can put something someone else wrote onto your feewd
15:33:51 <stain> shepazu: twitter and retweets
15:33:55 <stain> shepazu: which is an important functionality
15:34:07 <stain> shepazu: sharing should be cross-service -- e.g. pinterest shared on twitter
15:34:12 <stain> shepazu: the provenance should be observed
15:34:15 <azaroth> q+ to distinguish license for reuse and authorization to modify in place
15:34:17 <stain> shepazu: we've not talked about this in depth
15:34:43 <stain> shepazu: if we have what paoloC said, the ability to say "You can't comment on this", first of all I disagree about that philosophically as a use-case
15:34:48 <stain> shepazu: but acknowledge there are some use-cases
15:35:02 <stain> shepazu: it troubles me.. but I don't think we should define that capability (?)
15:35:09 <azaroth> q?
15:35:13 <stain> shepazu: but in permission models there could be "Don't share this"
15:35:13 <stain> q+
15:35:15 <azaroth> ack paoloC
15:35:31 <stain> paoloC: I think this is a good discussion.. technically when an annotation is public, you can read it
15:35:41 <stain> paoloC: as Benjamin was saying, if you can read it, sharing is automatic
15:35:53 <stain> paoloC: another thing is copyright.. who owns the copyright on sharing? Embedding? Other things?
15:36:07 <stain> paoloC: say Twitter, the model is simple, once you tweet, anyone can retweet it and embed it
15:36:26 <stain> paoloC: if the annotation keeps it all open, then ..    Let's say an annotation is public, technically you can retrieve it
15:36:36 <stain> paoloC: if is available only to a group, but you share.. what does that mean then?
15:36:42 <stain> paoloC: is it then only available still to the same group?
15:36:50 <stain> paoloC: this gets complicated!
15:36:56 <stain> (Google+ syndrome!)
15:37:15 <stain> paoloC: another example is the Non Comment. That is why I was myself sceptical.
15:37:29 <stain> paoloC: In this environment, I would not want people to comment on it. Of course globally it can be broken.
15:37:37 <stain> paoloC: not sure how that would play out
15:37:38 <shepazu> q+
15:37:41 <azaroth> ack azaroth
15:37:41 <Zakim> azaroth, you wanted to distinguish license for reuse and authorization to modify in place
15:37:56 <stain> azaroth: looking at what paoloC said.. at what (?) is this being used
15:38:01 <stain> azaroth: from authorization requirements
15:38:21 <stain> azaroth: (?) authorizatoin and permissions are keys.. and what can I do with this? Like a license.
15:38:34 <stain> azaroth: e.g. you can share, etc.. but you have to tell me
15:38:45 <shepazu> http://www.canyoucopyrightatweet.com/
15:38:48 <stain> azaroth: this sounds distinct from permissions on the annotation
15:38:58 <azaroth> q?
15:39:03 <azaroth> ack stain
15:39:18 <paoloC> I am not sure 'copyright' is the right term
15:39:26 <azaroth> Stian:  +1, can they be shared is more advisory. Part of the annotation description and model.
15:39:30 <paoloC> I am referring to for instance a CC model
15:39:43 <azaroth> ... Trying to model the sorts of things there is difficult.  More like advisory in the open world.
15:39:53 <Matt_Haas> q+
15:40:01 <azaroth> ... Can't comment is definitely possible at an individual server level, e.g. you can't do this here
15:40:07 <azaroth> ack shepazu
15:40:15 <TimCole> q+
15:40:40 <stain> shepazu: I think that summarized it well. The azaroth was right with license. Leave it for the most part of up to the sytem how it enforces the license or not.
15:40:41 <paoloC> +1
15:40:44 <azaroth> +1
15:40:44 <stain> shepazu: not a technological way
15:40:45 <stain> +1
15:40:54 <TimCole> +1
15:41:05 <stain> shepazu: on the other hand I feel like the protocol should explicitly say something about Sharing
15:41:10 <stain> shepazu: I think it should be one of the verbs
15:41:34 <stain> (stain:.. or is Sharing just a Meta-annotation?)
15:41:36 <bigbluehat> huge +1 for collaborating with Social on AS 2.0 for sharing
15:41:45 <stain> azaroth: (?) Social
15:41:53 <azaroth> q?
15:41:58 <stain> (audio from azaroth is very small-room-ish.. )
15:41:58 <azaroth> ack Matt_Haas
15:42:01 <Kyrce> +1 to collaborating with Social Media as well.
15:42:32 <stain> Matt_Haas: from an education public PoV this is important.. student and teacher. Ability for that dynamic. Role might not be right to describe Teacher and Student.
15:42:36 <azaroth> azaroth:  Should collaborate with social web working group on the sharing aspect as closely related to the activity streams work
15:42:42 <azaroth> q?
15:42:44 <azaroth> ack TimCole
15:42:45 <stain> (thanks azaroth )
15:42:52 <Kyrce> q+
15:43:04 <stain> TimCole: it sounds like what will happen is that the service is going to enforce a lot of these limits
15:43:11 <stain> TimCole: who can edit, update, delete
15:43:21 <stain> TimCole: what does the protocol need to do..
15:43:42 <azaroth> q+ to discuss container vs annotation scoping
15:43:52 <stain> TimCole: can the protocol allow for the LDP Container to express "annotations who lives here are governed by this license, and this policy for reading, this for updating, etc"
15:44:11 <stain> TimCole: a container could say Bob and Doug is allowed to update, etc.
15:44:19 <stain> TimCole: and reuse according to CC-BY license
15:44:20 <Kyrce> q-
15:44:37 <stain> azaroth: good point, TimCole
15:44:51 <tbdinesh> +1 TimCole
15:44:53 <stain> azaroth: distinction between permissions on containers, and on annotations and results
15:44:56 <Kyrce> +1 TimCole
15:45:04 <davis_salisbury> +1
15:45:22 <bigbluehat> +1
15:45:32 <stain> azaroth: if permission and authorizatoin was associated with containers, and all in that container were by that requirement.. would that be sufficient? Or should an individual annotatoin carry this?
15:45:41 <bigbluehat> q+
15:45:44 <stain> azaroth: Benjamin has something along those lines (?)
15:45:47 <azaroth> ack bigbluehat
15:46:14 <azaroth> ack azaroth
15:46:15 <Zakim> azaroth, you wanted to discuss container vs annotation scoping
15:46:15 <stain> bigbluehat: we've been looking at container based access permissions the way the Annotator store annotations know, we do what paoloC mentioned earlier on the Annotatoin Package we send the Annotator
15:46:43 <stain> bigbluehat: the disadvantage for federation then is huge, as people need to read the access regulation and abide by the rule on the annotation
15:47:02 <stain> bigbluehat: if it's by box, then it's much easier to federate as you don't nee to check each annotation on the way out
15:47:15 <stain> bigbluehat: cleaner federation stories, containers can live all kinds of places and move around the web with the same content
15:47:31 <stain> bigbluehat: you could make things that took annotations out of one container and put it another to share it with another group
15:47:40 <stain> bigbluehat: and then get particular permission systems per container
15:47:40 <tbdinesh> q+
15:48:05 <stain> paoloC: this is an interesting point, going down to implementation. We have it on the Annotation level
15:48:22 <stain> paoloC: but we use Annotation Set, and so what we really do is to check permission on the set level, e.g. the same about the container
15:48:31 <stain> paoloC: but in our system each container carry their own permissions
15:48:46 <stain> paoloC: specially if it contains multiple annotations with the same
15:48:57 <stain> paoloC: but I'm not sure about the real benefit otherwise.. philosophical point
15:49:03 <stain> q+
15:49:21 <stain> paoloC: so every container will need to go with it.. permissions.. etc
15:49:34 <azaroth> ack tbdinesh
15:49:34 <stain> paoloC: if each annotation is shipped with the container, that is probably the way to go
15:49:42 <azaroth> q?
15:50:02 <stain> tbdinesh: what we do in the Sweep (?) case, every one that goes out.. (?) -- you can only see per container
15:50:08 <stain> tbdinesh: you can choose where your annotation gioes
15:50:15 <azaroth> ack stain
15:50:25 <stain> tbdinesh: (?)
15:50:50 <azaroth> Stain: For the annotopia case, keeping it on the container level is simpler, the container should enforce the permissions as its configured
15:50:50 <tbdinesh> s/Sweep/SweeT
15:50:58 <azaroth> ... makes things more complicated for the client
15:51:04 <azaroth> q?
15:51:19 <stain> stain: it is more complicated for the client if it is forced to figure out which permissions to set
15:51:22 <Uskudarli> Uskudarli has joined #annotation
15:51:41 <stain> azaroth: (?)  We have an LDAP service where we use OAuth
15:51:52 <stain> azaroth: with the token to the client
15:52:21 <stain> azaroth: token to the annotation server (?)
15:52:31 <tbdinesh> s/(?)/each annotation is a message that is sent to the container and the its up to the container to merge or consider it as an edit of the earlier one.
15:52:31 <stain> azaroth: (?) We went for a single group with each container
15:52:45 <stain> azaroth: so anyone in that group can access and modify annotations in the container
15:52:57 <stain> azaroth: (?)
15:53:29 <stain> azaroth: so in case of the permissions on the container, if we agree that is the way to go.. then.. license can be associated with the container (?)
15:53:49 <stain> (my apologies, I can only hear the reverb of the room)
15:53:49 <azaroth> q?
15:54:18 <stain> azaroth: thanks for this discussion
15:54:24 <stain> TOPIC: Model:  Ordering in Annotation Lists
15:54:26 <stain> no
15:54:54 <stain> azaroth: from this about the protocol.. what we should add.. license under which an annotation can be reused.
15:55:01 <stain> azaroth: we should enable on container-level initially
15:55:15 <stain> azaroth: permissions (??)
15:55:31 <stain> azaroth: we should work with Social Media WG on this
15:55:54 <stain> azaroth: OAuth pattern seems valuable to mention
15:56:10 <TimCole> +1
15:56:12 <stain> azaroth: is that summary reasonable?
15:56:12 <tbdinesh> +1 azaroth
15:56:13 <paoloC> q+
15:56:19 <azaroth> ack paoloC
15:56:35 <stain> paoloC: so we are just settling on the Container that has to exist..? Is that what you are saying?
15:56:45 <stain> azaroth: so I heard that we should try to do it at container level first
15:57:11 <stain> azaroth: if we end up including it per annotation.... (?)   each annotation has a container?
15:57:32 <stain> paoloC: as I was explaining Annotation Set earlier, I mentioned it can be used both as Grouping By Task, or by Grouping By Restrictions
15:57:37 <stain> paoloC: those can conflate.. and complicate
15:57:47 <stain> paoloC: I don't know how you would handle that in our container model
15:57:57 <stain> paoloC: e.g. 10 annotations in the same task with different permissions
15:58:15 <stain> paoloC: would that be two containers (task/permission)? One single? Then which annotatoin has which permission?
15:58:26 <stain> paoloC: working at container level.. if I understand.. can also be used to group annotations
15:58:28 <Kyrce> +1 paoloC
15:58:32 <shepazu> q+
15:58:50 <stain> azaroth: I would treat the Container as the Service to which the client would use
15:59:03 <stain> azaroth: there could be a separate annotation (?) that includes it in a task
15:59:29 <stain> paoloC: so we are asking if the model level or protocol level.. to ask to have 3 levels.. one container for Set, one for Permission.. and one for (?)
15:59:35 <azaroth> ack shepazu
15:59:42 <stain> paoloC: I understand it's easier to apply the permission, but it sounds to me more complicated
15:59:57 <stain> shepazu: could we model this as saying there could be a Container which is an Annotation of 1
16:00:12 <stain> shepazu: a container can contain Any Number of Annotations, e.g., 0, 1, 2, 1000
16:00:45 <stain> azaroth: shepazu that does make sense.. one container pr annotation
16:01:03 <stain> azaroth: do continue the discussion on the mailing list
16:01:10 <stain> azaroth: we do NOT meet next week
16:01:28 <stain> azaroth: regroup on 2015-05-27
16:01:45 <stain> azaroth: (?) serialization group
16:01:56 <stain> will you do the make-minutes-magic?
16:02:25 <azaroth> thanks Ivan!
16:02:26 <stain> thanks
16:02:29 <ivan> rrsagent, draft minutes
16:02:29 <RRSAgent> I have made the request to generate http://www.w3.org/2015/05/13-annotation-minutes.html ivan
16:02:32 <stain> azaroth: next time.. perhaps not call from the toilet! :))
16:03:12 <azaroth> hehe
16:03:28 <azaroth> It's an office but with very hard walls
16:04:18 <ivan> rrsagent, bye
16:04:27 <ivan> rrsagent, set log public
16:04:31 <ivan> rrsagent, bye
16:04:31 <RRSAgent> I see no action items