- From: Ivan Herman <ivan@w3.org>
- Date: Fri, 26 Feb 2016 18:37:01 +0100
- To: W3C Public Annotation List <public-annotation@w3.org>
- Message-Id: <56183EDA-5FDE-4507-A51B-F7DD6D21AFFD@w3.org>
Minutes are here:
https://www.w3.org/2016/02/26-annotation-minutes.html
text version below.
ivan
----
Ivan Herman, W3C
Digital Publishing Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704
[1]W3C
[1] http://www.w3.org/
Web Annotation Working Group Teleconference
26 Feb 2016
[2]Agenda
[2] http://www.w3.org/mid/CABevsUHPphbug7QnmHNfjiwcugFyJtGJGOERouHQXYZ5qfGxPw@mail.gmail.com
See also: [3]IRC log
[3] http://www.w3.org/2016/02/26-annotation-irc
Attendees
Present
Ivan Herman, Frederick Hirsch, Rob Sandersion (azaroth),
Tim Cole, Benjamin Young (bigbluehat), Jacob Jett, Doug
Schepers (shepazu), Davis Salisbury, Paolo Ciccarese,
Ben De Meester, Chris Birk, TB Dinesh, Takeshi Kanai
Regrets
Dan Whaley
Chair
Rob Sanderson
Scribe
Tim Cole
Contents
* [4]Topics
1. [5]Scribe Selection, Agenda Review, Announcements
2. [6]Minutes Approval
3. [7]Logistics
4. [8]XPath Selector
5. [9]Range Selector
6. [10]issue #177
7. [11]Dates in the model
8. [12]Multiple Selectors, States
* [13]Summary of Action Items
* [14]Summary of Resolutions
__________________________________________________________
<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:
[15]https://www.w3.org/2016/02/19-annotation-minutes.html
[15] https://www.w3.org/2016/02/19-annotation-minutes.html
RESOLUTION: Minutes of the previous call are approved:
[16]https://www.w3.org/2016/02/19-annotation-minutes.html
[16] https://www.w3.org/2016/02/19-annotation-minutes.html
Logistics
<azaroth> Register:
[17]https://www.w3.org/2002/09/wbs/73180/anno-f2f-berlin-2016/
[17] 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:
[18]https://www.w3.org/annotation/wiki/Meetings/F2F_Berlin_2016
[18] 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:
[19]https://github.com/w3c/web-annotation/issues/95
[19] https://github.com/w3c/web-annotation/issues/95
<azaroth> draft:
[20]http://w3c.github.io/web-annotation/model/wd2/#xpath-select
or
[20] http://w3c.github.io/web-annotation/model/wd2/#xpath-selector
azaroth: the issue is a proposal to add an XPath Selector
<azaroth> proposal:
[21]https://github.com/w3c/web-annotation/issues/95#issuecommen
t-186344208
[21] 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> [22]https://www.w3.org/TR/xpath/
[22] 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:
[23]https://github.com/w3c/web-annotation/issues/153
[23] https://github.com/w3c/web-annotation/issues/153
<azaroth> Draft:
[24]http://w3c.github.io/web-annotation/model/wd2/#range-select
or
[24] 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:
[25]https://github.com/w3c/web-annotation/issues/177
[25] 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> [26]https://github.com/w3c/web-annotation/issues/177
[26] 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:
[27]https://github.com/w3c/web-annotation/issues/141
[27] https://github.com/w3c/web-annotation/issues/141
<azaroth> Draft:
[28]http://w3c.github.io/web-annotation/model/wd2/#lifecycle-in
formation
[28] http://w3c.github.io/web-annotation/model/wd2/#lifecycle-information
<azaroth> Draft:
[29]http://w3c.github.io/web-annotation/vocab/wd/#json-ld-consi
derations
[29] 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:
[30]https://github.com/w3c/web-annotation/issues/93
[30] https://github.com/w3c/web-annotation/issues/93
<azaroth> Draft:
[31]http://w3c.github.io/web-annotation/model/wd2/#sub-selectio
n
[31] 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
Summary of Action Items
Summary of Resolutions
1. [32]Minutes of the previous call are approved:
https://www.w3.org/2016/02/19-annotation-minutes.html
2. [33]Accept XPathSelector, as written up in the Editor's
Draft ; add a warning to CSS, XPath and SVG to use as
intended
3. [34]Accept RangeSelector as written in editor's draft
4. [35]Keep TextPosition, DataPosition and Range Selectors
despite some overlap
5. [36]Replace prov terms with terms from other vocabularies
(dcterms, activity streams)
6. [37]Accept overall model, change subSelector/subState to
refinedBy
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [38]scribe.perl version
1.144 ([39]CVS log)
$Date: 2016/02/26 17:32:04 $
[38] http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm
[39] http://dev.w3.org/cvsweb/2002/scribe/
Received on Friday, 26 February 2016 17:37:12 UTC