See also: IRC log
<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
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
<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
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