See also: IRC log
<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
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
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> 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
+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
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: 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
+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
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
+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
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