- From: Ivan Herman <ivan@w3.org>
- Date: Fri, 4 Mar 2016 18:13:40 +0100
- To: W3C Public Annotation List <public-annotation@w3.org>
- Message-Id: <6E8DD02C-395F-4068-8016-38DEBFD61656@w3.org>
Minutes are here:
https://www.w3.org/2016/03/04-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
04 Mar 2016
[2]Agenda
[2] http://www.w3.org/mid/CABevsUEFmryvoUFvg-4O2WfiOwr_0LSi1yJ5fxB20HBdhEeXng@mail.gmail.com
See also: [3]IRC log
[3] http://www.w3.org/2016/03/04-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,
Randall Leeds, Dan Whaley
Regrets
Nick Stenning
Chair
Rob
Scribe
Benjamin_Young
Contents
* [4]Topics
1. [5]WG Chairing
2. [6]Issues
1. [7]https://github.com/w3c/web-annotation/issues/1
10
2. [8]Extension Capacity:
https://github.com/w3c/web-annotation/issues/154
3. [9]Document annotation service endpoint rel:
https://github.com/w3c/web-annotation/issues/174
4. [10]IRI vs URI: -
https://github.com/w3c/web-annotation/issues/183
* [11]Summary of Action Items
* [12]Summary of Resolutions
__________________________________________________________
<scribe> Agenda: announcement, chairs discussion, and a handful
of issues
[13]https://lists.w3.org/Archives/Public/public-annotation/2016
Mar/0005.html
[13] https://lists.w3.org/Archives/Public/public-annotation/2016Mar/0005.html
azaroth: are there any other issues important to discuss not
represented on the agenda?
... k. we'll run with what we have
... announcements
<dwhly> +q
azaroth: other than the chairing conversation are there others?
ivan: at this moment there are 10 people registered with a
'wish to come' to the face to face
... if there are others who want to come, please register
... last week I sent a list of hotels
... they're also linked from the iannotate.org site
... make reservations soon to avoid extra expenses
dwhly: we have put a program committee together for I Annotate
2016
... you can see it on the site
... please send in submissions for talks if you'd like to give
one
... sometime in the next week would be great
... Rob, it'd be great if you might make a presentation on the
face-to-face output
azaroth: any other announcements?
... approving minutes from last time
<azaroth> PROPOSED RESOLUTION: Minutes of the previous call are
approved:
[14]https://www.w3.org/2016/02/26-annotation-minutes.html
[14] https://www.w3.org/2016/02/26-annotation-minutes.html
azaroth: any problems with the minutes?
RESOLUTION: Minutes of the previous call are approved:
[15]https://www.w3.org/2016/02/26-annotation-minutes.html
[15] https://www.w3.org/2016/02/26-annotation-minutes.html
WG Chairing
azaroth: announcement and discussion about working group
chairing
ivan: things are busy for fjh and consequently it's hard to do
both chairing and keep up with other responsibilities
... he will still be active in the group
... but not as a co-chair
<shepazu> +1 to fjh
ivan: first of all, we should all thank fjh for his help from
the beginning
<azaroth> Thank you Frederick!
<davis_salisbury> Thank you!
ivan: as a replacement for fjh, TimCole_ has accepted the
co-chair position
<tbdinesh> Thank you!
fjh++ :)
scribe: it has not been more widely announced, as we wanted to
tell the WG call first
... announcement will go out later this week or Monday
<fjh> Thanks all, congratulations to Tim. I think the group has
good chairing going forward!
fjh: just wanted to say congrats Tim and thanks everyone!
TimCole_: the transition should be smooth. I've been here since
the beginning, and I'm happy to serve in this capacity
fjh: tnx to ivan shepazu and azaroth and TimCole_ for working
through the transition
azaroth: my heart felt thanks to you fjh for your dedication
and hard work!
<fjh> Thanks!
azaroth: it's super appreciated
Issues
azaroth: as a note, these issues are the last ones that we
have!
... if we can get through these plus the new one from takeshi,
our queue will be clear
... we'll have to discuss testing, the html serialization, etc.
... but focusing on the 3 core specifications, this is pretty
much it
... while it's been particularly product to force march through
issues, we can reconsider that approach
... and with TimCole_ as co-chair, it probably makes sense for
Tim to take a more active role in the chairing
... and I would focus more on editorial
[16]https://github.com/w3c/web-annotation/issues/110
[16] https://github.com/w3c/web-annotation/issues/110
azaroth: The first issue, is issue 110
<azaroth> Proposal is:
[17]https://github.com/w3c/web-annotation/issues/110#issuecomme
nt-188963956
[17] https://github.com/w3c/web-annotation/issues/110#issuecomment-188963956
ivan: I started this issue....I don't even remember
when...based on the recognition
... that whatever we do here
... to identify part of a document could be combined with other
specifications
... and would have huge value beyond just annotation
... if you want to see the use cases, feel free to read through
the long discussion
... this did come in a little bit late, so there's lots of
discussion about how to make it happen
... what we're proposing now is...
... in terms of the standard, there are very very few changes
... on the vocab level, very few changes
... on the vocab level it's mostly resorting how the classes
and sub-classes are done
... so they can be more widely used
... it's one of the last comments on the issues list
[18]https://github.com/w3c/web-annotation/issues/110#issuecomme
nt-188963956
[18] https://github.com/w3c/web-annotation/issues/110#issuecomment-188963956
scribe: there's essentially just some editorial work to be done
... essentially a cut and paste from the model document
... but put it in a less-annotation-bound space
... so others could use them without digging through a
recommendation that may not be in their core interest
... There was a side issue that came up during the discussion
... whether it was good to map the selectors into a fragment
identifier
... technically, this is not hard
... socially, it's very unclear
... for instance registering a fragment identifier for HTML is
not technically possible
... we would leave that work to future WGs
<azaroth> +1 to putting it in the note
scribe: that sums it up. sound right?
azaroth: yes.
... it's basically a best practices document about how to use
our work outside of annotation
... the changes come in at the vocab level rather than the
model
shepazu: while I agree that this could theoretically be useful
outside of annotation
... unless there's really compelling need outside of the group
... we should do the minimum
... I don't hear people clamoring to reuse this stuff
... most people are not going to use more than CSS selectors
for their stuff
... without wider review, then I don't think it makes sense to
spend much time on this
... until we have more outside attention on it, I think we
should do any substantial work on this...
ivan: since the work is minimal, then I don't think we disagree
... as for the use cases, on the one hand, there was one big
one
... that certainly was a big use case (by Jacob, I think)
... when I talked to epub and publishing groups, they would
very much like something like this
... the combination of all these is very powerful
<azaroth> I suggest not going through the use cases, if Doug is
willing to accept that they exist, across communities
ivan: the current way of selecting things within an eboook is
pretty ugly
shepazu: I just don't think this is a high priority issue
ivan: than I propose we go along with what's been
proposed--which is minimal
<ivan>
[19]https://github.com/w3c/web-annotation/issues/110#issuecomme
nt-188963956
[19] https://github.com/w3c/web-annotation/issues/110#issuecomment-188963956
ivan: this is the comment for the specific proposal
[20]https://github.com/w3c/web-annotation/issues/110#issuecomme
nt-188963956
... let's go along with that, and coming up with a NOTE is
typically not disturbing to the working group
[20] https://github.com/w3c/web-annotation/issues/110#issuecomment-188963956
TimCole_: I support the proposal, with the understanding that
we should highlight that there's potential for future
development here
... the one class of use cases that are compelling involve
multiple selectors
... that's hard to do in any of the current mish-mash
environments
... applying a sequence or a variation of selectors is
currently tricky
... that's not for us to solve now
... but noting that it would be good ground for the future
seems prudent
<shepazu> (at this point, use cases are less important than
specific requests and commitment from implementers to actually
implement these outside of Web Annotations)
azaroth: any further thoughts?
... since GitHub allows issues to be edited, I'll restate the
resolution here
<azaroth> PROPOSAL: In vocab, split SpecificResource into
Annotation / non Annotation specific classes, Selectors and
States as associated with the non Annotation specific class;
describe the usage in a Note
<ivan> +1
<azaroth> +1
+1
<TimCole_> +1
<takeshi> +1
<davis_salisbury> +1
<tbdinesh> +1
<bjdmeest> +1
<shepazu> -0
RESOLUTION: In vocab, split SpecificResource into Annotation /
non Annotation specific classes, Selectors and States as
associated with the non Annotation specific class; describe the
usage in a Note
Extension Capacity
[21]https://github.com/w3c/web-annotation/issues/154
[21] https://github.com/w3c/web-annotation/issues/154
azaroth: the next issue is around extension
... the bulk of the content has already been done
... we allow for multiple @context's in the text
<shepazu> *I don't think this should have been prioritized,
since it doesn't change our implementations behavior)
azaroth: we will liberally crib from the extension section from
the ActivityStreams document
... to help folks looking to extend the model a place to find
this content
... in general, how does that seem?
<TimCole_> +1 to having extension section in vocab
azaroth: The vocabulary section seems to be the right place to
do it
... how do we feel about those things?
... k. we can turn that into an editorial issue and review that
once it's done
... and...I seem to have confused two issues
... there's also an issue of I18N of values in an annotation
ivan: let's close this one first
<azaroth> PROPOSAL: Add extension section to vocab not model,
proposing the use of multiple json-ld contexts
<ivan> +1
<shepazu> (extensions are fine, but let's not pretend we
haven't committed the spec to JSON-LD / RDF already)
+1
<PaoloCiccarese> +1
<azaroth> +1
<TimCole_> +1
<shepazu> + 0
<takeshi> +1
<davis_salisbury> +1
<tbdinesh> +1
<tilgovi> +1
RESOLUTION: Add extension section to vocab not model, proposing
the use of multiple json-ld contexts
<azaroth> I18n issue:
[22]https://github.com/w3c/web-annotation/issues/154#issuecomme
nt-191421726
[22] https://github.com/w3c/web-annotation/issues/154#issuecomment-191421726
azaroth: currently, the model only has the text of the Body for
humans to read--and we have I18N support here already
... so my thinking is that this is an extension problem--not a
model problem
... it would be sufficient to say, this is an extension issue
and we use JSON-LD for extension, so do it that way
... or we can recommend a patter, and give the rationale for
that
ivan: if we push it on the JSON-LD side, then implementations
may miss it because they'll be focused on the model document
... or we are completely silent on it
... we don't have any 3rd choice, I think
... if we point people to JSON-LD the ground seems a bit shaky
TimCole_: ivan how is this being address by other groups?
ivan: we had that in the CSV metadata
... which defines a JSON format which is JSON-LD compatible
<azaroth> Activity Streams does the map version:
[23]https://www.w3.org/TR/activitystreams-core/#naturalLanguage
Values
[23] https://www.w3.org/TR/activitystreams-core/#naturalLanguageValues
ivan: we essentially adopted one specific approach in the
equivalent "model" type document
TimCole_: the patterns that azaroth indicated, would we put
that in vocab? and then model would talk about it?
azaroth: no, the 'label' bit was from the example use case
given
ivan: oh. well that's....since we don't have a label, then we
don't need this
<shepazu> +1 to ivan
azaroth: right. it's only for extension
ivan: then it's irrelevant
... we talk about extension, then specific implementations
would do it that way
... they can use that by whatever means, and they would
document how to use those extensions, and this thing here would
be part of that extension documentation
... but not part of our document in any way
TimCole_: the only concern I have is that there may be multiple
I18N extensions
ivan: that's a common problem with extensions--it's just how it
is...
shepazu: sorry, I was taking myself off the queue, I was
agreeing with ivan
... we at least avoid name space collisions by using JSON-LD
azaroth: I'm putting in a proposal that we'll remain silent on
it
<azaroth> PROPOSAL: Remain silent about i18n of extension
properties, as it is covered by JSON-LD already
<ivan> +1
<azaroth> +1
+1
<davis_salisbury> +1
<takeshi> +1
<PaoloCiccarese> +1
<bjdmeest> +1
<tbdinesh> +1
<shepazu> (it's not "covered by JSON-LD already", it's simply
not addressed)
<shepazu> (it's lumped in with any other extensions)
RESOLUTION: Remain silent about i18n of extension properties,
as it is covered by JSON-LD already
Document annotation service endpoint rel
[24]https://github.com/w3c/web-annotation/issues/174
[24] https://github.com/w3c/web-annotation/issues/174
ivan: you still have editorial work to do for extensions, yeah?
azaroth: definitely
ivan: I'll leave the issue open then
azaroth: 174 is a protocol need
... a relationship to go into the link headers for HTTP
response to point to a service where you can send annotations
to
... in order to have a readable relation--called a "rel
type"--we need to register it with IANA
... in order to do that, we have to have a URI
... currently, it's in the name space of the vocabulary
... are there any objections to putting the concept of the
service into the vocabulary which otherwise serves the model
... to avoid creating a namespace just for this piece
shepazu: I don't have objections to it
... I was reading a document that was using the `oa` namespace
... our spec is different than Open Annotation
... there are people using it for the last year or two
... since we changed that, shouldn't we change the namespace?
azaroth: this was handled in issue #53
<azaroth> github:
[25]https://github.com/w3c/web-annotation/issues/53
[25] https://github.com/w3c/web-annotation/issues/53
shepazu: when was that resolved
ivan: can we close the current 174
shepazu: I've no objection to the current issue
<azaroth> PROPOSAL: Use the ontology namespace for the prefix
of the annotation service "rel" for link header references
<ivan> +1
<azaroth> +1
+1
<davis_salisbury> +1
<takeshi> +1
<TimCole_> +1
<fjh> +1
<bjdmeest> +1
<Tbdinesh_> +1
RESOLUTION: Use the ontology namespace for the prefix of the
annotation service "rel" for link header references
IRI vs URI - [26]https://github.com/w3c/web-annotation/issues/183
[26] https://github.com/w3c/web-annotation/issues/183
azaroth: there's a motion with the WhatWG to use URL even
"over" URI or IRI
... takeshi is correct that the identifiers in JSON-LD and
Turtle are expressed as IRI
... should we then follow those specs?
... or should we use URI or URL (following WhatWG)
... the reasoning is that developers may not know when to use %
encoded content
... using IRI makes that clear
takeshi: my understanding is that in the serialization process,
we definitely need to transform the model into the
serialization format
... since both the JSON-LD and Turtle use IRI
... that resource identifiers in the model would become an IRI
regardless
<shepazu> (note that it's not just naming, it's parsing and
processing, which is a non-trivial distinction for interop)
<shepazu> (changing away from HTML5 URL would be going against
the future trend)
takeshi: it would be very helpful to make it clear
ivan: since a URI is a subset of an IRI, then it's perhaps OK
to leave it at URI
... my point is more practical
... what do you do if you have serialized selectors?
... will your implementation handle that correctly?
... will it fail because it is turning a IRI into a URI?
... with all the dashes, etc.
... that should be one of the directing issues
<shepazu> (I think I agree with Ivan)
takeshi: so. when I put JSON-LD into a data store, some are
transformed
<azaroth> +1 to takeshi
takeshi: it becomes very difficult to mix and match
ivan: your implementation accepts IRIs
... what is the practice out there--say at hypothes.is?
... that's what I don't know
shepazu: does the HTML5 spec address this? or punt?
... it would be a shame to switch to something that's on it's
way out
<azaroth> [27]https://url.spec.whatwg.org/
[27] https://url.spec.whatwg.org/
shepazu: if it's not addressed in that spec, then I think we
should avoid it
... they reference 3987 which is IRIs
<tilgovi> From that spec
shepazu: but they don't say anything about it
<tilgovi> "Standardize on the term URL. URI and IRI are just
confusing."
azaroth: this is the important bit
[28]https://url.spec.whatwg.org/#idna
... which defines the encoding for this "new" URL term
[28] https://url.spec.whatwg.org/#idna
<shepazu> [29]http://www.unicode.org/reports/tr46/#ToASCII
[29] http://www.unicode.org/reports/tr46/#ToASCII
azaroth: so we are past time
shepazu: can we come back to this next week?
azaroth: please way in on the issue in the meantime
<ivan> trackbot, end telcon
Summary of Action Items
Summary of Resolutions
1. [30]Minutes of the previous call are approved:
https://www.w3.org/2016/02/26-annotation-minutes.html
2. [31]In vocab, split SpecificResource into Annotation / non
Annotation specific classes, Selectors and States as
associated with the non Annotation specific class; describe
the usage in a Note
3. [32]Add extension section to vocab not model, proposing the
use of multiple json-ld contexts
4. [33]Remain silent about i18n of extension properties, as it
is covered by JSON-LD already
5. [34]Use the ontology namespace for the prefix of the
annotation service "rel" for link header references
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [35]scribe.perl version
1.144 ([36]CVS log)
$Date: 2016/03/04 17:10:54 $
[35] http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm
[36] http://dev.w3.org/cvsweb/2002/scribe/
Received on Friday, 4 March 2016 17:13:50 UTC