Meeting minutes: 2016-03-04

Minutes are here:

Text version below


Ivan Herman, W3C
Digital Publishing Lead
mobile: +31-641044153



              Web Annotation Working Group Teleconference

04 Mar 2016



   See also: [3]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




     * [4]Topics
         1. [5]WG Chairing
         2. [6]Issues
              1. [7]
              2. [8]Extension Capacity:
              3. [9]Document annotation service endpoint rel:
              4. [10]IRI vs URI: -
     * [11]Summary of Action Items
     * [12]Summary of Resolutions

   <scribe> Agenda: announcement, chairs discussion, and a handful
   of issues


   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 site
   ... make reservations soon to avoid extra expenses

   dwhly: we have put a program committee together for I Annotate
   ... you can see it on the site
   ... please send in submissions for talks if you'd like to give
   ... 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


   azaroth: any problems with the minutes?

   RESOLUTION: Minutes of the previous call are approved:


WG Chairing

   azaroth: announcement and discussion about working group

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


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

   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
   ... 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: this is the comment for the specific proposal
   ... 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
   ... 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


   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:


   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

   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:


   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

   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

   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

   <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


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


   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 - [26]


   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

   <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

   <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
   ... 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]


   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

   azaroth: this is the important bit
   ... which defines the encoding for this "new" URL term


   <shepazu> [29]


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


Received on Friday, 4 March 2016 17:13:50 UTC