14:19:11 <RRSAgent> RRSAgent has joined #annotation
14:19:11 <RRSAgent> logging to http://www.w3.org/2015/09/16-annotation-irc
14:19:13 <trackbot> RRSAgent, make logs public
14:19:13 <Zakim> Zakim has joined #annotation
14:19:15 <trackbot> Zakim, this will be 2666
14:19:15 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
14:19:16 <trackbot> Meeting: Web Annotation Working Group Teleconference
14:19:16 <trackbot> Date: 16 September 2015
14:37:41 <azaroth> azaroth has joined #annotation
14:40:05 <fjh> Agenda: https://lists.w3.org/Archives/Public/public-annotation/2015Sep/0182.html
14:40:09 <fjh> fjh has changed the topic to: agenda https://lists.w3.org/Archives/Public/public-annotation/2015Sep/0182.html
14:40:33 <fjh> Chair: Frederick_Hirsch, Rob_Sanderson
14:40:35 <fjh> Present+ Frederick_Hirsch, Rob_Sanderson
14:41:13 <fjh> Topic: Agenda Review, Scribe Selection, Announcements
14:41:59 <fjh> Regrets+ Ray_Denenberg
14:42:22 <fjh> Regrets+ Doug_Schepers
14:45:35 <uskudarli> uskudarli has joined #annotation
14:57:12 <Jacob> Jacob has joined #annotation
14:57:22 <TimCole> TimCole has joined #annotation
14:58:01 <ivan> Present+ Ivan
14:58:32 <Jacob> Present+ Jacob_Jett
14:58:47 <TimCole> Present+ Tim_Cole
15:01:34 <azaroth> Regrets+ TB_DInesh
15:04:45 <fjh> ScribeNick: TimCole
15:04:57 <fjh> Topic: Minutes Approval
15:05:00 <EmrahGuder> EmrahGuder has joined #annotation
15:05:05 <fjh> proposed RESOLUTION: Minutes from 9 September approved,
15:05:06 <fjh> http://www.w3.org/2015/09/09-annotation-minutes.html
15:05:22 <TimCole> RESOLUTION: Minutes from 9 September approved, http://www.w3.org/2015/09/09-annotation-minutes.html
15:05:40 <TimCole> fjh: General issue about the model
15:06:00 <Jacob> Body vs TextBody?
15:06:28 <TimCole> ... literal bodies
15:06:50 <takeshi> takeshi has joined #annotation
15:07:02 <TimCole> ... we need to think about whether we are making the right assumptions about JSON developers relative to the model
15:07:38 <TimCole> ... Are we making the model inconsistent to simplify serialization in ways that are going to create trouble for developers
15:07:48 <bjdmeest> bjdmeest has joined #annotation
15:08:06 <TimCole> azaroth: inconsistencies in terms of ease of use
15:08:28 <bjdmeest> Present+ Ben_De_Meester
15:08:31 <PaoloCiccarese> PaoloCiccarese has joined #annotation
15:08:47 <TimCole> ivan: if it is only inconsistent in terms RDF, that is a different problem
15:08:58 <fjh> Topic: Protocol: Ordering with ActivityStreams Collection not LDP Paging
15:09:10 <fjh> Issue: https://github.com/w3c/web-annotation/issues/50
15:09:11 <trackbot> Created ISSUE-24 - Https://github.com/w3c/web-annotation/issues/50.  Please complete additional details at <http://www.w3.org/annotation/track/issues/24/edit>.
15:09:11 <fjh> Proposal document:
15:09:12 <fjh> http://w3c.github.io/web-annotation/protocol/wd/paging.html
15:09:29 <fjh> close ISSUE-24
15:09:29 <trackbot> Closed ISSUE-24.
15:09:37 <TimCole> azaroth: the issue is around ordering of annotations within LDP container
15:10:02 <bigbluehat> Present+ Benjamin_Young
15:10:08 <TimCole> ... in trying to implement the protocol, I ran into the problem that the pages are not ordered
15:10:30 <takeshi> Present+ Takeshi_Kanai
15:10:46 <TimCole> ... if you have a long list of annotations, you can decide to return 100 annotations per page
15:10:53 <azaroth> https://github.com/w3c/web-annotation/issues/50
15:11:08 <TimCole> ... you can do this in a way that ensures annotations are not repeated across pages
15:11:12 <uskudarli> Present+ Suzan_Uskudarli
15:11:19 <fjh> "Several downstream systems have a need for lists of annotations, including EPUB [1] and IIIF [2]."
15:11:19 <TimCole> ... but you don't have ordering within a page.
15:12:03 <TimCole> ... Issue #50 would say that if searching, the return would not be ordered by relevance just using ldp:contains
15:12:08 <davis_salisbyry> davis_salisbyry has joined #annotation
15:12:16 <TimCole> ... order would allow optimization
15:12:27 <davis_salisbyry> present+ davis_salisbury
15:12:31 <TimCole> ... imagine this for ebook reader
15:12:50 <TimCole> ... you want to retrieve the annotations for the ebook in the order of the pages
15:13:21 <TimCole> ... you might want to order in terms of distance from reader to annotator
15:13:32 <TimCole> ... this is not something you can put on the annotations
15:13:48 <TimCole> ... you might have proprietary rankings
15:14:14 <TimCole> ... these are illustrative use cases for why internal ordering within a page is valueable
15:14:25 <fjh> q?
15:14:28 <TimCole> ... do people agree that ordering within a page is useful?
15:14:58 <Jacob> Seems to me that ordering is implicit in the serialization. so if the anno list is sorted before hand, is it still an issue?
15:15:15 <azaroth> http://w3c.github.io/web-annotation/protocol/wd/paging.html
15:15:20 <TimCole> azaroth: given that this issue can't be solved via ldp:paging alone
15:15:33 <TimCole> ... proposed solution is to use Activity Streams approach
15:15:36 <fjh> use cases make sense, ePub is example noted in issue #50 for example
15:17:05 <TimCole> ...allow the client to influence whether ordered, and the server to decide how many per page
15:17:38 <TimCole> ... prefer header allows the client to say whether it wants minimal container or more
15:18:07 <TimCole> ...ldp doesn't provide a way to say whether you just want URIs or complete annotations
15:18:40 <azaroth> q?
15:18:40 <TimCole> ... so propose prefer to differentiate between just URIs or full annotation description
15:18:58 <TimCole> ... the first example shows no annotations in the container use case
15:19:35 <TimCole> ... the second case is small number of annotations and ordered not required / supported, server just returns them all
15:19:56 <TimCole> ... if there is order or if too many annotations to return all at once, then server must use paging
15:20:26 <TimCole> ... the server supplies complete link (client doesn't have to construct link to next / previous)
15:20:50 <fjh> q+
15:21:16 <TimCole> ... if URIs requested, sever returns URIs, if full annotations requested, server returns full descriptions
15:21:25 <azaroth> ack fjh
15:21:34 <TimCole> ... we are still following ldp pattern, but not ldp paging
15:21:53 <fjh> q?
15:22:03 <TimCole> fjh: having last allows convenience of starting at other end.
15:22:07 <TimCole> azaroth: yes
15:22:17 <TimCole> q+
15:22:34 <TimCole> azaroth: this was quick to implement, less than 5 hours.
15:22:36 <fjh> might want to add Note to doc that developers should make no assumptions about urls, so need to use prev and next for access as well as first and last
15:22:44 <azaroth> https://github.com/azaroth42/mangoserver
15:23:42 <fjh> TimCole: server makes decisions about order to provide, client cannot say ordered by timestamp or other criteria, right?
15:23:45 <fjh> azaroth: correct
15:24:19 <TimCole> azaroth: at core protocol level what's needed is discovery of annotation, if you can get the annotations you can suck them down and do magic
15:25:00 <TimCole> ... but by having this paging pattern available, then when we look at search, additional parameters could be added to deal with filter/query and preferred order.
15:25:11 <azaroth> q?
15:25:14 <azaroth> ack TimCole
15:25:31 <TimCole> q+
15:25:38 <azaroth> ack TimCole
15:25:46 <PaoloCiccarese> Present+ Paolo_Ciccarese
15:25:57 <fjh> TimCole: why didn't LDP do this, are there any downsides?
15:26:22 <TimCole> azaroth: the down side is minimal, but it doesn't work when you have a single huge resource (rather than just  a container)
15:27:01 <TimCole> ... this allows you to have a set of pages that has whole resources and references to resources, but you can't split big resources
15:27:40 <TimCole> ... ldp requires a redirect (range-14 issue)
15:27:49 <TimCole> ... proposed solution doesn't require that
15:28:17 <TimCole> ... end up with same number of requests, but doesn't force client into page mode in the same way
15:28:55 <TimCole> ... ldp WG did discuss, but most of the discussion had concluded by time Rob joined that WG.
15:29:27 <bigbluehat> +1
15:29:31 <ivan> +1
15:29:31 <TimCole> azaroth: should this go in next update of protocol?
15:29:31 <fjh> +1 to including in next draft
15:29:32 <TimCole> +1
15:29:38 <bjdmeest> +1
15:29:41 <Jacob> +1
15:30:17 <fjh> Topic: Protocol: JSON-LD
15:30:17 <TimCole> Topic: JSON-LD Usage
15:30:23 <fjh> proposed RESOLUTION: Continue to require JSON-LD structure (#52)
15:30:24 <fjh> proposed RESOLUTION: MUST for JSON-LD / JSON, SHOULD for Turtle, MAY for
15:30:24 <fjh> everything else (#34)
15:30:30 <azaroth> https://github.com/w3c/web-annotation/issues/52
15:31:12 <TimCole> azaroth: The question her is whether or not we should specify the shape of the json-ld
15:31:37 <fjh> s/her is/here is/
15:31:41 <TimCole> ... should we specify something that a json-ld application could work with (i.e., re;ly on)
15:31:55 <azaroth> proposed RESOLUTION: Continue to require JSON-LD structure (#52)
15:32:13 <TimCole> ... consensus seems to be to make the json-ld as easy to work with, so we should require a particular json-ld structure
15:32:27 <ivan> q+
15:32:30 <azaroth> ack ivan
15:32:36 <TimCole> ... for example this would mean not allowing language to be associated with a literal
15:33:22 <TimCole> ivan: we may want to add to the document in an informative appendix a json-ld frame specification
15:33:35 <TimCole> ... it cannot be normative because frame is not a standard
15:33:53 <TimCole> azaroth: agree that we've discussed, but may not have reached a consensus.
15:33:59 <TimCole> ... but it would be easy to provide.
15:34:23 <TimCole> ivan: I think it would be good to provide since it helps provide a more precise definition of the structure.
15:34:44 <TimCole> azaroth: making new issue for including a framing doc as an appendix
15:35:20 <TimCole> ivan: to make framing a standard, another WG would have to pick it up and move it the rest of the way.
15:35:47 <fjh> new issue has been added by Rob - https://github.com/w3c/web-annotation/issues/80
15:36:04 <TimCole> azaroth: if enough WG add frame documents as informative appendix that may provide impetus for new WG (not this one) to complete that work
15:36:12 <ivan> +1
15:36:16 <azaroth> +1
15:36:17 <Jacob> +1
15:36:31 <takeshi> +1
15:36:32 <fjh> +1 to continue to require specific JSON-LD structure
15:36:33 <TimCole> ... do we agree on #52, require a structrure
15:36:40 <PaoloCiccarese> +1
15:36:41 <bjdmeest> +1
15:36:41 <TimCole> +1
15:37:01 <davis_salisbyry> +1
15:37:08 <bigbluehat> +1
15:37:21 <TimCole> RESOLUTION: Continue to require JSON-LD structure (#52)
15:37:57 <TimCole> azaroth: the result is to be clearer that the examples given in the model are the structures that should be used.
15:38:01 <azaroth> https://github.com/w3c/web-annotation/issues/34
15:38:11 <fjh> follow up action is to add clear statement in document and to also confirm correctness of examples
15:38:19 <TimCole> azaroth: should we require support for Turtle?
15:38:26 <TimCole> ... ldp requires Turtle
15:38:42 <fjh> proposed RESOLUTION: MUST for JSON-LD / JSON, SHOULD for Turtle, MAY for everything else (#34)
15:38:48 <TimCole> ... however, the likelihood of people implementing is directly related to its utility
15:39:06 <TimCole> ... utility of Turtle is reduced if we require json-ld / json
15:39:34 <TimCole> ... proposal is to require json-ld/ld and make Turtle a Should, and May support other serializations
15:39:50 <TimCole> ... acknowledge that this is inconsistent with LDP
15:39:53 <ivan> +1
15:39:54 <azaroth> +1
15:39:57 <fjh> +1
15:40:01 <takeshi> +1
15:40:02 <bjdmeest> +1
15:40:02 <Jacob> +1
15:40:06 <davis_salisbyry> +1
15:40:08 <TimCole> ... Rob is personally in favor of doing this
15:40:14 <TimCole> +1
15:40:27 <TimCole> RESOLUTION: MUST for JSON-LD / JSON, SHOULD for Turtle, MAY for everything else (#34)
15:40:37 <TimCole> Topic: Renaming
15:40:41 <azaroth> https://github.com/w3c/web-annotation/issues/70
15:40:55 <fjh> proposed RESOLUTION:  Retain the current ontology term names (#70)
15:41:14 <TimCole> azaroth: some confusion about whether this applied to the json-ld serialization or to the ontology.
15:41:41 <TimCole> ... seems like for now and hopefully forever, we can stick with current ontology names (e.g., hasBody, ...)
15:42:00 <TimCole> ... doesn't change the json-ld serialization (our @context document)
15:42:11 <ivan> +1
15:42:12 <TimCole> q+
15:42:13 <Jacob> +!
15:42:15 <azaroth> ack TimCole
15:42:15 <Jacob> +1
15:42:15 <fjh> +1
15:42:19 <azaroth> +1
15:42:37 <bjdmeest> +1
15:43:06 <fjh> prefer hasSource, think it is clearer in fact, prefer to use ontology language for JSON-LD JSON
15:43:39 <TimCole> RESOLUTION:  Retain the current ontology term names (#70)
15:43:47 <fjh> TimCole: would be good to have consistency in JSON language with model language, where are we with that
15:43:57 <fjh> azaroth: lets keep that a separate issue
15:43:59 <Jacob> I agree with fjh, it looks weird when used in combination with selectors
15:44:08 <fjh> q+
15:44:11 <TimCole> azaroth: hasSource vs. Content is a separate issue...
15:44:38 <azaroth> ack fjh
15:44:39 <TimCole> ... Rob personally prefers Source over Content, but we can discuss further if people want to.
15:45:11 <TimCole> fjh: doesn't think we need to redo this exercise of potential renaming
15:45:32 <TimCole> ... should be hesitant to go through renaming just for JSON
15:45:54 <TimCole> ivan: don't touch model
15:46:10 <TimCole> fjh: we should try not to re-open naming even for json-ld
15:46:38 <TimCole> azaorth: agrees that we should avoid going crazy with renaming
15:46:46 <TimCole> ivan: so we should freeze what we have
15:46:54 <fjh> +1 to retain ontology term names
15:46:59 <PaoloCiccarese> +1
15:47:02 <Jacob> +1
15:47:02 <davis_salisbyry> +1
15:47:17 <fjh> suggest to not change JSON-LD mapping names
15:47:19 <azaroth> https://github.com/w3c/web-annotation/issues/53
15:47:32 <TimCole> azaroth: #53 is whether the name space should change
15:47:35 <fjh> proposed RESOLUTION:  Retain the current namespace (#53)
15:48:19 <TimCole> ... CG was intentionally only ever creating drafts in expectation that a WG would finalize
15:48:26 <ivan> q+
15:48:31 <azaroth> ack ivan
15:48:40 <TimCole> ... proposal is to retain current namespace, rather than creating one that looks almost identical
15:49:02 <TimCole> ivan: what are the incompatibilities with what we have ?
15:49:14 <TimCole> azaroth: the terms are pretty much all the same.
15:49:19 <fjh> s/what we have/what we have, at the model level, RDF/
15:49:28 <TimCole> ... the model has changed -- extending and removing
15:49:52 <TimCole> ... per body roles allowed us to rationalize tags / semantic tags
15:50:12 <fjh> s/semantic tags/semantic tags, no need for semantic tag class any more/
15:50:26 <TimCole> ... the other main one SimpleTextBody (replacing Content as Text, because the spec was never finalized)
15:50:34 <TimCole> ... so we had to make this change
15:51:28 <TimCole> ivan: whether we change the namespace may bother people external to the WG, e.g., those working with OA, but not participating in the WG
15:51:54 <TimCole> ... for those on the WG we see this as an ongoing process, but others may not
15:51:57 <fjh> q+
15:52:28 <TimCole> azaroth: we could mark this issue as defer, and then seek feedback from the CG once next model draft is ready
15:52:31 <Jacob> +1 to what Ivan suggests
15:52:40 <TimCole> ivan: that sounds like the right thing do.
15:53:02 <fjh> +1 to soliciting feedback on using same namespace with noted changes
15:53:06 <azaroth> +1
15:53:08 <fjh> q?
15:53:13 <azaroth> ack fjh
15:53:14 <TimCole> ... we don't want to say in 3 months that we have a change but there are people using the spec who don't want that change
15:53:23 <TimCole> fjh: agree with what's been said
15:53:54 <TimCole> ... if the changes are relatively benign, but keeping the same namespace, interoperability might be facilitated.
15:54:12 <TimCole> ... there are benefits if we are able to keep the same namespace
15:54:38 <fjh> +1 to keep namespace with caveat to seek feedback from community group
15:54:43 <TimCole> azaroth: overall consensus is to keep same namespace for now, pending feedback...
15:54:49 <fjh> but do not keep it if later we make breaking changes
15:54:53 <azaroth> proposed RESOLUTION:  Retain the current namespace (#53) and seek feedback on the issue from the CG after the next model draft
15:55:00 <ivan> +1
15:55:02 <azaroth> +1
15:55:04 <bjdmeest> +1
15:55:04 <TimCole> RESOLUTION:  Retain the current namespace (#53) and seek feedback on the issue from the CG after the next model draft
15:55:05 <fjh> +1
15:55:11 <TimCole> +1
15:55:37 <TimCole> q+
15:55:40 <azaroth> ack TimCole
15:57:02 <azaroth> +1 to Tim
15:58:22 <TimCole> azaroth: good progress last few calls
15:58:28 <fjh> thanks to TimCole for scribiung
15:58:30 <TimCole> ... adjourn
15:58:36 <fjh> s/scribiung/scribing/
15:58:41 <fjh> topic: Adjourn
15:59:23 <ivan> rrsagent, draft minutes
15:59:23 <RRSAgent> I have made the request to generate http://www.w3.org/2015/09/16-annotation-minutes.html ivan
15:59:34 <ivan> trackbot, end telcon
15:59:34 <trackbot> Zakim, list attendees
15:59:34 <Zakim> As of this point the attendees have been Frederick_Hirsch, Rob_Sanderson, Ivan, Jacob_Jett, Tim_Cole, Ben_De_Meester, Benjamin_Young, Takeshi_Kanai, Suzan_Uskudarli,
15:59:37 <Zakim> ... davis_salisbury, Paolo_Ciccarese, !
15:59:42 <trackbot> RRSAgent, please draft minutes
15:59:42 <RRSAgent> I have made the request to generate http://www.w3.org/2015/09/16-annotation-minutes.html trackbot
15:59:43 <trackbot> RRSAgent, bye
15:59:43 <RRSAgent> I see no action items