Web Annotation Working Group Teleconference

<azaroth> Not yet

<azaroth> s/Not Yet//

<fjh> trackbot, start telecon

<trackbot> Meeting: Web Annotation Working Group Teleconference

<trackbot> Date: 16 December 2015

<fjh> Agenda: https://lists.w3.org/Archives/Public/public-annotation/2015Dec/0083.html

<fjh> Chair: Frederick_Hirsch, Rob_Sanderson

<azaroth> ScribeNick: Jacob

azaroth: Looking at four issues from github, allotting approx. 15 minutes each
... 48 and 49 might require more time, they are complex
... if we can't come to a consensus then we'll defer decisions on them to a later date
... any other topics? any announcements?

ivan: for those who don't already know, benjamin has left as an official participant and is now participating as an invited expert

<fjh> https://www.w3.org/annotation/wiki/PubStatus

<azaroth> PROPOSED RESOLUTION: Minutes of previous call are approved

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

RESOLUTION: Minutes of previous call are approved

<azaroth> Model update: http://w3c.github.io/web-annotation/web-annotation-model/wd/

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

<azaroth> http://w3c.github.io/web-annotation/vocab/wd/

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

azaroth: when we're happy with the fork from splitting model and vocab then we'll [lost exactly what the then effect is...]

doug: would be good to have a consistent way to discover the current editors draft
... didn't advertise the splitting anywhere, need to figure out a consistent way to do this

fjh: update the public links with the 3 editors drafts?

ivan: yes

fjh: will do it

https://github.com/w3c/web-annotation/issues/21

RESOLUTION: Minutes of previous call are approved http://www.w3.org/2015/12/09-annotation-minutes.html

azaroth: issue 1: what was annotations previous uri when copied from somewhere else
... related what is it's offline identity, e.g., dereferencable uri.uuid

doug: collapsing annotaitons from multiple sources seems to be a separate issue from off-line identity

azaroth: proposal is to use "via" for both of those

doug: what if the annotation is simultaneously published in multiple places, doesn't seem to fulfill the requirement

azaroth: content of via is the original uri / identity of the annotation

doug: where is that value coming from

<bigbluehat> looks like this: {"id": "http://example.com/anno", "via": ["http://shepazu.example/anno", "urn:uuid:1234"]}

