IRC log of annotation on 2016-03-04

Timestamps are in UTC.

15:44:24 [RRSAgent]
RRSAgent has joined #annotation
15:44:24 [RRSAgent]
logging to
15:44:26 [trackbot]
RRSAgent, make logs public
15:44:28 [trackbot]
Zakim, this will be 2666
15:44:28 [Zakim]
I do not see a conference matching that name scheduled within the next hour, trackbot
15:44:29 [trackbot]
Meeting: Web Annotation Working Group Teleconference
15:44:29 [trackbot]
Date: 04 March 2016
15:44:51 [ivan]
15:45:02 [ivan]
ivan has changed the topic to: Agenda:
15:45:14 [ivan]
Chair: Rob
15:46:32 [azaroth]
azaroth has changed the topic to: Agenda:
15:46:47 [azaroth]
Present+ Rob_Sanderson
15:58:04 [TimCole_]
TimCole_ has joined #annotation
15:58:31 [fjh]
fjh has joined #annotation
15:59:21 [dwhly]
+Present Dan_Whaley
16:00:07 [fjh]
Present+ Frederick_Hirsch
16:00:58 [bjdmeest]
bjdmeest has joined #annotation
16:01:20 [dwhly]
Present+ Dan_Whaley
16:01:21 [bjdmeest]
Present+ Ben_De_Meester
16:02:05 [azaroth]
Regrets+ Nick_Stenning
16:02:07 [TimCole_]
Present+ Tim_Cole
16:02:36 [tilgovi]
tilgovi has joined #annotation
16:04:03 [azaroth]
scribenick: bigbluehat
16:04:07 [tilgovi]
Present+ Randall_Leeds
16:04:09 [azaroth]
scribe: Benjamin_Young
16:04:16 [bigbluehat]
Present+ Benjamin_Young
16:04:18 [ivan]
Present+ Ivan
16:04:31 [takeshi]
takeshi has joined #annotation
16:04:51 [PaoloCiccarese]
PaoloCiccarese has joined #annotation
16:05:04 [tbdinesh]
tbdinesh has joined #Annotation
16:05:27 [bigbluehat]
Agenda: announcement, chairs discussion, and a handful of issues
16:06:00 [bigbluehat]
azaroth: are there any other issues important to discuss not represented on the agenda?
16:06:12 [bigbluehat]
...k. we'll run with what we have
16:06:17 [bigbluehat]
16:06:23 [dwhly]
16:06:26 [bigbluehat]
...other than the chairing conversation are there others?
16:06:48 [bigbluehat]
ivan: at this moment there are 10 people registered with a 'wish to come' to the face to face
16:07:03 [bigbluehat]
...if there are others who want to come, please register
16:07:14 [bigbluehat]
...last week I sent a list of hotels
16:07:21 [bigbluehat]
...they're also linked from the site
16:07:23 [takeshi]
Present+ Takeshi_Kanai
16:08:01 [bigbluehat]
...make reservations soon to avoid extra expenses
16:08:09 [azaroth]
ack dwhly
16:08:36 [bigbluehat]
dwhly: we have put a program committee together for I Annotate 2016
16:08:40 [bigbluehat] can see it on the site
16:08:50 [bigbluehat]
...please send in submissions for talks if you'd like to give one
16:08:57 [bigbluehat]
...sometime in the next week would be great
16:09:01 [azaroth]
16:09:21 [bigbluehat]
...Rob, it'd be great if you might make a presentation on the face-to-face output
16:09:32 [shepazu]
present+ shepazu
16:09:37 [bigbluehat]
azaroth: any other announcements?
16:09:58 [bigbluehat]
azaroth: approving minutes from last time
16:10:04 [azaroth]
PROPOSED RESOLUTION: Minutes of the previous call are approved:
16:10:10 [tbdinesh]
Present+ tb_dinesh
16:10:20 [bigbluehat]
...any problems with the minutes?
16:10:31 [davis_salisbury]
davis_salisbury has joined #annotation
16:10:35 [bigbluehat]
RESOLUTION: Minutes of the previous call are approved:
16:10:37 [azaroth]
TOPIC: WG Chairing
16:10:46 [davis_salisbury]
Present+ davis_salisbury
16:10:51 [bigbluehat]
azaroth: announcement and discussion about working group chairing
16:11:31 [bigbluehat]
ivan: things are busy for fjh and consequently it's hard to do both chairing and keep up with other responsibilities
16:11:36 [bigbluehat]
...he will still be active in the group
16:11:39 [bigbluehat]
...but not as a co-chair
16:11:49 [shepazu]
+1 to fjh
16:11:50 [bigbluehat]
...first of all, we should all thank fjh for his help from the beginning
16:11:59 [azaroth]
Thank you Frederick!
16:12:07 [davis_salisbury]
Thank you!
16:12:16 [bigbluehat] a replacement for fjh, TimCole_ has accepted the co-chair position
16:12:22 [tbdinesh]
Thank you!
16:12:27 [bigbluehat]
fjh++ :)
16:12:44 [bigbluehat] has not been more widely announced, as we wanted to tell the WG call first
16:12:52 [bigbluehat]
...announcement will go out later this week or Monday
16:12:56 [fjh]
Thanks all, congratulations to Tim. I think the group has good chairing going forward!
16:13:13 [bigbluehat]
fjh: just wanted to say congrats Tim and thanks everyone!
16:14:00 [bigbluehat]
TimCole_: the transition should be smooth. I've been here since the beginning, and I'm happy to serve in this capacity
16:14:20 [bigbluehat]
fjh: tnx to ivan shepazu and azaroth and TimCole_ for working through the transition
16:14:31 [bigbluehat]
azaroth: my heart felt thanks to you fjh for your dedication and hard work!
16:14:33 [fjh]
16:14:33 [bigbluehat]'s super appreciated
16:15:02 [azaroth]
TOPIC: Issues
16:15:19 [bigbluehat]
azaroth: as a note, these issues are the last ones that we have!
16:15:33 [bigbluehat]
...if we can get through these plus the new one from takeshi, our queue will be clear
16:15:44 [bigbluehat]
...we'll have to discuss testing, the html serialization, etc.
16:15:57 [bigbluehat]
...but focusing on the 3 core specifications, this is pretty much it
16:16:20 [bigbluehat]
...while it's been particularly product to force march through issues, we can reconsider that approach
16:16:47 [bigbluehat]
...and with TimCole_ as co-chair, it probably makes sense for Tim to take a more active role in the chairing
16:16:56 [bigbluehat]
...and I would focus more on editorial
16:17:02 [azaroth]
16:17:08 [bigbluehat]
...The first issue, is issue 110
16:17:38 [azaroth]
Proposal is:
16:17:43 [bigbluehat]
ivan: I started this issue....I don't even remember when...based on the recognition
16:17:50 [bigbluehat]
...that whatever we do here
16:18:14 [bigbluehat] identify part of a document could be combined with other specifications
16:18:23 [bigbluehat]
...and would have huge value beyond just annotation
16:18:38 [bigbluehat]
...if you want to see the use cases, feel free to read through the long discussion
16:18:50 [tilgovi_]
tilgovi_ has joined #annotation
16:18:57 [bigbluehat]
...this did come in a little bit late, so there's lots of discussion about how to make it happen
16:18:59 [shepazu]
16:19:03 [bigbluehat]
...what we're proposing now is...
16:19:12 [bigbluehat] terms of the standard, there are very very few changes
16:19:18 [bigbluehat]
...on the vocab level, very few changes
16:19:34 [bigbluehat]
...on the vocab level it's mostly resorting how the classes and sub-classes are done
16:19:39 [bigbluehat] they can be more widely used
16:19:59 [bigbluehat]'s one of the last comments on the issues list
16:20:12 [bigbluehat]
16:20:24 [bigbluehat]
...there's essentially just some editorial work to be done
16:20:54 [bigbluehat]
...essentially a cut and paste from the model document
16:21:05 [bigbluehat]
...but put it in a less-annotation-bound space
16:21:20 [bigbluehat] others could use them without digging through a recommendation that may not be in their core interest
16:21:47 [bigbluehat]
...There was a side issue that came up during the discuss
16:21:51 [bigbluehat]
16:22:06 [bigbluehat]
...whether it was good to map the selectors into a fragment identifier
16:22:10 [bigbluehat]
...technically, this is not hard
16:22:25 [bigbluehat]
...socially, it's very unclear
16:22:42 [bigbluehat]
...for instance registering a fragment identifier for HTML is not technically possible
16:22:49 [bigbluehat]
...we would leave that work to future WGs
16:22:52 [azaroth]
+1 to putting it in the note
16:23:05 [bigbluehat]
...that sums it up. sound right?
16:23:09 [bigbluehat]
azaroth: yes.
16:23:17 [ivan]
16:23:24 [bigbluehat]'s basically a best practices document about how to use our work outside of annotation
16:23:33 [azaroth]
ack shepazu
16:23:34 [bigbluehat]
...the changes come in at the vocab level rather than the model
16:23:49 [bigbluehat]
shepazu: while I agree that this could theoretically be useful outside of annotation
16:23:58 [bigbluehat]
...unless there's really compelling need outside of the group
16:24:02 [bigbluehat]
...we should do the minimum
16:24:13 [bigbluehat]
...I don't hear people clamoring to reuse this stuff
16:24:26 [bigbluehat]
...most people are not going to use more than CSS selectors for their stuff
16:24:51 [bigbluehat]
...without wider review, then I don't think it makes sense to spend much time on this
16:25:09 [TimCole_]
16:25:18 [bigbluehat]
...until we have more outside attention on it, I think we should do any substantial work on this...
16:25:31 [bigbluehat]
ivan: since the work is minimal, then I don't think we disagree
16:25:53 [bigbluehat] for the use cases, on the one hand, there was one big one
16:26:01 [bigbluehat]
...that certainly was a big use case (by Jacob, I think)
16:26:14 [bigbluehat]
...when I talked to epub and publishing groups, they would very much like something like this
16:26:20 [bigbluehat]
...the combination of all these is very powerful
16:26:24 [azaroth]
I suggest not going through the use cases, if Doug is willing to accept that they exist, across communities
16:26:32 [bigbluehat]
...the current way of selecting things within an eboook is pretty ugly
16:26:54 [bigbluehat]
shepazu: I just don't think this is a high priority issue
16:27:04 [bigbluehat]
ivan: than I propose we go along with what's been proposed--which is minimal
16:27:10 [ivan]
16:27:26 [bigbluehat]
...this is the comment for the specific proposal
16:27:38 [azaroth]
ack TimCole_
16:27:44 [bigbluehat]
...let's go along with that, and coming up with a NOTE is typically not disturbing to the working group
16:28:04 [bigbluehat]
TimCole_: I support the proposal, with the understanding that we should highlight that there's potential for future development here
16:28:20 [bigbluehat]
...the one class of use cases that are compelling involve multiple selectors
16:28:28 [bigbluehat]
...that's hard to do in any of the current mish-mash environments
16:28:45 [bigbluehat]
...applying a sequence or a variation of selectors is currently tricky
16:28:49 [bigbluehat]
...that's not for us to solve now
16:29:01 [bigbluehat]
...but noting that it would be good ground for the future seems prudent
16:29:01 [uskudarli]
uskudarli has joined #annotation
16:29:05 [shepazu]
(at this point, use cases are less important than specific requests and commitment from implementers to actually implement these outside of Web Annotations)
16:29:09 [azaroth]
16:29:22 [bigbluehat]
azaroth: any further thoughts?
16:30:18 [bigbluehat]
...since GitHub allows issues to be edited, I'll restate the resolution here
16:31:10 [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
16:31:15 [ivan]
16:31:17 [azaroth]
16:31:18 [bigbluehat]
16:31:19 [TimCole_]
16:31:24 [takeshi]
16:31:43 [davis_salisbury]
16:31:46 [tbdinesh]
16:31:47 [bjdmeest]
16:31:59 [shepazu]
16:32:20 [bigbluehat]
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
16:32:21 [ivan]
rrsagent, pointer?
16:32:21 [RRSAgent]
16:32:25 [azaroth]
16:32:41 [bigbluehat]
azaroth: the next issue is around extension
16:32:52 [bigbluehat]
...the bulk of the content has already been done
16:32:58 [bigbluehat]
...we allow for multiple @context's in the text
16:32:59 [shepazu]
*I don't think this should have been prioritized, since it doesn't change our implementations behavior)
16:34:02 [bigbluehat]
...we will liberally crib from the extension section from the ActivityStreams document
16:34:18 [bigbluehat] help folks looking to extend the model a place to find this content
16:34:26 [bigbluehat] general, how does that seem?
16:34:52 [TimCole_]
+1 to having extension section in vocab
16:34:53 [bigbluehat]
...The vocabulary section seems to be the right place to do it
16:35:00 [azaroth]
16:35:02 [bigbluehat] do we feel about those things?
16:35:14 [shepazu]
s/TOPIC:/TOPIC: Extension Capacity /
16:35:52 [bigbluehat]
...k. we can turn that into an editorial issue and review that once it's done
16:35:59 [bigbluehat]
...and...I seem to have confused two issues
16:36:13 [bigbluehat]
...there's also an issue of I18N of values in an annotation
16:36:19 [bigbluehat]
ivan: let's close this one firt
16:36:23 [bigbluehat]
16:36:30 [bigbluehat]
16:36:40 [azaroth]
PROPOSAL: Add extension section to vocab not model, proposing the use of multiple json-ld contexts
16:36:43 [ivan]
16:36:44 [shepazu]
(extensions are fine, but let's not pretend we haven't committed the spec to JSON-LD / RDF already)
16:36:46 [bigbluehat]
16:36:47 [PaoloCiccarese]
16:36:47 [azaroth]
16:36:52 [TimCole_]
16:36:54 [shepazu]
+ 0
16:36:55 [takeshi]
16:36:57 [davis_salisbury]
16:37:03 [tbdinesh]
16:37:13 [tilgovi]
16:37:22 [ivan]
rrsagent, pointer?
16:37:22 [RRSAgent]
16:37:46 [bigbluehat]
RESOLUTION: Add extension section to vocab not model, proposing the use of multiple json-ld contexts
16:38:04 [azaroth]
I18n issue:
16:38:40 [bigbluehat]
azaroth: currently, the model only has the text of the Body for humans to read--and we have I18N support here already
16:38:55 [bigbluehat] my thinking is that this is an extension problem--not a model problem
16:39:33 [bigbluehat] would be sufficient to say, this is an extension issue and we use JSON-LD for extension, so do it that way
16:39:37 [ivan]
16:39:42 [azaroth]
ack ivan
16:39:43 [bigbluehat]
...or we can recommend a patter, and give the rationale for that
16:40:12 [bigbluehat]
ivan: if we push it on the JSON-LD side, then implementations may miss it because they'll be focused on the model document
16:40:20 [bigbluehat]
...or we are completely silent on it
16:40:27 [bigbluehat]
...we don't have any 3rd choice, I think
16:40:30 [TimCole_]
16:40:33 [azaroth]
ack TimCole_
16:40:41 [bigbluehat]
...if we point people to JSON-LD the ground seems a bit shaky
16:40:53 [bigbluehat]
TimCole_: ivan how is this being address by other groups?
16:41:03 [bigbluehat]
ivan: we had that in the CSV metadata
16:41:13 [bigbluehat]
...which defines a JSON format which is JSON-LD compatible
16:41:20 [azaroth]
Activity Streams does the map version:
16:41:35 [bigbluehat]
...we essentially adopted one specific approach in the equivalent "model" type document
16:41:54 [bigbluehat]
TimCole_: the patterns that azaroth indicated, would we put that in vocab? and then model would talk about it?
16:42:10 [bigbluehat]
azaroth: no, the 'label' bit was from the example use case given
16:42:30 [bigbluehat]
ivan: oh. well that's....since we don't have a label, then we don't need this
16:42:34 [shepazu]
+1 to ivan
16:42:34 [bigbluehat]
azaroth: right. it's only for extension
16:42:47 [bigbluehat]
ivan: then it's irrelevant
16:43:06 [bigbluehat]
...we talk about extension, then specific implementations would do it that way
16:43:26 [bigbluehat]
...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
16:43:31 [bigbluehat]
...but not part of our document in any way
16:43:54 [shepazu]
16:43:55 [bigbluehat]
TimCole_: the only concern I have is that there may be multiple I18N extensions
16:44:06 [azaroth]
ack shepazu
16:44:07 [bigbluehat]
ivan: that's a common problem with extensions--it's just how it is...
16:44:24 [bigbluehat]
shepazu: sorry, I was taking myself off the queue, I was agreeing with ivan
16:44:41 [bigbluehat]
...we at least avoid name space collisions by using JSON-LD
16:44:53 [bigbluehat]
azaroth: I'm putting in a proposal that we'll remain silent on it
16:45:00 [azaroth]
PROPOSAL: Remain silent about i18n of extension properties, as it is covered by JSON-LD already
16:45:02 [ivan]
16:45:03 [azaroth]
16:45:06 [bigbluehat]
16:45:06 [davis_salisbury]
16:45:08 [takeshi]
16:45:09 [PaoloCiccarese]
16:45:14 [bjdmeest]
16:45:17 [tbdinesh]
16:45:36 [shepazu]
(it's not "covered by JSON-LD already", it's simply not addressed)
16:46:00 [shepazu]
(it's lumped in with any other extensions)
16:46:10 [ivan]
rrsagent, pointer?
16:46:10 [RRSAgent]
16:46:16 [bigbluehat]
RESOLUTION: Remain silent about i18n of extension properties, as it is covered by JSON-LD already
16:46:22 [azaroth]
16:46:44 [bigbluehat]
ivan: you still have editorial work to do for extensions, yeah?
16:46:47 [bigbluehat]
azaroth: definitely
16:46:56 [bigbluehat]
ivan: I'll leave the issue opent hen
16:47:01 [bigbluehat]
s/opent hen/open then
16:47:09 [bigbluehat]
azaroth: 174 is a protocol need
16:47:27 [bigbluehat]
...a relationship to go into the link headers for HTTP response to point to a service where you can send annotations to
16:47:46 [bigbluehat] order to have a readable relation--called a "rel type"--we need to register it with IANA
16:47:46 [shepazu]
s/TOPIC:/ TOPIC: Document annotation service endpoint rel /
16:47:52 [bigbluehat] order to do that, we have to have a URI
16:48:16 [bigbluehat]
...currently, it's in the name space of the vocabulary
16:48:53 [bigbluehat]
...are there any objections to putting the concept of the service into the vocabulary which otherwise serves the model
16:49:02 [bigbluehat] avoid creating a namespace just for this piece
16:49:04 [shepazu]
16:49:09 [azaroth]
ack shepazu
16:49:31 [bigbluehat]
shepazu: I don't have objections to it
16:49:40 [bigbluehat]
...I was reading a document that was using the `oa` namespace
16:49:55 [bigbluehat]
...our spec is different than Open Annotation
16:50:06 [bigbluehat]
...there are people using it for the last year or two
16:50:15 [bigbluehat]
...since we changed that, shouldn't we change the namespace?
16:50:24 [bigbluehat]
azaroth: this was handled in issue #53
16:50:28 [azaroth]
16:50:31 [bigbluehat]
shepazu: when was that resolved
16:50:54 [bigbluehat]
ivan: can we close the current 174
16:51:08 [bigbluehat]
shepazu: I've no objection to the current issue
16:51:29 [azaroth]
PROPOSAL: Use the ontology namespace for the prefix of the annotation service "rel" for link header references
16:51:37 [ivan]
16:51:39 [azaroth]
16:51:40 [bigbluehat]
16:51:45 [davis_salisbury]
16:51:58 [Tbdinesh_]
Tbdinesh_ has joined #Annotation
16:52:03 [takeshi]
16:52:36 [TimCole_]
16:52:41 [fjh]
16:52:41 [bjdmeest]
16:52:44 [Tbdinesh_]
16:52:48 [bigbluehat]
RESOLUTION: Use the ontology namespace for the prefix of the annotation service "rel" for link header references
16:52:49 [azaroth]
16:52:49 [ivan]
rrsagent, pointer?
16:52:49 [RRSAgent]
16:53:52 [bigbluehat]
azaroth: there's a motion with the WhatWG to use URL even "over" URI or IRI
16:54:08 [bigbluehat]
...takeshi is correct that the identifiers in JSON-LD and Turtle are expressed as IRI
16:54:17 [bigbluehat]
...should we then follow those specs?
16:54:31 [bigbluehat]
...or should we use URI or URL (following WhatWG)
16:54:52 [bigbluehat]
...the reasoning is that developers may not know when to use % encoded content
16:54:56 [bigbluehat]
...using IRI makes that clear
16:55:26 [bigbluehat]
takeshi: my understanding is that in the serialization process, we definitely need to transform the model into the serialization format
16:55:37 [bigbluehat]
...since both the JSON-LD and Turtle use IRI
16:55:39 [ivan]
16:55:51 [bigbluehat]
...that resource identifiers in the model would become an IRI regardless
16:55:52 [shepazu]
(note that it's not just naming, it's parsing and processing, which is a non-trivial distinction for interop)
16:56:15 [azaroth]
ack ivan
16:56:20 [shepazu]
(changing away from HTML5 URL would be going against the future trend)
16:56:22 [bigbluehat] would be very helpful to make it clear
16:57:03 [bigbluehat]
ivan: since a URI is a subset of an IRI, then it's perhaps OK to leave it at URI
16:57:10 [bigbluehat] point is more practical
16:57:36 [bigbluehat]
...what do you do if you have serialized selectors?
16:57:42 [bigbluehat]
...will your implementation handle that correctly?
16:58:00 [bigbluehat]
...will it fail because it is turning a IRI into a URI?
16:58:08 [bigbluehat]
...with all the dashes, etc.
16:58:14 [azaroth]
16:58:15 [takeshi]
16:58:18 [azaroth]
ack takeshi
16:58:19 [bigbluehat]
...that should be one of the directing issues
16:58:22 [shepazu]
(I think I agree with Ivan)
16:58:55 [bigbluehat]
takeshi: so. when I put JSON-LD into a data store, some are transformed
16:59:02 [azaroth]
+1 to takeshi
16:59:03 [bigbluehat] becomes very difficult to mix and match
16:59:16 [bigbluehat]
ivan: your implementation accepts IRIs
16:59:31 [bigbluehat]
...what is the practice out there--say at
16:59:34 [bigbluehat]
...that's what I don't know
16:59:45 [bigbluehat]
shepazu: does the HTML5 spec address this? or punt?
17:00:25 [bigbluehat] would be a shame to switch to something that's on it's way out
17:00:37 [azaroth]
17:00:39 [bigbluehat]
...if it's not addressed in that spec, then I think we should avoid it
17:00:48 [tilgovi]
17:01:13 [bigbluehat]
shepazu: they reference 3987 which is IRIs
17:01:14 [tilgovi]
From that spec
17:01:20 [bigbluehat]
...but they don't say anything about it
17:01:24 [tilgovi]
"Standardize on the term URL. URI and IRI are just confusing."
17:01:59 [bigbluehat]
azaroth: this is the important bit
17:02:08 [bigbluehat]
...which defines the encoding for this "new" URL term
17:02:09 [tilgovi]
17:02:31 [shepazu]
17:02:51 [bigbluehat]
azaroth: so we are past time
17:02:57 [bigbluehat]
shepazu: can we come back to this next week?
17:03:22 [bigbluehat]
azaroth: please way in on the issue in the meantime
17:04:30 [ivan]
rrsagent, draft minutes
17:04:30 [RRSAgent]
I have made the request to generate ivan
17:04:39 [ivan]
trackbot, end telcon
17:04:39 [trackbot]
Zakim, list attendees
17:04:39 [Zakim]
As of this point the attendees have been Ivan, Frederick_Hirsch, Rob_Sandersion, Rob_Sanderson, Tim_Cole, Benjamin_Young, Jacob_Jett, shepazu, davis_salisbury, Paolo_Ciccarese,
17:04:42 [Zakim]
... Ben_De_Meester, Chris_Birk, TB_Dinesh, Takeshi_Kanai, Randall_Leeds, Dan_Whaley, Susan, Uskudarli, !, Nick_Stenning, Suzan_Uskudarli, 0
17:04:47 [trackbot]
RRSAgent, please draft minutes
17:04:47 [RRSAgent]
I have made the request to generate trackbot
17:04:48 [trackbot]
RRSAgent, bye
17:04:48 [RRSAgent]
I see no action items