W3C


Web Annotation Working Group Teleconference

10 Jun 2015

Agenda

See also: IRC log

Attendees

Present
Frederick Hirsch (fjh), Ray Denenberg (RayD), Doug Schepers (schepazu), Ben De Meester (bjdmeest), Benjamin Young (bigbluehat), Tim Cole (TimCole), Janina Sarol (Janina_), Ivan Herman (ivan), Jacob Jett (Jacob), Matt Haas (MattHaas), Paolo Ciccarese (PaoloC), Davis Salisbury (davis_salisbury), Takeshi Kanai (Takeshi), TB Dinesh (tbdinesh)
Regrets
Rob Sanderson
Chair
Frederick Hirsch
Scribe
TimCole

Contents


<trackbot> Date: 10 June 2015

Agenda Review, Scribe Selection, Announcements

Janina and Jacob are in the room with Tim

<fjh_> ScribeNick: TimCole

<fjh_> TPAC F2F update - scheduled for two days now, Mon/Tue , http://www.w3.org/2015/11/TPAC/

<fjh_> TR/Style sheet update response - https://lists.w3.org/Archives/Public/public-annotation/2015May/0060.html

<fjh_> Dataset Usage Vocabulary request for review and guidance, see https://lists.w3.org/Archives/Public/public-annotation/2015May/0058.html

F2F at TPAC

fjh: now 2 days
... Oct 26 & 27

TR/Style update survey

fjh: need help with regard turtle / json-ld and other questions on survey
... deadline is today
... has anybody have concerns with regards to the stylesheets for our specs?

shapazu: concerns -- we are using a way of switching between json and turtle

<fjh_> views switching - toggle between tabs

shapazu: we will need to keep this ability to switch between views
... the wide format of specs can harm readability
... there are ways of making narrower specs

fjh: clarification, Doug is saying margins / white space should be wider and text narrower

<bigbluehat> shepazu: Social WG has a tabbed UI in their Activity Streams 2.0 draft: http://jasnell.github.io/w3c-socialwg-activitystreams/activitystreams2.html#fig-expresses-the-statement-urn-example-person-martin-created-http-example.org-foo.jpg-.-no-additional-detail-is-given.x

<fjh_> text needs to be less wide for readability

<fjh_> wider gutter on side bar

shepazu: would help with annotation display

fjh: do we have any links we can give them?

shepazu: I think you can give them published data model and also rangefinder and protocol drafts

fjh: will finish this today

DataSet usage vocabulary

<fjh_> Dataset Usage Vocabulary request for review and guidance, see https://lists.w3.org/Archives/Public/public-annotation/2015May/0058.html

fjh: I think this ties into motivations
... do we need to add motivations important to us.
... please look offline and provide comments and feedback

Journalism annotation conference

<fjh_> workshop report from Doug, https://lists.w3.org/Archives/Public/public-annotation/2015May/0061.html and the AnnotatIST meeting http://janastu.org/technoscience/index.php/Annotatist

<shepazu> https://readfold.com/read/alexishope/journalism-annotation-3-GkLGdCJ2

<shepazu> https://hypothes.is/blog/poynter-annotation-summit-at-the-new-york-times/

shepazu: ReadFold summary is quite good and goes into detail
... includes plenty of links
... how can journalism use annotation? what should journalists be doing with annotation?
... Genius is partnering with a number of journalists, somewhat like what hypothes.is is doing
... LiveFire is another group supporting this kind of annotation
... 2nd note: Choral Project formed from Mozilla OpenNews
... Washington Post and NY Times are trying to improve user comments and may get involved.
... interesting initiative
... 3rd note: much of the conversation focused on comments on journalism and annotation as comments
... less about copy/edit kind of use cases.
... there is an expectation that people are more involved in journalism
... not an annotation use case per se, but does suggest what we should keep in mind.
... 4th note: a good mix of journalists, bloggers, academics, a lot of positive energy
... may not grow the WG, but is an audience that will be interested in what we are doing.

RayD: we have a motivation 'commenting'
... if you have an article with 400 comments below, are these annotations with motivation 'commenting'

shapazu: yes, that seems a possibility, and we should try to facilitate
... we didn't go into motivation a great deal during the meeting, not a lot on the technical details, more on functional requirements
... this may also be relevant to the discussion of adding an HTML note element
... this would likely be a useful thing to this community
... have talked to Web designers who would like to see this, i.e., comment as separate from the article itself.

Minutes Approval

fjh: need to revisit, but should move on for now.l

<fjh_> proposed RESOLUTION: Teleconference minutes from 13 May 2015 approved, see http://www.w3.org/2015/05/13-annotation-minutes.html

RESOLUTION: Teleconference minutes from 13 May 2015 approved, see http://www.w3.org/2015/05/13-annotation-minutes.html

