See also: IRC log
<trackbot> Date: 10 June 2015
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
fjh: now 2 days
... Oct 26 & 27
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
<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
<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.
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
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.
<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
<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