Web Annotation Working Group Teleconference

<trackbot> Date: 16 September 2015

Agenda Review, Scribe Selection, Announcements

<fjh> ScribeNick: TimCole

Minutes Approval

<fjh> proposed RESOLUTION: Minutes from 9 September approved,

<fjh> http://www.w3.org/2015/09/09-annotation-minutes.html

RESOLUTION: Minutes from 9 September approved, http://www.w3.org/2015/09/09-annotation-minutes.html

fjh: General issue about the model

<Jacob> Body vs TextBody?

fjh: literal bodies
... we need to think about whether we are making the right assumptions about JSON developers relative to the model
... Are we making the model inconsistent to simplify serialization in ways that are going to create trouble for developers

azaroth: inconsistencies in terms of ease of use

ivan: if it is only inconsistent in terms RDF, that is a different problem

Protocol: Ordering with ActivityStreams Collection not LDP Paging

<fjh> Issue: https://github.com/w3c/web-annotation/issues/50

<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>.

<fjh> Proposal document:

<fjh> http://w3c.github.io/web-annotation/protocol/wd/paging.html

<fjh> close ISSUE-24

<trackbot> Closed ISSUE-24.

azaroth: the issue is around ordering of annotations within LDP container
... in trying to implement the protocol, I ran into the problem that the pages are not ordered
... if you have a long list of annotations, you can decide to return 100 annotations per page

<azaroth> https://github.com/w3c/web-annotation/issues/50

azaroth: you can do this in a way that ensures annotations are not repeated across pages

<fjh> "Several downstream systems have a need for lists of annotations, including EPUB [1] and IIIF [2]."

azaroth: but you don't have ordering within a page.
... Issue #50 would say that if searching, the return would not be ordered by relevance just using ldp:contains
... order would allow optimization
... imagine this for ebook reader
... you want to retrieve the annotations for the ebook in the order of the pages
... you might want to order in terms of distance from reader to annotator
... this is not something you can put on the annotations
... you might have proprietary rankings
... these are illustrative use cases for why internal ordering within a page is valueable
... do people agree that ordering within a page is useful?

<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?

<azaroth> http://w3c.github.io/web-annotation/protocol/wd/paging.html

azaroth: given that this issue can't be solved via ldp:paging alone
... proposed solution is to use Activity Streams approach

<fjh> use cases make sense, ePub is example noted in issue #50 for example