<fjh_> proposed RESOLUTION: Minutes from 3 June approved, http://www.w3.org/2015/06/03-annotation-minutes.html

RESOLUTION: Minutes from 3 June approved, http://www.w3.org/2015/06/03-annotation-minutes.html

Protocol

fjh: Turtle discussion, Patch, etc.
... Benjamin's points about Turtle resonate
... if we have a good reason to specify JSON-LD is the default rather than Turtle, should be okay

<fjh_> turtle required? https://lists.w3.org/Archives/Public/public-annotation/2015Jun/0017.html

<bigbluehat> "4.3.2.2 LDP servers SHOULD respond with a text/turtle representation of the requested LDP-RS whenever the Accept request header is absent [turtle]."

<bigbluehat> http://www.w3.org/TR/ldp/

bigbluehat: Here is the line from LDP spec that says SHOULD rather than MUST
... this should lessen the amount of work and new things that adopters have to now to make an annotation server

<fjh_> proposal? if Accept is absent MUST JSON_LD for Annotation Protocol

bigbluehat: 4.3.2.2 should allow us to get away with this.

shepazu: We should avoid optional features, but can say what Benjamin suggests.

<shepazu> 4.3.2.3 LDP servers MUST respond with a application/ld+json representation of the requested LDP-RS when the request includes an Accept header, unless content negotiation or Turtle support requires a different outcome [JSON-LD].

<ivan> +1 to shepazu and bigbluehat

shepazu: so I agree that for annotation protocol, if absent we should respond with json-ld

RayD: if nothing is requested by the Client, than why should we specify what the server returns

bigbluehat: the Client does have to know how to send an accept header
... if I implement a server that sends back json-ld by default, will that mess up an LDP client that doesn't send accept header but expects Turtle

RayD: is the reason to relieve the necessity of client sending an accept header?

bigbluehat: more about when server is implemented are developers going to think they have to implement Turtle
... if you looking at annotation protocol and using LDP spec to fill in the gaps, the tendency will be to think you have to do Turtle

<fjh_> proposed RESOLUTION: Annotation Protocol spec will override LDP 4.3.2.2 LDP servers SHOULD respond with a text/turtle representation of the requested LDP-RS whenever the Accept request header is absent with "MUST respond with JSON-LD"

bigbluehat: so by being explicit we avoid that mis conception.

fjh: our goal is for Turtle not to be the default developers think they have to meet, not to exclude Turtle altogether (e.g., with accept headers)

<bigbluehat> +1

<Jacob> +1

<shepazu> +1

<Jacob> Yes

<bjdmeest> +1

<ivan> +1

<bigbluehat> found it....

<bigbluehat> "HTTP servers in general are not required to resolve ties in this way, or to support Turtle at all, but LDP servers are."

fjh: we will make a resolution now, and wait to see if there is new information that comes forward.

bigbluehat: there is some language that may imply LDP servers have to support Turtle, 4.3.??

ivan: we have had a discussion about whether it is a big deal -- it is for clients and for dedicated annotation servers

<tbdinesh> bigbluehat: i just joined the LDP group :)!

<bigbluehat> fjh_: well...this one may be normative: http://www.w3.org/TR/ldp/#h5_ldpc-post-turtle

ivan: so I think we should try what Doug, fjh, and Benjamin have suggested

<bigbluehat> "5.2.3.5 LDP servers that allow creation of LDP-RSs via POST MUST allow clients to create new members by enclosing a request entity body with a Content-Type request header whose value is text/turtle [turtle]. "

ivan: historically when LDP began work json-LD did not yet exist.

bigbluehat: if we agree that we can do this, we should and not depend as much on the LDP spec as a fallback
... LDP spec examples are all Turtle
... if we rely more on json-ld that would be good for annotation developers who don't need to rely as much on LDP Spec

shepazu: I think this should be okay. I do wonder what happens if a Client requests Turtle

<bigbluehat> ...good point...

shepazu: it may not be an option to leave ambiguous
... how big a deal is it to convert JSON-LD to Turtle

<fjh_> yes, good point. the decision is about what to do when client does not specify ACCEPT header

<bigbluehat> http://www.w3.org/TR/ldp/#h5_ldprs-get-turtle - "MUST respond with a Turtle rep...[when asked]"

ivan: there are some libraries, but especially for javaScript it is not as easy as you might think

<fjh_> so the proposed resoution is for smaller question

bigbluehat: json-ld into Turtle you typically get the same thing, but going the other way what you get is less predictable
... the shape of your json if you ingest Turtle may vary in ways that are problematic

<bigbluehat> Turtle to JSON-LD is "easy" (given tooling)

<bigbluehat> but converting Turtle to a specific JSON-LD "shape" is not as trivial

