15:35:40 RRSAgent has joined #annotation 15:35:40 logging to http://www.w3.org/2015/02/18-annotation-irc 15:35:42 RRSAgent, make logs public 15:35:42 Zakim has joined #annotation 15:35:44 Zakim, this will be 2666 15:35:44 ok, trackbot; I see DPUB_(ANNO)11:00AM scheduled to start in 25 minutes 15:35:45 Meeting: Web Annotation Working Group Teleconference 15:35:45 Date: 18 February 2015 15:46:50 RRSAgent has joined #annotation 15:46:50 logging to http://www.w3.org/2015/02/18-annotation-irc 15:46:52 RRSAgent, make logs public 15:46:54 Zakim, this will be 2666 15:46:54 ok, trackbot; I see DPUB_(ANNO)11:00AM scheduled to start in 14 minutes 15:46:55 Meeting: Web Annotation Working Group Teleconference 15:46:55 Date: 18 February 2015 15:47:42 Agenda: https://lists.w3.org/Archives/Public/public-annotation/2015Feb/0088.html 15:48:02 fjh has changed the topic to: agenda https://lists.w3.org/Archives/Public/public-annotation/2015Feb/0088.html code 2666 15:48:18 Chair: Frederick_Hirsch, Rob_Sanderson 15:48:22 Present+ Frederick_Hirsch, Rob_Sanderson 15:48:37 azaroth has joined #annotation 15:49:57 Regrets+ Paolo_Ciccarese, Raphaël_Troncy, Davis_Salisbury 15:51:58 Thanks! 15:52:02 (rebooting, brb) 15:55:23 azaroth has joined #annotation 15:55:34 RayD has joined #annotation 15:56:21 azaroth_ has joined #annotation 15:57:49 DPUB_(ANNO)11:00AM has now started 15:57:56 +azaroth 15:58:13 +[IPcaller] 15:58:18 zakim, ipcaller is me 15:58:18 +fjh; got it 15:58:31 +dauwhe 15:58:34 -dauwhe 15:58:55 +Kyrce 15:59:10 +dauwhe 15:59:26 Jacob has joined #annotation 15:59:30 +Rayd 15:59:33 Present+ Dave_Cramer 15:59:43 Present+ Kyrce_Swenson 15:59:51 Present+ Ray_Denenberg 15:59:52 Present+ Rob_Sanderson 15:59:55 TimCole has joined #annotation 15:59:58 Present+ Jacob_Jett 16:00:01 Bill_Kasdorf has joined #annotation 16:00:36 +TimCole 16:01:00 +Bill_Kasdorf 16:01:36 zakim, dial ivan-voip 16:01:36 ok, ivan; the call is being made 16:01:38 +Ivan 16:02:11 ScribeNick: Kyrce 16:02:17 +[IPcaller] 16:03:17 zakim, who is here? 16:03:17 On the phone I see azaroth, fjh, Kyrce, dauwhe, Rayd, TimCole, Bill_Kasdorf, Ivan, [IPcaller] 16:03:20 On IRC I see Bill_Kasdorf, TimCole, Jacob, azaroth, RayD, RRSAgent, Kyrce, fjh, Zakim, dauwhe, ivan, shepazu, MarkS, KevinMarks, JakeHart, Mitar, dwhly, nickstenn, bigbluehat, 16:03:20 ... rhiaro, oshepherd, stain, trackbot 16:03:30 Matt_Haas has joined #annotation 16:03:45 tbdinesh has joined #annotation 16:03:59 Present+ TB Dinesh 16:04:14 +Matt_Haas 16:04:16 Topic: Agenda Review 16:04:23 Present+ Tim_Cole 16:04:23 Zakim, ipcaller is me 16:04:23 +tbdinesh; got it 16:04:38 Present+ Matt_Haas 16:04:53 fjh:… approve minutes, go through data model issues, no protocol discussions scheduled. Robust anchoring—not much we can do right now. Anything else? 16:05:04 Topic: Minutes Approval 16:05:12 proposed RESOLUTION: 11 February 2015 minutes are approved: http://www.w3.org/2015/02/11-annotation-minutes.html 16:05:19 RESOLUTION: 11 February 2015 minutes are approved: http://www.w3.org/2015/02/11-annotation-minutes.html 16:05:38 Topics: Use Cases 16:06:06 fjh: … paolo cannot attend on use cases issues on csv, not up to date, we want to add a column but we are not sure how that would work. Is there more on use cases that we can discuss on this call? 16:06:21 q+ 16:06:32 fjh: saw that we have new material related to CSV use cases 16:06:52 i submitted the social semantic web as a use case 16:06:56 ack azaroth 16:07:09 but it would be good to discuss after some offline looking at it 16:07:49 azaroth: … progress with protocol use cases. existing products that use some kind of protocol and see if we can get common use cases out of them. how iAnnotator works, or how any third party annotation tools works. 16:08:05 azaroth: … promote if not user stories, a synthesis of the current playing field. 16:08:25 fjh: .. needs action item but not sure who to. 16:08:27 zakim, who is here? 16:08:27 On the phone I see azaroth, fjh, Kyrce, dauwhe, Rayd, TimCole, Bill_Kasdorf, Ivan, tbdinesh, Matt_Haas 16:08:28 (sorry, my phone with headphone has been a problem often) 16:08:30 On IRC I see tbdinesh, Matt_Haas, Bill_Kasdorf, TimCole, Jacob, azaroth, RayD, RRSAgent, Kyrce, fjh, Zakim, dauwhe, ivan, shepazu, MarkS, KevinMarks, JakeHart, Mitar, dwhly, 16:08:30 ... nickstenn, bigbluehat, rhiaro, oshepherd, stain, trackbot 16:08:57 azaroth: brief summary—paolo for annotopia, does anyone have other products they want to describe? 16:09:26 csillag has joined #annotation 16:09:34 ACTION: azaroth to request summary of protocols from Paolo (Domeo) and Nick (Annotator) 16:09:35 Created ACTION-5 - Request summary of protocols from paolo (domeo) and nick (annotator) [on Robert Sanderson - due 2015-02-25]. 16:09:51 fjh: … azaroth ask nick. nick will indicate if he is the right person. one issue between linkage of protocol and data model. Decouple as much as possible. Zip files, etc. Decouple deliverables as much as we can. 16:10:03 fjh: … might want to capture how use cases relate to our deliverable.s 16:10:14 fjh: issues now, anchoring when doug comes later. 16:10:23 MGU has joined #annotation 16:10:24 Topic: Data Model issue review 16:10:58 +??P21 16:11:11 zakim, ??P21 is MGU 16:11:11 +MGU; got it 16:11:28 * Split punning body to body / bodyValue? 16:11:29 azaroth: did some cleaning which prompted some issues. Run through them at a high level. Pick one or two to work on, whatever we think is most interesting to people on the call. fjh: Is there a way to enter issues into chat? 16:12:05 +bigbluehat 16:12:24 tilgovi has joined #annotation 16:12:37 azaroth: … body property either an object or a literal string as its value. That seemed to fulfill most of the requirements. After the first public working draft there was further discussion. Need to be able to do inferencing, etc. Suggestion is that we split body into body which is always a resource and bodyvalue which is always a string. 16:12:37 +??P22 16:12:46 * How to do a graph as the body? 16:12:53 zakim, ??P22 is csillag 16:12:53 +csillag; got it 16:14:10 +Doug_Schepers 16:14:26 azaroth: … Next is how to have a graph as a body of an annotation. Instead of having a human readable comment, we have a machine readable content. It would be valuable to be able to express the value by using a small graph. In Json ld this is pretty straightforward. So that would solve the problem, ??? does not have the concept. Some discussion on what had been the recommendation or what had not. 16:14:33 * PROV inference rules are broken by serializedBy/annotatedBy (and ...At); drop serialized*? change subPropertyOf? 16:15:15 http://www.w3.org/2004/03/trix/#consynt 16:15:27 TriG's in the list. 16:15:41 http://www.w3.org/TR/trig/ 16:15:45 tnx ivan 16:15:49 s/.*consynt// 16:16:04 azaroth: … In the community group model we have annotatedBy and annotatedAt for some— Trig is a serialization of RDF that supports graphs. 16:16:33 s/???/TriG/ 16:16:33 azaroth: … my thought was to go through all of them and then pick ones to go over with but I am also happy to stop on the ones where people have interest. 16:16:37 q+ 16:16:41 ack ivan 16:17:16 +1 to Ivan 16:18:04 ivan: … The problem with the main graph thing is that we bring in yet another obstruction that even less people know about than RDF. That creates problems. You and I have background; we know this. But there are few people who know this. I'd like to see alternatives and more on the original problem. It's a source of discussion even among experts. 16:18:30 q+ 16:19:19 ack TimCole 16:19:23 azaroth: … paolo has the use case. When you have comments that are generated through machines, where the machine understands the semantics, it would be nice for systems to be able to have a machine-readable comment or body so you can include the graphs for processing. 16:19:45 q+ 16:19:57 q+ 16:20:05 q+ 16:20:15 ack ivan 16:20:16 ack ivan 16:20:17 TimCole: … community group wanted to use real use cases, only interesting to a few people. Allow it, and let people who want to use it, use it. The other option: not allow it and wait until the pressure from those who allow it to put it in. Not sure which is better. Can put it in a way that most people can ignore. 16:20:19 q+ 16:20:21 -tbdinesh 16:20:50 (sorry bad skype coonection) 16:20:53 q+ 16:20:56 tuples (i.e. triples) 16:20:57 graph is collection of triples with URI 16:21:03 Collection of RDF triples that have a URI 16:21:39 ack fjh 16:21:44 ivan: … apologies to those who don't understand. A graph is a collection of tuples RDF statements that have a URI and this collection has a URI of its own. In some sense it can be addressed today without complications. I think we should postpone for now. 16:22:04 ack azaroth 16:22:07 fjh: I agree. the use case in LD is a non-issue. Can we just require JSON-LD and be done with it? 16:22:08 s/tuples/triples/ 16:22:25 +[IPcaller] 16:22:51 zakim, ipcaller is me 16:22:51 +tbdinesh; got it 16:22:58 (BTW, here's an explanation of an RDF Triple: http://stackoverflow.com/questions/273218/what-is-an-rdf-triple) 16:23:29 (more detail: http://webdesign.about.com/od/rdf/a/rdf-triples.htm) 16:23:58 (basically, Subject, Object, Predicate) 16:24:14 shepazu: … the issue was in supporting in one serialization and what can be said in another. Then it becomes problematic. One of the options in the community group or before we already have a way to say a body and it has this format. You can still embed the triples, they would not be part of the serialization. i think that is what Ivan is suggesting? If it does not have the URI it cannot be embedded. I would be happy with the solution in the meantime 16:24:15 ack shepazu 16:24:48 bigbluehat: … talk about how we could achieve what was suggested. Main spec + module for those users, extending data model. 16:25:00 ivan: … you don't have to extend the data model. 16:25:07 s/bigbluehat/doug/ 16:25:14 doug: … not sure that would satisfy the use case 16:25:42 s/doug:/shepazu:/g 16:25:51 ack RayD 16:25:56 shepazu: if we find that it does not, I am in favor of a simpler spec. If we need to extend it—extended feature is what you want. 16:25:58 +1 for postponing and addressing via a note or extension 16:26:33 RayD: … directed at Rob, related to BIBframe and you understand that. Is this the same issue? Bodies that have properties. is that the same? 16:27:07 proposed RESOLUTION: postpone graph as body issue and address via note or extension 16:27:16 +1 16:27:17 subsequently 16:27:45 Rob: similar. Body would describe a set of triples. Question is if the triples enter the body resource. 16:27:58 RayD: will send as part of the mailing list. 16:28:38 proposed RESOLUTION: postpone graph as body issue and address via note or extension if current serialization isn’t sufficient, subsequently 16:28:55 +1 16:28:57 +1 16:28:59 +1 16:29:00 +1 16:29:05 RESOLUTION: postpone graph as body issue and address via note or extension if current serialization isn’t sufficient, subsequently 16:29:09 +1 16:29:16 +1 16:29:48 q+ 16:29:53 ack ivan 16:30:35 ivan … trying to understand the issue. Issue when we had the discussion with the csv people. They want to have an annotation of one string and a reference to the target. I would like that finalized so we can finalize the csv doc. 16:31:03 q+ 16:31:47 fjh: current model is that you can have either a string or the object in JSON LD. And revision for the next draft to add a second property bodyValue. The rationale behind it: instead of checking type of resource, you could check for two different properties. Still do inferencing more easily. 16:31:51 ack TimCole 16:32:00 q+ 16:32:07 s/fjh/azaroth/ 16:32:27 Can we just handle this by assigning a sub-type to the body rather than minting some new predicate? 16:32:28 TimCole: …I thought to not have second predicate was compelling. I think that having it check to see if its a string would be easier than checking for a second value. 16:32:35 ack ivan 16:33:35 Ivan: … I agree with everything Tim says today. It depends on who we want to optimize for. How many people in our community really want to do serious inferencing? for most users, simplicity is more important. 16:34:19 zakim, who is here? 16:34:21 On the phone I see azaroth, fjh, Kyrce, dauwhe, Rayd, TimCole, Bill_Kasdorf, Ivan, Matt_Haas, MGU, bigbluehat, csillag, Doug_Schepers, tbdinesh 16:34:21 On IRC I see tilgovi, MGU, csillag, tbdinesh, Matt_Haas, Bill_Kasdorf, TimCole, Jacob, azaroth, RayD, RRSAgent, Kyrce, fjh, Zakim, dauwhe, ivan, shepazu, MarkS, KevinMarks, 16:34:22 ... JakeHart, Mitar, dwhly, nickstenn, bigbluehat, rhiaro, oshepherd, stain, trackbot 16:34:29 azaroth: it was antoine who was in favor of us splitting the properties. I forget what his motivation was. It seemed convincing to me at the time. 16:34:37 q+ 16:34:43 ack ivan 16:35:32 Ivan: … so the point is that for the JSON world, a property value can be a string or an object is a widely used pattern. There is nothing surprising or offputting about this for that community. Those are our users in my view. For RDF users, perhaps they will need other tricks. 16:36:24 q+ 16:36:26 azaroth: … one point: if the body can be either a resource or a literal, if its a resource you have to give it a JSON object construction. Which is asymmetric with target, which will almost always be a URI. And that's confusing. 16:37:05 Ivan: … I can envisage the target may be more complicated for some media than URI. We may have an object for target as well (eg, Bnode). I wouldn't bet on target being simple. 16:38:04 + +1.434.971.aaaa 16:38:10 q+ 16:38:14 azaroth: … not always simple. But if 99% use case is simple tagging, then that's the situation we should optimize for and the target would be a string and you would get the asymmetry. We can postpone the issue or we can have the consensus to leave as is. 16:38:20 ack ivan 16:38:26 ack RayD 16:38:33 davis_salisbury has joined #annotation 16:39:40 RayD: Prior to this discussion, I wanted two properties. But this discussion made me change my mind. Antoine was arguing a year or so ago when inferencing was thought to be more important. This is no longer true today. We should rethink the two properties. 16:39:45 if we go 2 property route should we go body and bodyResource 16:39:45 should we record in the use cases or elsewhere, the relative importance of inferencing to the design? 16:40:08 azaroth: … leave the model as it stands in the first public working draft? 16:40:13 +1 16:40:16 proposed RESOLUTION: resolve body property issue by keeping as in FPWD 16:40:18 +1 16:40:19 +1 16:40:20 +1 16:40:21 +1 16:40:25 +1 16:40:30 proposed RESOLUTION: leave the model as it stands in the FPWD with a punning property, pending further discussion from interested parties 16:40:30 q+ 16:40:39 ack fjh 16:40:53 fjh: … suggest that we record in the use cases our view that inferencing is a lower priority. 16:41:12 azaroth: … in the principles and data model document. 16:41:26 fjh: … then the question won't come up as much. So it's necessary. 16:41:39 ACTION: azaroth to add that inferencing is not an important design criterion to data model principles 16:41:40 Created ACTION-6 - Add that inferencing is not an important design criterion to data model principles [on Robert Sanderson - due 2015-02-25]. 16:42:00 I would say that it is important but lower priority than usability in other contexts 16:42:10 azaroth: good progress on those two issues. Shall we cut over or do one more? 16:42:16 * PROV inference rules are broken by serializedBy/annotatedBy (and ...At); drop serialized*? change subPropertyOf? 16:43:08 azaroth: the next one is from inferencing rules. We inherit these from the provenance ontology. About the agent that creates the annotations. annotatedBy/annotatedAt, serialzedBy/serializedAt 16:43:31 azaroth: … if there are two agents for these. For generation, there can only be one reference 16:44:11 q+ 16:44:44 azaroth: … two possible approaches. We have to change this because we are facing some rules. We could split up annotaiton into two separate resources: artifact and conceptual, so they can use the same term. we had decided against this in the past because it makes the model more complex. 16:45:16 azaroth: … we could drop serializedBy/serializedAt and say we don't need this info and the annotation would always just be the concept. 16:45:19 s/annotaiton/annotation/ 16:45:44 q+ 16:46:01 ack ivan 16:46:09 Is it possible to shift annotatedAt/By to be a property of the body? 16:46:12 azaroth: simplest we can change it so it is not part of the provenance ontology and then we would avoid the inferencing problem. This does not change our model but seems the least pure. So we have some things that are provenance and some that are not but they look like the come from the same. 16:46:19 +1 to importance of keeping information 16:47:17 tantek has joined #annotation 16:47:17 ivan: … keeping this information somewhere is important. e.g., in scientific environments this information is part of the discourse. Let's postpone this and talk to Luc Moreau. See what the issue is from him and perhaps he has a better idea to solve this. 16:47:37 azaroth: Luc brought up the issue 16:47:45 +1 for Ivan's suggestion 16:47:47 https://github.com/w3c/web-annotation/issues/10 16:47:50 ivan: … without a solution? then we need him to propose a solution 16:47:51 +1 ask for proposed solution in conjunction with raising issue 16:48:01 q? 16:48:35 fjh: … I agree with Ivan. This brings inferencing back. Luc should provide a proposed solution. 16:49:14 azaroth: +1 from me as well. Suggested: change the mapping. Not sure what this would entail. Making it not part of the mapping, but I'm not certain. 16:49:45 azaroth: ask Luc to come up with a proposal that leaves things simple but doesn't fall into the problem. 16:50:01 azaroth: … Thank you for going through the issues. Let's cut over to anchoring. 16:50:38 ACTION: azaroth to ask Luc to propose a solution for #10 / #7 16:50:38 Created ACTION-7 - Ask luc to propose a solution for #10 / #7 [on Robert Sanderson - due 2015-02-25]. 16:50:43 Topic: Robust Anchoring 16:50:48 fjh: … is there a way to mark the issue we postpone so we don't go over them endlessly? azaroth: … we will postpone on github. 16:51:19 q+ 16:51:23 ack fjh 16:51:24 ACTION: azaroth to update github issues to avoid repetition 16:51:24 Created ACTION-8 - Update github issues to avoid repetition [on Robert Sanderson - due 2015-02-25]. 16:52:00 zakim, who is here? 16:52:00 On the phone I see azaroth, fjh, Kyrce, dauwhe, Rayd, TimCole, Bill_Kasdorf, Ivan, Matt_Haas, MGU, bigbluehat, csillag, Doug_Schepers, tbdinesh, +1.434.971.aaaa 16:52:04 On IRC I see tantek, davis_salisbury, tilgovi, MGU, csillag, tbdinesh, Matt_Haas, Bill_Kasdorf, TimCole, Jacob, azaroth, RayD, RRSAgent, Kyrce, fjh, Zakim, dauwhe, ivan, shepazu, 16:52:04 ... MarkS, KevinMarks, JakeHart, Mitar, dwhly, nickstenn, bigbluehat, rhiaro, oshepherd, stain, trackbot 16:52:09 TimCole: … There is some disagreement about whether or not this should be done at all. Some people are uncomfortable with standardizing. Next step is to carve out a week where I can draw up strawman for API. 16:52:21 fjh: do we know what the concern is and what the root cause is? 16:52:26 s/TimCole/shepazu/ 16:52:35 shall I wait for my place in the que, or should I just jump in? 16:52:37 +dwhly 16:52:40 q? 16:52:41 Shepazu: I'll go ahead and try to characterize it. 16:52:44 ack csillag 16:52:49 can you here me? 16:52:52 no 16:53:15 s/can you here me?/ 16:53:19 s/no// 16:53:29 zakim, who is here? 16:53:29 On the phone I see azaroth, fjh, Kyrce, dauwhe, Rayd, TimCole, Bill_Kasdorf, Ivan, Matt_Haas, MGU, bigbluehat, csillag, Doug_Schepers, tbdinesh, +1.434.971.aaaa, dwhly 16:53:33 On IRC I see tantek, davis_salisbury, tilgovi, MGU, csillag, tbdinesh, Matt_Haas, Bill_Kasdorf, TimCole, Jacob, azaroth, RayD, RRSAgent, Kyrce, fjh, Zakim, dauwhe, ivan, shepazu, 16:53:33 ... MarkS, KevinMarks, JakeHart, Mitar, dwhly, nickstenn, bigbluehat, rhiaro, oshepherd, stain, trackbot 16:55:03 q+ 16:55:20 fjh: thanks for reminding me of the issue, now I remember the desire for more information 16:55:28 I'll exit and re-join my voice connection 16:55:31 shepazu: selectors input, return is best match, can have a variety of inputs for selection 16:55:38 Shepazu: not sure where csillag sits on this, please revise me. Some of us at hypothes.is feel like we don't know enough to put forward a solution, to put forward an algorithm on how things would behave. put in set of selectors, including string you are looking for. The API would return the best match. Selectors; text string, maybe distance on string, xpath, 32 characters before or after, etc. Find in page API would take these things and find closest match. 16:56:48 -csillag 16:56:59 so issue is getting deterministic response for selector algorithm, which might not be so easy, right? 16:57:01 shepazu: concern from hypothes.is is that this goal would be to specify the algorithm. the implementation should follow this algorithm. Same return value on any document in all browsers. Same behavior. Same range. To do that we would need to 1. specify algorithm. 2. test behavoir exhaustively 16:57:17 +??P7 16:57:30 zakin, +??p7 is csillag 16:57:38 seems like an important concern. Can we narrow the scope/concern? 16:57:40 zakim, +??P7 is csillag 16:57:40 sorry, csillag, I do not recognize a party named '+??P7' 16:57:59 shepazu: … question whether we know enough right now to say what the algorithm should be. It has been said that it should be up to the implementation so they could optimize—but as a dev, I don't want inconsistencies across browsers. 16:57:59 q+ 16:58:08 zakim, ??p7 is csillag 16:58:08 +csillag; got it 16:59:03 can we start with a very simple algorithm? 16:59:07 shepazu: we want interoperability over optimization. interoperability means that people can reliably build apps. Second: I think we can specify algorithms so we can extend in the future. First pass today; allow different ordering of selectors and let new algorithms be introduced or improved. 16:59:31 shepazu: … do this in a way that would not disrupt even past implementations. Still would be most reliable result. 17:00:10 thanks Doug for clear overview 17:00:26 Just to note that we can't punt on the /model/ side of things -- we need to have some selectors. 17:00:45 csillag: … add two things. Several different levels to standardaze. 1. API, how do we access text content and run searches. Concrete things we can plug into the API. We can standardize the API without standardizing the algorithm. 17:00:46 Thanks all :) 17:00:53 -azaroth 17:00:55 q? 17:00:56 q- 17:00:58 q- 17:01:06 q- 17:01:09 q+ 17:01:10 ack azaroth 17:01:23 csillag: … The other thing I wanted to note: there are two opinions one to standardize and one to not. 17:01:24 +q 17:01:26 -fjh 17:01:49 ack shepazu 17:02:37 cannot join 17:02:47 +1 to that 'sort' option 17:02:53 suggest we Adjourn 17:02:56 shepazu: … agree about the idea of letting authors provide their own algorithms. example: the sort method in js arrays, where you give a specific algorithm for sort. Find out in the wild what the most optimized or popular algorithm would be. 17:03:01 gotta go 17:03:03 -Rayd 17:03:08 Kyrce, thank you very much for scribing! 17:03:18 -Bill_Kasdorf 17:03:40 Thanks all for a very productive call 17:03:59 shepazu: a robust anchoring API is more robust than text. Not everything you want to robustly anchor will be text. You search for other DOM nodes, including a portion of an image, a map, any other resource. 17:04:33 Ivan: … dwhly urgent? we need to pick this up later. 17:05:21 dwhly: … don't want to characterize things as minority or majority. Do we have enough information to standardize is the question. 17:05:31 dwhly: … put it on the agenda again and discuss 17:05:37 ivan: … adjourn now. 17:06:01 ivan: … clearly something for another week. Thank you all. We are adjourned. 17:06:04 -dwhly 17:06:04 -TimCole 17:06:05 MGU has left #annotation 17:06:05 -Kyrce 17:06:06 - +1.434.971.aaaa 17:06:07 -Doug_Schepers 17:06:07 -Matt_Haas 17:06:08 -MGU 17:06:10 -tbdinesh 17:06:12 rrsagent, draft minutes 17:06:12 I have made the request to generate http://www.w3.org/2015/02/18-annotation-minutes.html ivan 17:06:13 -bigbluehat 17:06:16 -csillag 17:06:16 Kyrce has left #annotation 17:06:17 -dauwhe 17:06:17 -Ivan 17:06:18 DPUB_(ANNO)11:00AM has ended 17:06:18 Attendees were azaroth, fjh, dauwhe, Kyrce, Rayd, TimCole, Bill_Kasdorf, Ivan, Matt_Haas, tbdinesh, MGU, bigbluehat, csillag, Doug_Schepers, +1.434.971.aaaa, dwhly 17:06:52 trackbot, end telcon 17:06:52 Zakim, list attendees 17:06:52 sorry, trackbot, I don't know what conference this is 17:07:00 RRSAgent, please draft minutes 17:07:00 I have made the request to generate http://www.w3.org/2015/02/18-annotation-minutes.html trackbot 17:07:01 RRSAgent, bye 17:07:01 I see 4 open action items saved in http://www.w3.org/2015/02/18-annotation-actions.rdf : 17:07:01 ACTION: azaroth to request summary of protocols from Paolo (Domeo) and Nick (Annotator) [1] 17:07:01 recorded in http://www.w3.org/2015/02/18-annotation-irc#T16-09-34 17:07:01 ACTION: azaroth to add that inferencing is not an important design criterion to data model principles [2] 17:07:01 recorded in http://www.w3.org/2015/02/18-annotation-irc#T16-41-39 17:07:01 ACTION: azaroth to ask Luc to propose a solution for #10 / #7 [3] 17:07:01 recorded in http://www.w3.org/2015/02/18-annotation-irc#T16-50-38 17:07:01 ACTION: azaroth to update github issues to avoid repetition [4] 17:07:01 recorded in http://www.w3.org/2015/02/18-annotation-irc#T16-51-24