azaroth: allow the client to influence whether ordered, and the server to decide how many per page
... prefer header allows the client to say whether it wants minimal container or more
... ldp doesn't provide a way to say whether you just want URIs or complete annotations
... so propose prefer to differentiate between just URIs or full annotation description
... the first example shows no annotations in the container use case
... the second case is small number of annotations and ordered not required / supported, server just returns them all
... if there is order or if too many annotations to return all at once, then server must use paging
... the server supplies complete link (client doesn't have to construct link to next / previous)
... if URIs requested, sever returns URIs, if full annotations requested, server returns full descriptions
... we are still following ldp pattern, but not ldp paging

fjh: having last allows convenience of starting at other end.

azaroth: yes
... this was quick to implement, less than 5 hours.

<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

<azaroth> https://github.com/azaroth42/mangoserver

<fjh> TimCole: server makes decisions about order to provide, client cannot say ordered by timestamp or other criteria, right?

<fjh> azaroth: correct

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
... 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.

<fjh> TimCole: why didn't LDP do this, are there any downsides?

azaroth: the down side is minimal, but it doesn't work when you have a single huge resource (rather than just a container)
... this allows you to have a set of pages that has whole resources and references to resources, but you can't split big resources
... ldp requires a redirect (range-14 issue)
... proposed solution doesn't require that
... end up with same number of requests, but doesn't force client into page mode in the same way
... ldp WG did discuss, but most of the discussion had concluded by time Rob joined that WG.

<bigbluehat> +1

<ivan> +1

azaroth: should this go in next update of protocol?

<fjh> +1 to including in next draft

+1

<bjdmeest> +1

<Jacob> +1

JSON-LD Usage

<fjh> proposed RESOLUTION: Continue to require JSON-LD structure (#52)

<fjh> proposed RESOLUTION: MUST for JSON-LD / JSON, SHOULD for Turtle, MAY for

<fjh> everything else (#34)

<azaroth> https://github.com/w3c/web-annotation/issues/52

azaroth: The question here is whether or not we should specify the shape of the json-ld
... should we specify something that a json-ld application could work with (i.e., re;ly on)

<azaroth> proposed RESOLUTION: Continue to require JSON-LD structure (#52)

azaroth: consensus seems to be to make the json-ld as easy to work with, so we should require a particular json-ld structure
... for example this would mean not allowing language to be associated with a literal

ivan: we may want to add to the document in an informative appendix a json-ld frame specification
... it cannot be normative because frame is not a standard

azaroth: agree that we've discussed, but may not have reached a consensus.
... but it would be easy to provide.

ivan: I think it would be good to provide since it helps provide a more precise definition of the structure.

azaroth: making new issue for including a framing doc as an appendix

ivan: to make framing a standard, another WG would have to pick it up and move it the rest of the way.

<fjh> new issue has been added by Rob - https://github.com/w3c/web-annotation/issues/80

azaroth: if enough WG add frame documents as informative appendix that may provide impetus for new WG (not this one) to complete that work

<ivan> +1

<azaroth> +1

<Jacob> +1

<takeshi> +1

<fjh> +1 to continue to require specific JSON-LD structure

azaroth: do we agree on #52, require a structrure

<PaoloCiccarese> +1

<bjdmeest> +1

+1

<davis_salisbyry> +1

<bigbluehat> +1

RESOLUTION: Continue to require JSON-LD structure (#52)

azaroth: the result is to be clearer that the examples given in the model are the structures that should be used.

<azaroth> https://github.com/w3c/web-annotation/issues/34

<fjh> follow up action is to add clear statement in document and to also confirm correctness of examples

azaroth: should we require support for Turtle?
... ldp requires Turtle

<fjh> proposed RESOLUTION: MUST for JSON-LD / JSON, SHOULD for Turtle, MAY for everything else (#34)

azaroth: however, the likelihood of people implementing is directly related to its utility
... utility of Turtle is reduced if we require json-ld / json
... proposal is to require json-ld/ld and make Turtle a Should, and May support other serializations
... acknowledge that this is inconsistent with LDP

<ivan> +1

<azaroth> +1

<fjh> +1

<takeshi> +1

<bjdmeest> +1

<Jacob> +1

<davis_salisbyry> +1

azaroth: Rob is personally in favor of doing this

+1

RESOLUTION: MUST for JSON-LD / JSON, SHOULD for Turtle, MAY for everything else (#34)

Renaming

<azaroth> https://github.com/w3c/web-annotation/issues/70

<fjh> proposed RESOLUTION: Retain the current ontology term names (#70)

azaroth: some confusion about whether this applied to the json-ld serialization or to the ontology.
... seems like for now and hopefully forever, we can stick with current ontology names (e.g., hasBody, ...)
... doesn't change the json-ld serialization (our @context document)

<ivan> +1

<Jacob> +!

<Jacob> +1

<fjh> +1

<azaroth> +1

<bjdmeest> +1

<fjh> prefer hasSource, think it is clearer in fact, prefer to use ontology language for JSON-LD JSON

RESOLUTION: Retain the current ontology term names (#70)

<fjh> TimCole: would be good to have consistency in JSON language with model language, where are we with that

<fjh> azaroth: lets keep that a separate issue

<Jacob> I agree with fjh, it looks weird when used in combination with selectors

azaroth: hasSource vs. Content is a separate issue...
... Rob personally prefers Source over Content, but we can discuss further if people want to.

fjh: doesn't think we need to redo this exercise of potential renaming
... should be hesitant to go through renaming just for JSON

ivan: don't touch model

fjh: we should try not to re-open naming even for json-ld

azaorth: agrees that we should avoid going crazy with renaming

ivan: so we should freeze what we have

<fjh> +1 to retain ontology term names

<PaoloCiccarese> +1

<Jacob> +1

<davis_salisbyry> +1

<fjh> suggest to not change JSON-LD mapping names

<azaroth> https://github.com/w3c/web-annotation/issues/53

azaroth: #53 is whether the name space should change

<fjh> proposed RESOLUTION: Retain the current namespace (#53)

azaroth: CG was intentionally only ever creating drafts in expectation that a WG would finalize
... proposal is to retain current namespace, rather than creating one that looks almost identical

ivan: what are the incompatibilities with what we have, at the model level, RDF ?

azaroth: the terms are pretty much all the same.
... the model has changed -- extending and removing
... per body roles allowed us to rationalize tags / semantic tags, no need for semantic tag class any more
... the other main one SimpleTextBody (replacing Content as Text, because the spec was never finalized)
... so we had to make this change

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
... for those on the WG we see this as an ongoing process, but others may not

azaroth: we could mark this issue as defer, and then seek feedback from the CG once next model draft is ready

<Jacob> +1 to what Ivan suggests

ivan: that sounds like the right thing do.

<fjh> +1 to soliciting feedback on using same namespace with noted changes

<azaroth> +1

ivan: 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

fjh: agree with what's been said
... if the changes are relatively benign, but keeping the same namespace, interoperability might be facilitated.
... there are benefits if we are able to keep the same namespace

<fjh> +1 to keep namespace with caveat to seek feedback from community group

azaroth: overall consensus is to keep same namespace for now, pending feedback...

<fjh> but do not keep it if later we make breaking changes

<azaroth> proposed RESOLUTION: Retain the current namespace (#53) and seek feedback on the issue from the CG after the next model draft

<ivan> +1

<azaroth> +1

<bjdmeest> +1

RESOLUTION: Retain the current namespace (#53) and seek feedback on the issue from the CG after the next model draft

<fjh> +1

+1

<azaroth> +1 to Tim

azaroth: good progress last few calls

<fjh> thanks to TimCole for scribing

azaroth: adjourn

Adjourn