IRC log of annotation on 2015-02-18

Timestamps are in UTC.

15:35:40 [RRSAgent]: RRSAgent has joined #annotation
15:35:40 [RRSAgent]: logging to http://www.w3.org/2015/02/18-annotation-irc
15:35:42 [trackbot]: RRSAgent, make logs public
15:35:42 [Zakim]: Zakim has joined #annotation
15:35:44 [trackbot]: Zakim, this will be 2666
15:35:44 [Zakim]: ok, trackbot; I see DPUB_(ANNO)11:00AM scheduled to start in 25 minutes
15:35:45 [trackbot]: Meeting: Web Annotation Working Group Teleconference
15:35:45 [trackbot]: Date: 18 February 2015
15:46:50 [RRSAgent]: RRSAgent has joined #annotation
15:46:50 [RRSAgent]: logging to http://www.w3.org/2015/02/18-annotation-irc
15:46:52 [trackbot]: RRSAgent, make logs public
15:46:54 [trackbot]: Zakim, this will be 2666
15:46:54 [Zakim]: ok, trackbot; I see DPUB_(ANNO)11:00AM scheduled to start in 14 minutes
15:46:55 [trackbot]: Meeting: Web Annotation Working Group Teleconference
15:46:55 [trackbot]: Date: 18 February 2015
15:47:42 [fjh]: Agenda: https://lists.w3.org/Archives/Public/public-annotation/2015Feb/0088.html
15:48:02 [fjh]: fjh has changed the topic to: agenda https://lists.w3.org/Archives/Public/public-annotation/2015Feb/0088.html code 2666
15:48:18 [fjh]: Chair: Frederick_Hirsch, Rob_Sanderson
15:48:22 [fjh]: Present+ Frederick_Hirsch, Rob_Sanderson
15:48:37 [azaroth]: azaroth has joined #annotation
15:49:57 [fjh]: Regrets+ Paolo_Ciccarese, Raphaël_Troncy, Davis_Salisbury
15:51:58 [azaroth]: Thanks!
15:52:02 [azaroth]: (rebooting, brb)
15:55:23 [azaroth]: azaroth has joined #annotation
15:55:34 [RayD]: RayD has joined #annotation
15:56:21 [azaroth_]: azaroth_ has joined #annotation
15:57:49 [Zakim]: DPUB_(ANNO)11:00AM has now started
15:57:56 [Zakim]: +azaroth
15:58:13 [Zakim]: +[IPcaller]
15:58:18 [fjh]: zakim, ipcaller is me
15:58:18 [Zakim]: +fjh; got it
15:58:31 [Zakim]: +dauwhe
15:58:34 [Zakim]: -dauwhe
15:58:55 [Zakim]: +Kyrce
15:59:10 [Zakim]: +dauwhe
15:59:26 [Jacob]: Jacob has joined #annotation
15:59:30 [Zakim]: +Rayd
15:59:33 [dauwhe]: Present+ Dave_Cramer
15:59:43 [Kyrce]: Present+ Kyrce_Swenson
15:59:51 [RayD]: Present+ Ray_Denenberg
15:59:52 [azaroth]: Present+ Rob_Sanderson
15:59:55 [TimCole]: TimCole has joined #annotation
15:59:58 [Jacob]: Present+ Jacob_Jett
16:00:01 [Bill_Kasdorf]: Bill_Kasdorf has joined #annotation
16:00:36 [Zakim]: +TimCole
16:01:00 [Zakim]: +Bill_Kasdorf
16:01:36 [ivan]: zakim, dial ivan-voip
16:01:36 [Zakim]: ok, ivan; the call is being made
16:01:38 [Zakim]: +Ivan
16:02:11 [fjh]: ScribeNick: Kyrce
16:02:17 [Zakim]: +[IPcaller]
16:03:17 [fjh]: zakim, who is here?
16:03:17 [Zakim]: On the phone I see azaroth, fjh, Kyrce, dauwhe, Rayd, TimCole, Bill_Kasdorf, Ivan, [IPcaller]
16:03:20 [Zakim]: 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 [Zakim]: ... rhiaro, oshepherd, stain, trackbot
16:03:30 [Matt_Haas]: Matt_Haas has joined #annotation
16:03:45 [tbdinesh]: tbdinesh has joined #annotation
16:03:59 [tbdinesh]: Present+ TB Dinesh
16:04:14 [Zakim]: +Matt_Haas
16:04:16 [fjh]: Topic: Agenda Review
16:04:23 [TimCole]: Present+ Tim_Cole
16:04:23 [tbdinesh]: Zakim, ipcaller is me
16:04:23 [Zakim]: +tbdinesh; got it
16:04:38 [Matt_Haas]: Present+ Matt_Haas
16:04:53 [Kyrce]: 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 [fjh]: Topic: Minutes Approval
16:05:12 [fjh]: proposed RESOLUTION: 11 February 2015 minutes are approved: http://www.w3.org/2015/02/11-annotation-minutes.html
16:05:19 [fjh]: RESOLUTION: 11 February 2015 minutes are approved: http://www.w3.org/2015/02/11-annotation-minutes.html
16:05:38 [fjh]: Topics: Use Cases
16:06:06 [Kyrce]: 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 [azaroth]: q+
16:06:32 [fjh]: fjh: saw that we have new material related to CSV use cases
16:06:52 [tbdinesh]: i submitted the social semantic web as a use case
16:06:56 [fjh]: ack azaroth
16:07:09 [tbdinesh]: but it would be good to discuss after some offline looking at it
16:07:49 [Kyrce]: 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 [Kyrce]: azaroth: … promote if not user stories, a synthesis of the current playing field.
16:08:25 [Kyrce]: fjh: .. needs action item but not sure who to.
16:08:27 [fjh]: zakim, who is here?
16:08:27 [Zakim]: On the phone I see azaroth, fjh, Kyrce, dauwhe, Rayd, TimCole, Bill_Kasdorf, Ivan, tbdinesh, Matt_Haas
16:08:28 [tbdinesh]: (sorry, my phone with headphone has been a problem often)
16:08:30 [Zakim]: 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 [Zakim]: ... nickstenn, bigbluehat, rhiaro, oshepherd, stain, trackbot
16:08:57 [Kyrce]: azaroth: brief summary—paolo for annotopia, does anyone have other products they want to describe?
16:09:26 [csillag]: csillag has joined #annotation
16:09:34 [azaroth]: ACTION: azaroth to request summary of protocols from Paolo (Domeo) and Nick (Annotator)
16:09:35 [trackbot]: Created ACTION-5 - Request summary of protocols from paolo (domeo) and nick (annotator) [on Robert Sanderson - due 2015-02-25].
16:09:51 [Kyrce]: 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 [Kyrce]: fjh: … might want to capture how use cases relate to our deliverable.s
16:10:14 [Kyrce]: fjh: issues now, anchoring when doug comes later.
16:10:23 [MGU]: MGU has joined #annotation
16:10:24 [fjh]: Topic: Data Model issue review
16:10:58 [Zakim]: +??P21
16:11:11 [MGU]: zakim, ??P21 is MGU
16:11:11 [Zakim]: +MGU; got it
16:11:28 [azaroth]: * Split punning body to body / bodyValue?
16:11:29 [Kyrce]: 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 [Zakim]: +bigbluehat
16:12:24 [tilgovi]: tilgovi has joined #annotation
16:12:37 [Kyrce]: 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 [Zakim]: +??P22
16:12:46 [azaroth]: * How to do a graph as the body?
16:12:53 [csillag]: zakim, ??P22 is csillag
16:12:53 [Zakim]: +csillag; got it
16:14:10 [Zakim]: +Doug_Schepers
16:14:26 [Kyrce]: 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 [azaroth]: * PROV inference rules are broken by serializedBy/annotatedBy (and ...At); drop serialized*? change subPropertyOf?
16:15:15 [bigbluehat]: http://www.w3.org/2004/03/trix/#consynt
16:15:27 [bigbluehat]: TriG's in the list.
16:15:41 [ivan]: http://www.w3.org/TR/trig/
16:15:45 [bigbluehat]: tnx ivan
16:15:49 [fjh]: s/.*consynt//
16:16:04 [Kyrce]: 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 [fjh]: s/???/TriG/
16:16:33 [Kyrce]: 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 [ivan]: q+
16:16:41 [fjh]: ack ivan
16:17:16 [azaroth]: +1 to Ivan
16:18:04 [Kyrce]: 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 [TimCole]: q+
16:19:19 [fjh]: ack TimCole
16:19:23 [Kyrce]: 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 [ivan]: q+
16:19:57 [fjh]: q+
16:20:05 [azaroth]: q+
16:20:15 [fjh]: ack ivan
16:20:16 [azaroth]: ack ivan
16:20:17 [Kyrce]: 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 [shepazu]: q+
16:20:21 [Zakim]: -tbdinesh
16:20:50 [tbdinesh]: (sorry bad skype coonection)
16:20:53 [RayD]: q+
16:20:56 [Jacob]: tuples (i.e. triples)
16:20:57 [fjh]: graph is collection of triples with URI
16:21:03 [azaroth]: Collection of RDF triples that have a URI
16:21:39 [azaroth]: ack fjh
16:21:44 [Kyrce]: 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 [azaroth]: ack azaroth
16:22:07 [Kyrce]: 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 [ivan]: s/tuples/triples/
16:22:25 [Zakim]: +[IPcaller]
16:22:51 [tbdinesh]: zakim, ipcaller is me
16:22:51 [Zakim]: +tbdinesh; got it
16:22:58 [shepazu]: (BTW, here's an explanation of an RDF Triple: http://stackoverflow.com/questions/273218/what-is-an-rdf-triple)
16:23:29 [shepazu]: (more detail: http://webdesign.about.com/od/rdf/a/rdf-triples.htm)
16:23:58 [shepazu]: (basically, Subject, Object, Predicate)
16:24:14 [Kyrce]: 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 [azaroth]: ack shepazu
16:24:48 [Kyrce]: bigbluehat: … talk about how we could achieve what was suggested. Main spec + module for those users, extending data model.
16:25:00 [Kyrce]: ivan: … you don't have to extend the data model.
16:25:07 [fjh]: s/bigbluehat/doug/
16:25:14 [Kyrce]: doug: … not sure that would satisfy the use case
16:25:42 [fjh]: s/doug:/shepazu:/g
16:25:51 [azaroth]: ack RayD
16:25:56 [Kyrce]: 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 [Jacob]: +1 for postponing and addressing via a note or extension
16:26:33 [Kyrce]: 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 [fjh]: proposed RESOLUTION: postpone graph as body issue and address via note or extension
16:27:16 [TimCole]: +1
16:27:17 [fjh]: subsequently
16:27:45 [Kyrce]: Rob: similar. Body would describe a set of triples. Question is if the triples enter the body resource.
16:27:58 [Kyrce]: RayD: will send as part of the mailing list.
16:28:38 [fjh]: proposed RESOLUTION: postpone graph as body issue and address via note or extension if current serialization isn’t sufficient, subsequently
16:28:55 [MGU]: +1
16:28:57 [azaroth]: +1
16:28:59 [shepazu]: +1
16:29:00 [ivan]: +1
16:29:05 [fjh]: RESOLUTION: postpone graph as body issue and address via note or extension if current serialization isn’t sufficient, subsequently
16:29:09 [fjh]: +1
16:29:16 [tbdinesh]: +1
16:29:48 [ivan]: q+
16:29:53 [azaroth]: ack ivan
16:30:35 [Kyrce]: 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 [TimCole]: q+
16:31:47 [Kyrce]: 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 [azaroth]: ack TimCole
16:32:00 [ivan]: q+
16:32:07 [fjh]: s/fjh/azaroth/
16:32:27 [Jacob]: Can we just handle this by assigning a sub-type to the body rather than minting some new predicate?
16:32:28 [Kyrce]: 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 [azaroth]: ack ivan
16:33:35 [Kyrce]: 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 [fjh]: zakim, who is here?
16:34:21 [Zakim]: 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 [Zakim]: 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 [Zakim]: ... JakeHart, Mitar, dwhly, nickstenn, bigbluehat, rhiaro, oshepherd, stain, trackbot
16:34:29 [Kyrce]: 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 [ivan]: q+
16:34:43 [azaroth]: ack ivan
16:35:32 [Kyrce]: 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 [ivan]: q+
16:36:26 [Kyrce]: 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 [Kyrce]: 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 [Zakim]: + +1.434.971.aaaa
16:38:10 [RayD]: q+
16:38:14 [Kyrce]: 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 [fjh]: ack ivan
16:38:26 [azaroth]: ack RayD
16:38:33 [davis_salisbury]: davis_salisbury has joined #annotation
16:39:40 [Kyrce]: 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 [TimCole]: if we go 2 property route should we go body and bodyResource
16:39:45 [fjh]: should we record in the use cases or elsewhere, the relative importance of inferencing to the design?
16:40:08 [Kyrce]: azaroth: … leave the model as it stands in the first public working draft?
16:40:13 [ivan]: +1
16:40:16 [fjh]: proposed RESOLUTION: resolve body property issue by keeping as in FPWD
16:40:18 [RayD]: +1
16:40:19 [TimCole]: +1
16:40:20 [ivan]: +1
16:40:21 [Jacob]: +1
16:40:25 [MGU]: +1
16:40:30 [azaroth]: proposed RESOLUTION: leave the model as it stands in the FPWD with a punning property, pending further discussion from interested parties
16:40:30 [fjh]: q+
16:40:39 [fjh]: ack fjh
16:40:53 [Kyrce]: fjh: … suggest that we record in the use cases our view that inferencing is a lower priority.
16:41:12 [Kyrce]: azaroth: … in the principles and data model document.
16:41:26 [Kyrce]: fjh: … then the question won't come up as much. So it's necessary.
16:41:39 [azaroth]: ACTION: azaroth to add that inferencing is not an important design criterion to data model principles
16:41:40 [trackbot]: 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 [fjh]: I would say that it is important but lower priority than usability in other contexts
16:42:10 [Kyrce]: azaroth: good progress on those two issues. Shall we cut over or do one more?
16:42:16 [azaroth]: * PROV inference rules are broken by serializedBy/annotatedBy (and ...At); drop serialized*? change subPropertyOf?
16:43:08 [Kyrce]: 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 [Kyrce]: azaroth: … if there are two agents for these. For generation, there can only be one reference
16:44:11 [ivan]: q+
16:44:44 [Kyrce]: 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 [Kyrce]: 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 [fjh]: s/annotaiton/annotation/
16:45:44 [fjh]: q+
16:46:01 [azaroth]: ack ivan
16:46:09 [Jacob]: Is it possible to shift annotatedAt/By to be a property of the body?
16:46:12 [Kyrce]: 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 [fjh]: +1 to importance of keeping information
16:47:17 [tantek]: tantek has joined #annotation
16:47:17 [Kyrce]: 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 [Kyrce]: azaroth: Luc brought up the issue
16:47:45 [Jacob]: +1 for Ivan's suggestion
16:47:47 [azaroth]: https://github.com/w3c/web-annotation/issues/10
16:47:50 [Kyrce]: ivan: … without a solution? then we need him to propose a solution
16:47:51 [fjh]: +1 ask for proposed solution in conjunction with raising issue
16:48:01 [fjh]: q?
16:48:35 [Kyrce]: fjh: … I agree with Ivan. This brings inferencing back. Luc should provide a proposed solution.
16:49:14 [Kyrce]: 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 [Kyrce]: azaroth: ask Luc to come up with a proposal that leaves things simple but doesn't fall into the problem.
16:50:01 [Kyrce]: azaroth: … Thank you for going through the issues. Let's cut over to anchoring.
16:50:38 [azaroth]: ACTION: azaroth to ask Luc to propose a solution for #10 / #7
16:50:38 [trackbot]: Created ACTION-7 - Ask luc to propose a solution for #10 / #7 [on Robert Sanderson - due 2015-02-25].
16:50:43 [fjh]: Topic: Robust Anchoring
16:50:48 [Kyrce]: 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 [csillag]: q+
16:51:23 [fjh]: ack fjh
16:51:24 [azaroth]: ACTION: azaroth to update github issues to avoid repetition
16:51:24 [trackbot]: Created ACTION-8 - Update github issues to avoid repetition [on Robert Sanderson - due 2015-02-25].
16:52:00 [azaroth]: zakim, who is here?
16:52:00 [Zakim]: 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 [Zakim]: 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 [Zakim]: ... MarkS, KevinMarks, JakeHart, Mitar, dwhly, nickstenn, bigbluehat, rhiaro, oshepherd, stain, trackbot
16:52:09 [Kyrce]: 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 [Kyrce]: fjh: do we know what the concern is and what the root cause is?
16:52:26 [azaroth]: s/TimCole/shepazu/
16:52:35 [csillag]: shall I wait for my place in the que, or should I just jump in?
16:52:37 [Zakim]: +dwhly
16:52:40 [azaroth]: q?
16:52:41 [Kyrce]: Shepazu: I'll go ahead and try to characterize it.
16:52:44 [azaroth]: ack csillag
16:52:49 [csillag]: can you here me?
16:52:52 [dwhly]: no
16:53:15 [fjh]: s/can you here me?/
16:53:19 [fjh]: s/no//
16:53:29 [fjh]: zakim, who is here?
16:53:29 [Zakim]: 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 [Zakim]: 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 [Zakim]: ... MarkS, KevinMarks, JakeHart, Mitar, dwhly, nickstenn, bigbluehat, rhiaro, oshepherd, stain, trackbot
16:55:03 [azaroth]: q+
16:55:20 [fjh]: fjh: thanks for reminding me of the issue, now I remember the desire for more information
16:55:28 [csillag]: I'll exit and re-join my voice connection
16:55:31 [fjh]: shepazu: selectors input, return is best match, can have a variety of inputs for selection
16:55:38 [Kyrce]: 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 [Zakim]: -csillag
16:56:59 [fjh]: so issue is getting deterministic response for selector algorithm, which might not be so easy, right?
16:57:01 [Kyrce]: 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 [Zakim]: +??P7
16:57:30 [csillag]: zakin, +??p7 is csillag
16:57:38 [fjh]: seems like an important concern. Can we narrow the scope/concern?
16:57:40 [csillag]: zakim, +??P7 is csillag
16:57:40 [Zakim]: sorry, csillag, I do not recognize a party named '+??P7'
16:57:59 [Kyrce]: 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 [fjh]: q+
16:58:08 [ivan]: zakim, ??p7 is csillag
16:58:08 [Zakim]: +csillag; got it
16:59:03 [fjh]: can we start with a very simple algorithm?
16:59:07 [Kyrce]: 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 [Kyrce]: shepazu: … do this in a way that would not disrupt even past implementations. Still would be most reliable result.
17:00:10 [fjh]: thanks Doug for clear overview
17:00:26 [azaroth]: Just to note that we can't punt on the /model/ side of things -- we need to have some selectors.
17:00:45 [Kyrce]: 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 [azaroth]: Thanks all :)
17:00:53 [Zakim]: -azaroth
17:00:55 [fjh]: q?
17:00:56 [fjh]: q-
17:00:58 [fjh]: q-
17:01:06 [fjh]: q-
17:01:09 [shepazu]: q+
17:01:10 [fjh]: ack azaroth
17:01:23 [Kyrce]: csillag: … The other thing I wanted to note: there are two opinions one to standardize and one to not.
17:01:24 [dwhly]: +q
17:01:26 [Zakim]: -fjh
17:01:49 [ivan]: ack shepazu
17:02:37 [fjh]: cannot join
17:02:47 [ivan]: +1 to that 'sort' option
17:02:53 [fjh]: suggest we Adjourn
17:02:56 [Kyrce]: 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 [RayD]: gotta go
17:03:03 [Zakim]: -Rayd
17:03:08 [fjh]: Kyrce, thank you very much for scribing!
17:03:18 [Zakim]: -Bill_Kasdorf
17:03:40 [fjh]: Thanks all for a very productive call
17:03:59 [Kyrce]: 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 [Kyrce]: Ivan: … dwhly urgent? we need to pick this up later.
17:05:21 [Kyrce]: dwhly: … don't want to characterize things as minority or majority. Do we have enough information to standardize is the question.
17:05:31 [Kyrce]: dwhly: … put it on the agenda again and discuss
17:05:37 [Kyrce]: ivan: … adjourn now.
17:06:01 [Kyrce]: ivan: … clearly something for another week. Thank you all. We are adjourned.
17:06:04 [Zakim]: -dwhly
17:06:04 [Zakim]: -TimCole
17:06:05 [MGU]: MGU has left #annotation
17:06:05 [Zakim]: -Kyrce
17:06:06 [Zakim]: - +1.434.971.aaaa
17:06:07 [Zakim]: -Doug_Schepers
17:06:07 [Zakim]: -Matt_Haas
17:06:08 [Zakim]: -MGU
17:06:10 [Zakim]: -tbdinesh
17:06:12 [ivan]: rrsagent, draft minutes
17:06:12 [RRSAgent]: I have made the request to generate http://www.w3.org/2015/02/18-annotation-minutes.html ivan
17:06:13 [Zakim]: -bigbluehat
17:06:16 [Zakim]: -csillag
17:06:16 [Kyrce]: Kyrce has left #annotation
17:06:17 [Zakim]: -dauwhe
17:06:17 [Zakim]: -Ivan
17:06:18 [Zakim]: DPUB_(ANNO)11:00AM has ended
17:06:18 [Zakim]: 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 [ivan]: trackbot, end telcon
17:06:52 [trackbot]: Zakim, list attendees
17:06:52 [Zakim]: sorry, trackbot, I don't know what conference this is
17:07:00 [trackbot]: RRSAgent, please draft minutes
17:07:00 [RRSAgent]: I have made the request to generate http://www.w3.org/2015/02/18-annotation-minutes.html trackbot
17:07:01 [trackbot]: RRSAgent, bye
17:07:01 [RRSAgent]: I see 4 open action items saved in http://www.w3.org/2015/02/18-annotation-actions.rdf :
17:07:01 [RRSAgent]: ACTION: azaroth to request summary of protocols from Paolo (Domeo) and Nick (Annotator) [1]
17:07:01 [RRSAgent]: recorded in http://www.w3.org/2015/02/18-annotation-irc#T16-09-34
17:07:01 [RRSAgent]: ACTION: azaroth to add that inferencing is not an important design criterion to data model principles [2]
17:07:01 [RRSAgent]: recorded in http://www.w3.org/2015/02/18-annotation-irc#T16-41-39
17:07:01 [RRSAgent]: ACTION: azaroth to ask Luc to propose a solution for #10 / #7 [3]
17:07:01 [RRSAgent]: recorded in http://www.w3.org/2015/02/18-annotation-irc#T16-50-38
17:07:01 [RRSAgent]: ACTION: azaroth to update github issues to avoid repetition [4]
17:07:01 [RRSAgent]: recorded in http://www.w3.org/2015/02/18-annotation-irc#T16-51-24