Web Annotation Working Group Teleconference

<azaroth> trackbot, start meeting

<trackbot> Meeting: Web Annotation Working Group Teleconference

<trackbot> Date: 11 March 2016

Scribe selection, agenda, announcements?

next meeting time

TimCole: us/canada time is going to be the same and europe 1 hour earlier

ivan: european time will be one hour earlier for the next two weeks
... not sure about how this affects Japane (maybe takeshi can say)

<tbdinesh> we wil all be 1hr earlier.. which is not bad

TimCole: everyone on the call is now aware, this is the plan for the next two weeks, will be noted in the next couple of agendas

takeshi: no daylight saving time in japan, so will be starting at midnight until the fall. will be better (than 1 AM)

Minutes approval

<TimCole> https://www.w3.org/2016/03/04-annotation-minutes.html

TimCole: any objections, corrections etc.?

<TimCole> PROPOSED RESOLUTION: Minutes of the previous call are approved: https://www.w3.org/2016/03/04-annotation-minutes.html

<azaroth> +1

RESOLUTION: Minutes of the previous call are approved: https://www.w3.org/2016/03/04-annotation-minutes.html

Issue: IRI / URI / URL

TimCole: ivan you mentioned a concern about the next topic now, waiting for some feedback from the w3c

ivan: feedback is 'yes, it's a mess', so for moving on let's proceed, can look again if the masses desire

azaroth: proposal is that we should follow the specs we're building on

<TimCole> https://github.com/w3c/web-annotation/issues/183

azaroth: as takeshi notes json-ld and ttl use iri's
... the proposal is to use iri's, will put an explanation in the introduction(?) that explains what that means

TimCole: is the concern that iri's require more escaping (of characters)

azaroth: as ivan says it's a mess; in recent specs though uri is not really used, is usally url or (more recently) iri
... iri gives a nice algorithm to conform with unicode and transformation back to percent encoded form

shepazu: the direction of other w3c specs in the future seems to be url
... shouldn't dwell on this but should have space to revisit on we move to CR and get feedback
... feedback may indicate that the decision needs to be revisited

takeshi: found that each browser deals with urls differently
... will summarize the differences on github

<azaroth> +1 to Takeshi :)

takeshi: will need that information in the document

<shepazu> +1 to takeshi

<TimCole> PROPOSED RESOLUTION: Go with IRI, make necessary changes in docs, revisit when more information

<azaroth> +1

<tbdinesh> +1

<tilgovi> +0

<takeshi> +1

<ivan> +1

+1

<PaoloCiccarese> +0

TimCole: should we change to editorial for now or close

azaroth: change to editorial

<bigbluehat> +1

<bjdmeest> +1

RESOLUTION: Go with IRI, make necessary changes in docs, revisit when more information

Issue 184 https://github.com/w3c/web-annotation/issues/184

TimCole: linking collections to target

azaroth: this came up in another community using annotations
... if you have a collection of annotations that is a list, even if you have a queryable endpoint, it remains complex to find the targets in the collection
... suggested inclusion of a list of included targets
... would allow consumers the ability to decide if the collection is something they want to consume or skip over
... wanted to raise it since it came up in the IIIF community

TimCole: reason to do is if this a common enough use case to be needed in the core

PaoloCiccarese: can we add things to the collections?
... not sure who would use this right now

azaroth: at the moment have extensions and vocab, so could add it as an example to the extensions doc

TimCole: proposing a resolution calling this use case out as an example, can be revisited

<TimCole> PROPOSED RESOLUTION: Add an informative note in extension section calling this use case as an example, if need be later would be revisited.

<PaoloCiccarese> +1

<azaroth> +1

+1

<davis_salisbury> +1

<ivan> +1

<takeshi> +1

<Kyrce> +1

RESOLUTION: Add an informative note in extension section calling this use case as an example, if need be later would be revisited.

TimCole: last two discussions will probably take around 20 minutes each

Conformance https://github.com/w3c/web-annotation/issues/165

ivan: only started the conformance discussion from an editorial point of view
... two or three meetings ago, related to selectors, question came up as to whether every conformant implementation of the model is supposed to implement selectors or not
... easy from the spec point of view to say, must implement everything in the model, but not so easy in practice
... need to identify groups of features in the model and define conformance levels for each group
... for example two levels, basic and full, then decide what basic must implement
... a traditional approach to conformance
... the danger and complication is that this affects testing
... need separate tests fro each profile
... so defining and specifying them now is important

TimCole: resource issue of who will identify and break the features into categories and then the testing

shepazu: idea of profiles is not how modern specs work
... specs that are browser-facing do not use profiles
... tend to define a global spec and then extend with additional specs

<bigbluehat> in JavaScript & HTML focused browser bits?

shepazu: profiles not being done, might be done in other domains

<bigbluehat> or also in document formats?

shepazu: skeptical that profiles will be helpful, leads to incompatibility by design
... are we talking about a client that generates an annotation, a server that interprets an annotation, etc. -- conformance would be helpful and reasonable for behavior categories

<bigbluehat> As long as a "level 1" client can consume a "level 2" document without breaking, what's the issue?

<bigbluehat> I can open HTML5 documents in Navigator 2.0 and still read it ^_^

TimCole: so more about if/how we break down features

