See also: IRC log
<trackbot> Date: 17 June 2015
<fjh> Agenda: https://lists.w3.org/Archives/Public/public-annotation/2015Jun/0074.html
<fjh> ScribeNick: bjdmeest
<fjh> response to TR design survey, please review: https://lists.w3.org/Archives/Public/public-annotation/2015Jun/0045.html
<fjh> TPAC registration now open: https://lists.w3.org/Archives/Public/public-annotation/2015Jun/0041.html
<fjh> updated publications page: https://www.w3.org/annotation/wiki/PubStatus
fjh: [announcements about links in chat]
... any other announcements?
<fjh> proposed RESOLUTION: Minutes from 10 June approved, http://www.w3.org/2015/06/10-annotation-minutes.html
RESOLUTION: Minutes from 10 June approved, http://www.w3.org/2015/06/10-annotation-minutes.html
<fjh> http://w3c.github.io/web-annotation/protocol/wd/
azaroth: some good discussion about the protocol
... on the list
... issue about: mini-annotations, patch, terminology about client-server
... removed suggestion URI-pattern for annotation containers
... added annotations where additional constraints are added on top of LDP
... e.g., link to alternate containers/services
... notes in the spec are added
... are there particular issues, i.e., crystalization or crossover, to be discussed?
... JSON-LD provides profiles, none are usable for ANNO
... we could define our own profile
... fjh: profile attribute is already in the draft, is more work needed?
... it's noted in 4.2.2 that you can retrieve annotations with a profile
... further work: we need to actually create the profile doc
... endsection for considerations for IANA
... and register the profile
... but let's postpone the registering until there is consensus here
... appendix B says we should define the profile
<Zakim> fjh, you wanted to ask about publishing FPWD
fjh: can we publish a FPWD?
<bigbluehat> implementations needed prior to that? or after? or both? ;)
azaroth: the doc is in a good state
TimCole: worries about implementations
... 4.1.4 (containers and resources): what is covered here?
azaroth: 4.1.4 is a way to try to recommend a common practice for e.g. binary sources (images) or CSS style sheets needed by the annotation
... not too strict about the actual implementation
... it could be basic containers
... so we could drop 4.1.4 and let implementations deal with previously mentioned situations
... basically, 4.1.4 says that it has to be LDP-compliant (e.g. supporting the right verbs)
... it is an extra container, not a child of the annotation
bigbluehat: [about FPWD] do we need implementations before or after?
fjh: that's not a requirement
azaroth: (partial) implementations would be great to refer to
... Stanford has a similar but not conformant implementation
... basics are the same, but details aren't implemented yet, e.g. link headers in responses
... so the small details that don't make them fully interoperable
shepazu: [about implementations] 1: we have a page that lists implementation, not really structured
... we should have something like that to inform people
... [for testing those implementations] we have a test suite that has a test report [a grid]: which implementation passes which test
<azaroth> https://dvcs.w3.org/hg/ldpwg/raw-file/default/tests/reports/ldp.html
shepazu: it is not mandatory, but there are a couple of good ways to do it
TimCole: [regarding implementations] we are 2-3 weeks into having a partial implementation. we need the profile to get it right though
... [regarding a comment on the list about using the same URI as resource]: if you use the same resource identifier, do you have to do that, and how should the system handle that? Do they have to match? should they be stored multiple times?
azaroth: that could be implementation-dependent
... if you submit an annotation with a specific resource, the server does have to provide a uri for that resource, but it has to provide a uri for the annotation
... however, it would be good that the resource would have a uri to get the description of that resource
... [about TimCole's question about validation] that is not covered yet
... an annotation that doesn't conform to the profile should be rejected, but perhaps it is still LDP-compliant
PaoloCiccarese: using the same URI is troublesome
... validating new data compared to the old one is complicated
... we need URIs for specific resources, but it is complicated
shepazu: it is important to cover, but maybe we can defer that after the FPWD?
TimCole: I am a little concerned that errors are not covered in the current doc
azaroth: I can add a section about error-handling
<Zakim> fjh, you wanted to note FPWD CfC after 4.1.4 edits, FPWD goal
azaroth: about using the same URIs: that can be deferred
fjh: FPWD gets IP things taken care of, gives visibility, but it is still a draft
... so it is worth moving to a FPWD
... 4.1.4 needs fixing, authentication and authorization documentation is fine as they are?
azaroth: agree with 4.1.4 fixing, no auth*, and error-section
fjh: can we do a CfC on the list? (agreeing via the list) CfC would be appropriate for this, after the edits are done
<Jacob> +1 for CfC
azaroth: CfC would be great
<shepazu> +1
azaroth: by the end of week, the adjustments could be made
bigbluehat: [about crystalization] does that need attention?
<fjh> I think that we have resolved that issue on the list - see https://lists.w3.org/Archives/Public/public-annotation/2015Jun/0115.html
fjh: we will launch thus a 1-week CfC
... +1 in the mailing etc would be great
<fjh> proposed RESOLUTION: WG agrees that after Rob updates Protocol editors draft to clarify 4.1.4 and add material on errors, 1 week CfC to publish FPWD, then publish FPWD if no CfC issues
<fjh> proposed RESOLUTION: WG agrees that after Protocol editors draft updated to clarify 4.1.4 and add material on errors, 1 week CfC to publish FPWD, then publish FPWD if no CfC issues
RESOLUTION: WG agrees that after Protocol editors draft updated to clarify 4.1.4 and add material on errors, 1 week CfC to publish FPWD, then publish FPWD if no CfC issues
<azaroth> +1
fjh: i.e., based on motivation, updates to edit could be made very easy
shepazu: main issue: suggesting an edit as an annotation, and the author could click 'accept', and the software does the edit automatically
... thus, should motivation then be attached to the body, or to the entire annotation?
fjh: if we include multiple bodies (e.g., a suggested edit and a comment), how do we convey the role of each body?
... it is easy if there is only one body, it becomes complicated when there are multiple bodies
<Jacob> Aren't those really different annotations?
<Jacob> Feels like we are eating the cake and still trying to have it?
fjh: If you have multiple annotations instead of one annotation with two bodies, these annotations are no longer linked
<fjh> doug has example in email that shows how two bodies are related even though different motivations
fjh: e.g., a pull request with a comment (cfr. github)
<Zakim> shepazu, you wanted to ask if the motivation isn't sufficient for the role?
<Jacob> Unless you were annotating the annotation but I can see the efficiency argument
shepazu: I don't see why the motivation cannot indicate the role
<shepazu> https://lists.w3.org/Archives/Public/public-annotation/2015Jun/0107.html
<chrisbirk> Isn't the comment an annotation on the edit? You can suggest an edit without a motivating comment
<Jacob> Exactly chrisbirk
shepazu: [see mail conversation]: motivation is commenting in first body, and motivation is editing in second body
<fjh> "body": [
<fjh> {
<fjh> "@id": "http://example.org/body1"
shepazu: so editing motivation can be intercepted by software
<fjh> "motivation": "oa:commenting",
<fjh> "value" : "'Change' is a bit dry, why don't you punch it up a bit?",
<fjh> },
<fjh> {
<fjh> "@id": "http://example.org/body2"
<fjh> "motivation": "oa:editing",
<fjh> "value" : "transformation",
<fjh> }
azaroth: the reason why motivation cannot be in the body: motivation is about the annotation, not about the body, so the annotation motivation would be commenting and editing at the same time
shepazu: can't we say that the editing motivation restricts the useful value as being the value of the body? so only the body with motivation editing will be used by the client
azaroth: imagine using images: replace this image with that image
... because of the open world assumption, we need a divider between the body and the annotation, to see what the role of the image is
<davis_salisbury> +1 to more discussion
TimCole: [about problems of where to put the motivation] e.g. multiple bodies and targets: motivation applies to what?
... what about not just editing, but e.g. and XSL for an XML file?
RayD: when you have a edit and a comment within one annotation: how about submitting the comment as an annotation on an editing annotation?
<chrisbirk> That's what I was trying to say
<Jacob> RayD, this is exactly what was suggested when this issue was discussed in times past
<Zakim> fjh, you wanted to ask for a concise problem statement re motivations
<Jacob> No, anno b (commenting) annotates anno a (editing some target)
shepazu: there are a number of scenarios where we want to edit something etc... let's make the simple things simple
... difficult cases could e.g. have different motivations ('copy-edit'?)
<azaroth> +1 to extending motivation list; potentially in different namespaces
<fjh> let's take this to the list
shepazu: e.g. motivation is editing, and there is another chain of resolution: it is not what we are trying to solve here
... if such an annotation is not well-formed: the author could decline that edit
<TimCole> But do these simple use cases require motivations on the body? Isn't it simpler to keep the motivation on the annotation and comment on the proposed edit in separate annotations?
fjh: let's move this to the list
shepazu: [about testing ontologies] we should reach out to other WG with experience
... protocol should be testable, RangeFinder API as well
<azaroth> TimCole: I think (agree with fjh) we should see on the list how people feel about 1 vs multiple annos.
<chrisbirk> yep
shepazu: we should start making tests (once we have a FPWD)
... e.g. use LDP test as a base for our tests
<azaroth> Yup. The link I sent before to the LDP implementation report has the test suite
chrisbirk: Chris from Open OpenGov Foundation
<chrisbirk> OpenGov Foundation
chrisbirk: as invited expert
<azaroth> http://w3c.github.io/ldp-testsuite/
shepazu: next thing for spec is testing it
<azaroth> +1 to testing :)
shepazu: you find next problems that you otherwise cannot find