Web Annotation Working Group Teleconference

04 Mar 2016


See also: IRC log


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
Nick Stenning


<scribe> Agenda: announcement, chairs discussion, and a handful of issues 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: https://www.w3.org/2016/02/26-annotation-minutes.html

azaroth: any problems with the minutes?

RESOLUTION: Minutes of the previous call are approved: 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


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


azaroth: The first issue, is issue 110

<azaroth> Proposal is: 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


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> https://github.com/w3c/web-annotation/issues/110#issuecomment-188963956

ivan: this is the comment for the specific proposal https://github.com/w3c/web-annotation/issues/110#issuecomment-188963956
... let's go along with that, and coming up with a NOTE is typically not disturbing to the working group

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


<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 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)


<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: 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: 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


<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 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: 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


<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 - 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> 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 https://url.spec.whatwg.org/#idna
... which defines the encoding for this "new" URL term

<shepazu> 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. Minutes of the previous call are approved: https://www.w3.org/2016/02/26-annotation-minutes.html
  2. 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. Add extension section to vocab not model, proposing the use of multiple json-ld contexts
  4. Remain silent about i18n of extension properties, as it is covered by JSON-LD already
  5. 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 scribe.perl version 1.144 (CVS log)
$Date: 2016/03/04 17:10:54 $