Web Annotation Working Group Teleconference

<ivan> trackbot, start telcon

<trackbot> Meeting: Web Annotation Working Group Teleconference

<trackbot> Date: 26 February 2016

<azaroth> trackbot, start meeting

<trackbot> Meeting: Web Annotation Working Group Teleconference

<trackbot> Date: 26 February 2016

Scribe Selection, Agenda Review, Announcements

<azaroth> scribenick: TimCole

<azaroth> scribe: Tim_Cole

azaroth: Let's review agenda...
... first logistics, then a few issues, then AOB
... anything else?
... any announcements?

Minutes Approval

<azaroth> PROPOSED RESOLUTION: Minutes of the previous call are approved: https://www.w3.org/2016/02/19-annotation-minutes.html

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

Logistics

<azaroth> Register: https://www.w3.org/2002/09/wbs/73180/anno-f2f-berlin-2016/

azaroth: Reminder. Please register for WG f2f using the link in the chat

<azaroth> Wiki: https://www.w3.org/annotation/wiki/Meetings/F2F_Berlin_2016

azaroth: also posting the link to the wiki page
... even if not going, please complete the registration questionaire so we know.

ivan: IAnnotate is posting a list of hotels recommended by MS, etc.

azaroth: we should make sure we get link and circulate...

ivan: Doug or I can do a work around for individuals.
... if you can't get to questionaire, please send W3c user name to to Doug and Ivan

XPath Selector

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

<azaroth> draft: http://w3c.github.io/web-annotation/model/wd2/#xpath-selector

azaroth: the issue is a proposal to add an XPath Selector

<azaroth> proposal: https://github.com/w3c/web-annotation/issues/95#issuecomment-186344208

azaroth: will let us use XPath within in DOM-based targets, including HTML

<ivan> +1 for it, it seems to be a no brainer...

azaroth: questions, comments

fjh: Does XPath have features that we want to exclude from being used as a Selector

azaroth: yes, functions could get messy
... but hesitation about restricting is that then implementers would have to shut down bits of the standard XPath libraries they want to use

<bigbluehat> shepazu: same difference

shepazu: if you want to do what fjh suggested, you could simply identify the parts of XPath implementers should use

<fjh> +1 to suggesting portions to use, otherwise at ‘your own risk’

shepazu: that would not require implementers to shut down bits of XPath libraries

ivan: I don't know that we need to get into the issues about what parts of XPath to use

<bigbluehat> https://www.w3.org/TR/xpath/

ivan: if implementers get over-complicated, that's their responsibility

<azaroth> (+1 to Ivan)

shepazu: but we do want to make sure that we have interoperability

fjh: at a minimum there should be a warning to use XPath intelligently

azaroth: trying to decide what we want people to use is overkill and could set precedent for CSS and other technologies that we want to use as selectors
... we are not suggesting you don't do SVG animation when using SVG selector

<bigbluehat> +1 to our not curtailing what "XPath" means in our spec

azaroth: we took out a OA CG restriction on SVG selectors

<davis_salisbury> +1 to not curtailing

<tbdinesh_> +0

<fjh> fine with a warning and not curtailing

<shepazu> -0

<PaoloCiccarese> -not sure what the danger is

azaroth: a warning for selectors like XPath, CSS, SVG seems a reasonable compromise

<shepazu> (the danger is lack of interoperability)

<azaroth> PROPOSAL: Accept XPathSelector, as written up in the Editor's Draft ; add a warning to CSS, XPath and SVG to use as intended

<azaroth> +1

<tbdinesh_> should we have page authoring guidelines for well behavedness re annotations

<ivan> +1

<PaoloCiccarese> +1

<fjh> +1

<takeshi> +1

<davis_salisbury> +1

RESOLUTION: Accept XPathSelector, as written up in the Editor's Draft ; add a warning to CSS, XPath and SVG to use as intended

Range Selector

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

<azaroth> Draft: http://w3c.github.io/web-annotation/model/wd2/#range-selector

azaroth: this selector has a start point and end point (described by individual selectors) and everything in between is selected.
... this aligns well with how ranges are done in DOM
... makes it easy for implementers familiar with this use in DOM
... still have time to remove from draft a little further on if new concerns arise

<ivan> +1

azaroth: any comments?

PaoloCiccarese: we had a long discussion about these in the CG.
... if we look at example #27, does this suggest range selector replaces existing selectors?

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

azaroth: now it is an addition, not a replacement, but see issue #177...
... let's see what people think about range first, then look at possible merging

<azaroth> PROPOSAL: Accept RangeSelector as written in editor's draft

<ivan> +1

<azaroth> +1

<bigbluehat> +1

<davis_salisbury> +1

<takeshi> +1

<fjh> +1

<PaoloCiccarese> +1

RESOLUTION: Accept RangeSelector as written in editor's draft

issue #177

<ivan> https://github.com/w3c/web-annotation/issues/177

azaroth: we now have 2 ways to select the same span of text (second is using range selector)
... do we need both?

ivan: I think text position selector will be widely used and therefore important to keep

<bigbluehat> +1 to leaving it as is

ivan: but duplication worth it to keep this very simple approach.

PaoloCiccarese: Text miners need the less verbose option when you doing annotations at scale
... Similar issue with data selector
... so I am okay with keeping text selector because of compactness, not sure we want 3.

azaroth: difference between text pos selector and data pos selector is that one works on underlying (e.g., without tags)

<fjh> +1 to leave as is