PaoloCiccarese: there are core things that I have to implement and maybe some things that I don't need
... if I implement the basic level, then a la carte several optional ones
... is it better to have a basic core and then optional extra features that we'd be happy if everyone implemented

<bigbluehat> no. it's just well designed :)

shepazu: how we figure what needs to be in or out of the core can be based on implementations

ivan: to be clear, not married to profiles idea, but the approach suggested by Paolo is even worse
... don't want to have to test across multiple browsers (like with html 5)

ivan: defining what we expect from them as a behavior, if we don't want profiles, would be fine with a single core model

azaroth: wanted to point out the profiles are being used in CSS

PaoloCiccarese: not a new concept, have discussed this many, many times in the CG

<azaroth> And also at the Santa Clara TPAC

PaoloCiccarese: called extension it  and then not extensions, and went back and forth
... in our case we don't have a minimum bar, we just say this is the spec, and not everyone implements everything

TimCole: recalling from the CG, not all implementors want to implement every selector and say that they implement some of the basic ones but not the more exotic ones

<Zakim> shepazu, you wanted to address CSS

PaoloCiccarese: something like this, was related to collections of selected and recall that the CG had multiple levels

shepazu: regarding css, it's an older spec, started before modern practices took hold
... is also extremely large, is nearly impossible to implement every combination
... many of its issues are related to differences in platforms (e.g., mobiles, etc.)
... reason for css profiles are due to hardware considerations and not software related
... in the case of the json-ld that we have, think that breaking it down would undercut its implementation

ivan: don't see a reason to cut the spec into sub-pieces
... propose we say that conformant implementations must implement what is there
... not so huge as to need a piecemeal approach
... will likely need other types of conformance criteria, e.g., for server, client, etc. behaviors
... a different dimension

shepazu: agree, should be separated according to class of agent rather than portion of model

azaroth: so if have an annotation client that only works for images (e.g., flickr), does that implementation need to implement the css and text selectors to be conformant, or does it only need to implement the svg (and other image specific) selectors in order to conform

shepazu: need to functionally break it down around what it is doing
... is the client generating annotations

ivan: seems like the issues are around selectors
... doesn't seem like the basic model is at issue
... can have performance criteria based on the media types that the particular implementation handles
... e.g., only images and not other media types
... may mean that selectors x, y, z, are not relevant to the implementation
... need a way to describe that
... it becomes a dimension of conformance criteria
... similar to css in that the criteria are around specific media types
... whereas a general purpose client would need to implement everything

azaroth: need to clarify section 4

<TimCole> PROPOSED RESOLUTION: Conformance section will be boilerplate adding notes that conformance for selectors will depend on media types and for rest on class of agent (server, client, ...)

ivan: think that we should be a little more precise than just notes

<azaroth> +1 to Ivan

ivan: have some well-defined lists or tables that e.g., say what selectors need to be implemented in relation to which media types

<davis_salisbury> +1

<ivan> Proposed Resolution: Conformance section will be defined by listing the required selector/states per media types for various classes of agents (server, client)

<TimCole> +1

<azaroth> +1

<ivan> +1

<bjdmeest> +1

<PaoloCiccarese> +1

<davis_salisbury> +1 again thanks

+1

<takeshi> +1

<tbdinesh> +1

<shepazu> 0

RESOLUTION: Conformance section will be defined by listing the required selector/states per media types for various classes of agents (server, client)

TimCole: should be able to change this to editorial
... will post a new issue so that those not on call will be able to think about this

<shepazu> (I'm still concerned that this means we're begging for lack of interoperability)

ivan: need a clear proposal about what these categories are
... leave issue as is, someone come up with a clear proposal moving forward

TimCole: will leave open and wait for the editors to come back with more concrete text

azaroth: or anyone else as well

Testing

TimCole: need someone other than the spec writers to help or take lead on testing

shepazu: will need another testing lead

TimCole: any volunteers?
... what else are folks concerned about that need to be on upcoming agendas?

ivan: when can we push out the next release of the document
... document must go through a bunch of horizontal reviews at w3c
... need feedback from other groups
... conformance doesn't seem very simple
... should we try to get the documents out quickly by leaving conformance open for now?

azaroth: most of the remaining issues that aren't marked as postpone are either done or will be closed through call actions

<shepazu> (conformance is the most important part of a spec… I'm confused what Ivan is suggesting)

azaroth: should go ahead and try to push out the docs as soon as possible

TimCole: only one I'm concerned about is issue #19 (Client can't determine if user has authorization to modify annotation)/#119 (How do we model "groups" in the Annotation model?)
... those are already marked as postpone
... do we need to resolve first?

azaroth: those are both big, time-consuming questions

TimCole: comfortable leaving those for later, how those get addressed may ultimately be controversial

ivan: both issues have not discussed in many months (since like December)
... not sure that they will be properly closed
... need feedback from other groups
... good to have a document that says the technical design is done

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

azaroth: should be able to get model, protocol, and vocab docs in order, however vocab docs only has a few diagrams so will remove the existing ones and add diagrams later
... will take them out for the near term publication and then put them in for CR

ivan: should put in an editorial note rather than remove the existing diagrams

azaroth: cfc via email to try and publish it by next Thursday?

ivan: if possible, will be great
... but moratorium begins soon
... more comfortable to aim for publication in 3 weeks or so rather than next week

TimCole: adjourn