fjh: we should address the issue of what to do if no accept header in request that our protocol says return json-ld.

RESOLUTION: Annotation Protocol spec will override LDP 4.3.2.2 LDP servers SHOULD respond with a text/turtle representation of the requested LDP-RS whenever the Accept request header is absent with "MUST respond with JSON-LD"

<PaoloCiccarese> Framing is still a big unsolved issue for those that use graphs databases

<fjh_> ACTION: fjh to follow up on JSON-LD resolution [recorded in http://www.w3.org/2015/06/10-annotation-minutes.html#action01]

fjh: I will send a message to annotation list, and then we should follow-up with LDP WG (Doug suggests cross-posting okay in this time).

<trackbot> Created ACTION-20 - Follow up on json-ld resolution [on Frederick Hirsch - due 2015-06-17].

<tbdinesh> bigbluehat: then json-ld needs a normal form or else we can never assume json-ld will be useful in the intended way

<bigbluehat> tbdinesh: correct.

Patch formats

<fjh_> patch formats https://lists.w3.org/Archives/Public/public-annotation/2015Jun/0012.html

ivan: summary - what happens is that LDP Patch allows you to change a graph (rather than remove and replace)
... LDP Patch is not yet a standard
... this means that there is a document, is essentially using a Turtle-inspired syntax, close to SPARQL
... if we define a Patch for annotation, which format do we want to specify?
... related to previous issue, if we live in a json world, then specifying LDP Patch would require learning a different syntax for patching
... there is a json Patch document out there, but don't know much about it

<bigbluehat> JSON Patch spec http://tools.ietf.org/html/rfc6902

bigbluehat: core issue is that LDP Patch is about updating graphs, json Patch is about updating documents
... we could decide to avoid patch, given that annotations are not huge
... but Patch could be useful

Paolo: clarification - Patch is only about updating annotations (not containers), is this correct?

<fjh_> ivan: yes

Paolo: for us we sometimes use a patch when changing an annotation set, but never really have to use for an individual annotation

ivan: removing one annotation and replacing does not seem a big deal

<fjh_> question for group - is patch needed

paolo: agree this seems to be the case

ivan: this was raised early on in protocol discussion

paolo: we may also have thought we needed patch for annotation sets, but not an issue given LDP Container
... it depends on what we mean by big annotations - lots of triples or very large text bodies or multi-lingual... but even these don't seem to require Patch

bigbluehat: agree, we don't really need patch
... even for very large annotations, you have options to break up into multiple resources, but typically you need the entire annotation any

<fjh_> proposed RESOLUTION: Annotation WG defer Patch to later release, not needed for v1

bigbluehat: for most of our use cases it seems like a premature optimization

paolo: a use case with lots of triples is a named graph as body; body might get large

<bigbluehat> +1 to the resolution

<ivan> +1

<Jacob> +1

<bigbluehat> later...if ever...

paolo: but if I want to change the triples of the body I probably need to switch out the entire body anyway, so not much value in Patch

<PaoloCiccarese> +1

RESOLUTION: Annotation WG defer Patch to later release, not needed for v1

Use Cases - Education

<fjh_> Educational use case - https://lists.w3.org/Archives/Public/public-annotation/2015Jun/0004.html

fjh: use case is essentially that an instructor has 2 classes, and intermingling of annotations becomes a possibility

<Jacob> Please speak up. You're mostly inaudible

matt_hass: idea is that instructors sees conversations from both classes, but class members only see the discussion in their class
... so the issue is managing annotations by groups and dealing with individuals (the instructor) in both groups

fjh: core question about whether this is in scope for WG right now
... there are other WGs working on security and permissions; we should work with outputs of these WGs

shepazu: it is not explicitly in scope.
... reasonable to have this conversation here
... there will be lots of levels of access, granularity, permissions

<fjh_> not arguing we should not discuss - asking that we consider the degree of work we take on

shepazu: but this is probably not going to result in normative text in our specs yet
... nothing in our current data model would prevent you from doing what you need to do
... might bear on our protocol document, however.

<fjh_> +1 to Doug

shepazu: making certain annotations public, private, group-based, we should not forbid this in our specs
... the question is whether our WG will standardize how this is done

paolo: we talked about this a bit at last F2F
... thought was to look at Annotator.js model and some of the extensions that have been created.
... would like to see if protocol can say something about this.

fjh: will take to Rob and email.
... adjourn

<fjh_> Topic Adjourn

<ivan> tracker, end telcon

<ivan> trackbot, end telcon

Summary of Action Items

[NEW] ACTION: fjh to follow up on JSON-LD resolution [recorded in http://www.w3.org/2015/06/10-annotation-minutes.html#action01]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015/06/11 04:27:18 $