azaroth: possibly we could merge with a flag to indicate whether we are working on the text stream or 'binary' stream

ivan: would prefer to keep separate, i.e., leave as it is

<azaroth> PROPOSAL: Keep TextPosition, DataPosition and Range Selectors despite some overlap

PaoloCiccarese: agree the way you interpert is different, so merging might make worse than having overlap

<azaroth> +1

<bigbluehat> +1

<PaoloCiccarese> +1

<ivan> +1

<takeshi> +1

+1

<davis_salisbury> +1

RESOLUTION: Keep TextPosition, DataPosition and Range Selectors despite some overlap

Dates in the model

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

<azaroth> Draft: http://w3c.github.io/web-annotation/model/wd2/#lifecycle-information

<azaroth> Draft: http://w3c.github.io/web-annotation/vocab/wd/#json-ld-considerations

azaroth: addressed at 2 points in the draft
... useful to look at JSON-LD context document which lays out how we've done the mapping
... issue - XSD dateTime requires you to have time with time zone
... proposal is to use the W3C Date Time Format
... one catch is that Prov requires XSD DateTime
... so since we already accepted using W3C DTF, the implication is that we are going to change generated (et al.) to map to AS rather than Prov
... so proposed changes to our context document

ivan: I don't fully agree with how you got there, but okay with end result
... that being said, I don't think that because we use labels from an external vocab we have to use their data types

azaroth: ivan is saying that we could continue to map to Prov and still use W3C DTF

ivan: yes, I don't think it is necessary to require XSD DateTime because Prov does
... but if we like AS for other reasons, that's fine

azaroth: yes, AS does make sense here, unless others see it differently
... any one want to retain these two mappings to Prov?

<ivan> +1

<azaroth> PROPOSAL: Replace prov terms with terms from other vocabularies (dcterms, activity streams)

+1

<azaroth> +1

<ivan> +1

<davis_salisbury> +1

<tbdinesh_> +1

azaroth: this is only an issue for the RDF stack users (JSON unchanged)

<PaoloCiccarese> +1

<fjh> +1

<takeshi> +1

RESOLUTION: Replace prov terms with terms from other vocabularies (dcterms, activity streams)

Multiple Selectors, States

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

<azaroth> Draft: http://w3c.github.io/web-annotation/model/wd2/#sub-selection

azaroth: primary issue is 93, but see also see 135
... last time we were leaning towards proposal to use subSelector better than status quo
... proposal preferred to inverse alternative
... suggestion that it was unnecessary
... proposal says to write up subSelector proposal and then discuss as new issue whether to take it out

TimCole: OA CG added multiplicity late to reduce ambiguity and reduce opportunities for misunderstanding
... helped that same construct could be used for selectors and resources used as targets / bodies
... Given reconsideration of multiplicity in general, I am okay with the idea of replacing Choice,
... does add ambiguity in that you have no way certain to identify the preferred alternative,
... but this seems an acceptable amount of ambiguity
... Similarly I am okay with replacing list with nesting

<azaroth> Agree that we've lost preferred alternative for choice

TimCole: However, if I understand correctly, subSelector and subState are intended to be recursive
... so why not just adjust the definition of selector and state to allow recursion and avoid 2 new properties
... the objects that can appear as selector and subSelector values (i.e., their range) is identical
... the only difference is in domain, the domain of selector is SpecificResource,
... while the domain of subSelector is essentially selector or subSelector.
... I would rather see us simply broaden the definition of selector and state to allow recursion
... the only real advantage of the subSelector / subState properties is it makes clear that other
... specifiers do not nest. This can be stated. And if we ever change our mind, no new properties need
... to be added, just up date the definitions to allow.
... The proposed solution seems to leave open the door for considering this idea of simply allowing
... nested recursion of selector and state, but if we get to the point of a CR with subSelector and subState
... we will have in essence precluded doing this since the sub-properties will by then be in general use
... so I in favor of the proposed solution if we very quickly revisit whether we need explicit new
... properties or can make do by simply adjusting the definition of selector and state

ivan: we have agreed to flag a feature as 'at risk'
... so we have the right to remove the feature before going to the next step
... but regardless I don't understand for not having

azaroth: one reason to have is to differentiate selector and state as potentially being chained.
... but also the semantics are a little different
... so you are applying the subSelector to a result (not made explicit) rather than on a source
... not lying down in the road, but preference is to have a different term to make semantics clear and also to differentiate selector or state from other specifier

<davis_salisbury> Sorry folks, need to go.

azaroth: not entirely sure what Nick was after, but if Nick (or Tim) wants to open an issue about need for subSelector and SubState, can do so.

PaoloCiccarese: let's make more concrete
... assume a 3-D model
... assume I rotate the model (State?)
... now I apply a subSelector to select the region of the rotated view

<azaroth> oa:refinedBy ?

PaoloCiccarese: we could have called it refiner instead of subSelector

azaroth: another example is selecting inside a zip file

PaoloCiccarese: Data is also a good use case, since it may take multiple steps to find the right granular

<PaoloCiccarese> I would not

<azaroth> PROPOSAL: Accept overall model, change subSelector/subState to refinedBy

<PaoloCiccarese> +1

<azaroth> +1

TimCole: if we go refinedBy, we would not need separatre subSelector and subState

<ivan> +1

+1

<tbdinesh_> +1

PaoloCiccarese: just to confirm, I can have a chain of them (recursion)

azaroth: yes

RESOLUTION: Accept overall model, change subSelector/subState to refinedBy

<ivan> trackbot, end telcon