azaroth: from the client or from wherever the federating server got the id from (see bigbluehat's example)

<bigbluehat> id would === the HTTP URL you got it from

doug: why does it have two different values?
... see where id is identical to the http url...where does the id come from?
... using hypothes.is for example, you publish an annotation simultaneously to three servers (hypothes.is, w3c, [and another one], what is the id?

<bigbluehat> "web resources can have multiple URI's" -- TimBL

azaroth: three different ids based on the servers, and one id in via provided by the hypothes.is client

<fjh> I have updated the publication status page to include Web Annotation Vocabulary document, and update editors draft URL for the Model, https://www.w3.org/annotation/wiki/PubStatus

azaroth: server puts the client id into via and mints a unique id for the annotation for storage[?]
... necessary because we cannot have multiple values for id

PaoloCiccarese: so coming from a different angle, I have my app doesn't generate an id (not very likely) but the server will assign one
... so can use web services to stitch back together later,
... external servers will mint their own uuids and store the uuid generated by my app (assuming it mints one) in via
... because via can have more than one value, may lose the canonical id because new ids are minted each time the annotation is reserialized
... cannot tell which annotation is the original one through via, so doesn't help distinguish the original publisher from subsequent services republishing the anno

<bigbluehat> the canonical one could be {"id": "urn:uuid:1234", "via":["http://example.com/anno"]}...but then `id` may not be dereferenceable

PaoloCiccarese: highlighting an edgecase that might break the via solution, but the intent is to record the original id from the original publisher through the via property

<bigbluehat> and we'd have to require `via`

doug: seems like this reverses the expectation that the canonical id of the annotation is in id and the local id is in via

PaoloCiccarese: if you publish the anno through a server, the server will mint a new id

TimCole: in favor of this proposal, id is the dereferencable uri in the linked data world and not the canonical id in the classical sense that we understand them

<ivan> +1 to Tim

TimCole: the question of one or more ids in via is an important decision moving forward with the proposal
... suggest only using one in via and republications have their own provenance, i.e., become new annotations

<bigbluehat> from http://www.w3.org/TR/json-ld/#node-identifiers "dereferencing the identifier [id] should result in a representation of that node"

<bigbluehat> ...so... {"id": "urn:uuid:1234"} is out

<Zakim> shepazu, you wanted to mention ordering

TimCole: need to develop an approach to resolving how we move down the chains to understand if you're looking at the same annotation or different versions of an annotaiton

<bigbluehat> let's move forward with what's proposed and make proposals to change it as needed

doug: suggest we discuss this further (vie mailing list / github) [defer decision to later]

<bigbluehat> ship it; file issues against it

<bigbluehat> we got +1's on the issue from a wide range of folks already

azaroth: benjamin suggests shipping it, and collect issues

<bigbluehat> shepazu: provide your counter info via GitHub or mailing lists--so we have things to reference in the calls

<bigbluehat> it would help

<bigbluehat> greatly

shepazu: not comfortable with this methodology because the issues collected don't usually get resolved

<bigbluehat> my fear is that the issues don't get collected in anything but call minutes

azaroth: is via better than nothing?

<bigbluehat> via provides a list of known identifiers for use in deduplication, future dereferencing, etc.

shepazu: don't think that it is, think it confuses the issue brought up at tpac rather than solving it

<bigbluehat> so. it does, in fact, do what it was designed to do...could it do more...certainly

ivan: would like to have a clear proposal, what is the alternative

<fjh> +1 to written alternative

azaroth: no resolution for now, shepazu writing an alternative by around 5-january-2016

https://github.com/w3c/web-annotation/issues/30

<azaroth> ACTION on shepazu to write up alternative to via in github issue

<trackbot> Error finding 'on'. You can review and register nicknames at <http://www.w3.org/annotation/track/users>.

<azaroth> ACTION shepazu to write up alternative to via in github issue

<trackbot> Created ACTION-31 - Write up alternative to via in github issue [on Doug Schepers - due 2015-12-23].

<bigbluehat> shepazu: can you write up your issue in an email?

azaroth: next issue - define a json-ld profile for the json-ld serialization of annos
... following tpac, the suggestion is that we can simply use the uri of the context as the uri of the profile if we just want one serialization of the model

<ivan> link to the profile definition for JSON-LD

azaroth: proposal is that the uri of context is the uri of the profile and that we register and thereafter it provides the media type for annos

TimCole: what if an implementor wants to augment the context with additional json-ld keys
... does this get in their way?
... if so, is the hazard of multiple context enough that this is really necessary?

azaroth: if someone wants to define additional keys for additional semantics we can allow that or we could disallow it
... doesn't effect the decision for the profile uri

TimCole: if someone adds another context can they still claim that profile?

azaroth: yes, nothing formal, just a convention

shepazu: how do different profiles of the data relate to different mimetypes?

<ivan> http://www.w3.org/TR/json-ld/#iana-considerations

ivan: see the iana-considerations link; for the json-ld media type

<azaroth> +1 to Ivan

ivan: includes allowances for multiple profiles, so in answer to TimCole, we cannot actually restrict anyone from attaching additional profiles

<fjh> thanks Ivan for clear explanation

ivan: proposal is to add a uri for our profile which is our own context, folding annotations into the json-ld mimetype

shepazu: not clear from the issue that generic json-ld will be used as the mimetype

ivan: allowed to do it if we want, not sure we want to, but it is a separate issue

shepazu: does this mean that if someone wanted to merge activity streams and annos or app specific data and annos, does this proposal effect that?

ivan: can accommodate / merge as necessary by including additional profiles
... server can return a media type "json-ld
... and as many profiles as necessary

shepazu: will raise the mediatype issue on the model (as it is separate from this proposal)

<azaroth> PROPOSAL: Accept context URI as profile URI for json-ld

<azaroth> +1

<fjh> +1

<ivan> +1

+1

<shepazu> +0

<PaoloCiccarese> +1

<davis_salisbury> +1

<TimCole> +1

RESOLUTION: Accept context URI as profile URI for json-ld

azaroth: next issue - #48 - support for search

https://github.com/w3c/web-annotation/issues/48

azaroth: one aspect regarding protocol is whether or how to search a collection of annos for ones that match the client's desired annos
... e.g., a hypothes.is server or some other web server, how to find the annos that target some desired target?
... discussed this at the april f2f but haven't returned to it since then
... aren't many examples of search for annos, in particular no query languages that would make it both easy and convenient to build a search service
... one that I'm aware of is a cultural heritage domain one
... uri based, anything can be fed to the server and the response is similar to activity stream's ordered collections
... is that a reasonable starting place or should we defer search to a later stage?

ivan: added a longer response in the issue list; bottom line is that query can be reproduced but is more inspiration than carried over one-to-one
... a good starting report but will require some work
... not convinced that we should pursue this right now, concerned that too many people are doing the same thing, getting to many similar but slightly different approaches, reinventing wheels others are working on

<azaroth> +1 to Ivan, again :)

ivan: should be clear that we aren't defining the one canonical search for anno servers
... be clear that the search we define is one possible formalism and that others can be developed

<fjh> is Ivan suggesting we defer to v.next, while offering advice?

ivan: yes or no to the issue is whether or not we can be inspired by the search document rather than adopt it
... can someone make a short version of what that search facility means for us
... if we don't have someone to that then we should defer

azaroth: volunteering to be one of the editors on that document
... to make a strawman for what search means for anno servers
... at a minimum say not how to do the search but provide existing pagination as an example
... will produce this by around 15-january-2016

TimCole: concerned that having this in the first round of specs will draw a certain amount of controversy to the spec
... does doing this put the protocol more at risk for objection?

<azaroth> ACTION azaroth to write straw proposal for search, based on IIIF

<trackbot> Created ACTION-32 - Write straw proposal for search, based on iiif [on Robert Sanderson - due 2015-12-23].

TimCole: or does not having it create more of a hazard?

azaroth: don't think it puts the core protocol at risk, we can do search as a separate doc and take through the process separately

ivan: yes, can do things with sparql, but that is the sledgehammer, so should not claim anywhere that it is the definitive query language

<TimCole> +1 to develop as separate document to maintain flexibility

ivan: in favor of having it as a separate document, allowing us to either publish as part of the spec or as a note

azaroth: real risk isn't around the spec process but the time it takes away from other topics

ivan: will need tests, requiring more time commitments

TimCole: having it at least as note sounds like a good strategy, allows us to point people at a doc that supplements the protocol as people need it to

<azaroth> PROPOSAL: The WG will consider a separate document defining a non-exclusive search interface to be published at least as a Note and potentially part of Protocol

<TimCole> +1

<azaroth> +1

<ivan> +1

+1

<PaoloCiccarese> +1

<davis_salisbury> +1

RESOLUTION: The WG will consider a separate document defining a non-exclusive search interface to be published at least as a Note and potentially part of Protocol

azaroth: will defer notification, no call next week (or the week after) because of the holidays, next call on 6-january-2016

<tbdinesh> happy holidays

<azaroth> :)

<ivan> trackbot, end telcon