See also: IRC log
<trackbot> Date: 22 July 2015
<fjh> Agenda: https://lists.w3.org/Archives/Public/public-annotation/2015Jul/0168.html
<azaroth> Scribe: Benjamin_Young
<azaroth> scribenick: bigbluehat
<fjh> proposed RESOLUTION: Minutes from 15 July approved, https://lists.w3.org/Archives/Public/public-annotation/2015Jul/att-0156/minutes-2015-07-15.html
RESOLUTION: Minutes from 15 July approved, https://lists.w3.org/Archives/Public/public-annotation/2015Jul/att-0156/minutes-2015-07-15.html
<fjh> updated draft - https://lists.w3.org/Archives/Public/public-annotation/2015Jul/0162.html (Rob)
<fjh> comments - https://lists.w3.org/Archives/Public/public-annotation/2015Jul/0167.html (Frederick)
<fjh> proposed RESOLUTION: Publish updated WD of Web Annotation Protocol and share with TAG
<azaroth> http://w3c.github.io/web-annotation/protocol/wd/
azaroth: I made a bunch of changes to the protocol draft based on feedback
... notably I moved publishing out of management
... section 4 is now only about retrieving
... if you look for section 4 in page source, you'll see XML comments for where each requirement comes from
... all of them except 1 is from LDP
... the other is a combo of LDP + HTTP
... the Vary header requirement
... as far as I know we are not adding any additional requirements
... the deletion section starts off by saying "if you support this, this is how you have to do it."
<Zakim> fjh, you wanted to ask about renaming section to "Annotation Retrieval"
azaroth: POST, PUT, and DELETE are not required
fjh: purely editorial...it seems we can move everything up a level and remove the publishing and management sections
... making the whole thing less deep
azaroth: the reason I had the headers, is that section 4 you could use any old web server with JSON documents sitting somewhere
... section 5, you probably also want to support updating and deleting them
... the two blocks are reasonably important for guiding implementors
fjh: maybe section 4 should be renamed to annotation retrieval vs. publishing?
azaroth: I was thinking from a server perspective
... 4.1 is retrieve...so I'm happy to merge 4.1 into 4 until such time as we have a second sub-bullet
fjh: the rational makes sense to me
<Zakim> TimCole, you wanted to ask about 5.2.1
TimCole: small question...in section 5.2.1 the choice between MAY and SHOULD in the start of the second paragraph
... I understand why you don't want to have to assign URIs to all the blank nodes in the annotation
... in order to use the various parts of the annotation, don't you want a URI for the various parts?
... should servers be required to flesh out identifiers of the predicates?
azaroth: personally, I agree. I would like to hear what other people think, however.
... it seems like quite an implementation requirement
... in our Trianon work...that took quite a lot of work to create and reconstruct URIs for all the resources
TimCole: it's all about minting the URIs where they have to deal with targets and that kind of thing
... in paragraph 5.2.1
... the server MAY assign URIs for blank nodes within the annotation
... I'd like to see that changed to SHOULD
<Jacob> Can we just add an additional clause that says, "and SHOULD assign a URI to Specific Resources" (and possibly other typed nodes)?
<fjh> suggestion from TimCole is to change "the server MAY assign HTTP URIs to resources and blank nodes" to say SHOULD"
TimCole: alternatively it could be left as MAY, but use SHOULD for blank nodes and resources that are the subject or objects within the annotation
... and MUST assign one to the annotation
<Zakim> fjh, you wanted to ask about status of my email comments
fjh: in other words some blank nodes might not need one
TimCole: for instance if they're not necessary for reconstructing the annotation
azaroth: essentially following best practices...don't use blank nodes unless you can avoid it
fjh: wouldn't you want a SHOULD for assigning URIs?
azaroth: you have to walk the nodes and assign URIs...to get non-blank nodes
... a more concrete use case
... if I want to propose an edit, I need a way to target the body
... if it's a blank node or a literal, then there's no URI to refer to it by
... the propose to go from you MAY do it, to you SHOULD do it to handle use cases like this
TimCole: we used specific targets
<Jacob> How does this proposal affect the "textual body" use case? IIRC, having a blank node as the object of oa:hasBody was a central part of the solution for that use case.
azaroth: use cases exist for re-using selectors...it's always this particular region
<Zakim> fjh, you wanted to ask about status of my email comments
<fjh> additional comments to be incorporated in draft https://lists.w3.org/Archives/Public/public-annotation/2015Jul/0167.html
azaroth: I agree with all of your comments and will make them before we republish
<fjh> section 4.1 remove MUST NOT, proposal and rationale in email
shepazu: if it didn't have an identifier for the body, then I couldn't target it...isn't that what we're trying to fix with selectors?
... that we can point to things that don't have identifiers on the web?
azaroth: we could come up with some sort of selector (LD Path or some such), but that's not easy
... this issue was tackled in LDP
... in the LD Patch specification
... the requirement there was to change a property within a blank node in a graph
... the amount of contortions that you have to go through to identify it in order to change it
... is not trivial
... iirc sparql update has immense problems dealing with this
... you have to identify it by property values
... so if you have multiple bodies...you can't do it by order, because there is no order in a graph
... so it's much much simpler to give it a URI
shepazu: all of this is assuming a semweb infrastructure
... it seems a lot of people will want to use this stuff without the linked data stack requirement
... without sparql without these other things
... does this assume that you have to have all that?
azaroth: no, but what you're proposing would
shepazu: when you start talking about sparql and blank nodes....I thought this was more accessible...
... for folks that weren't buying in to the whole semweb thing
... I just need to understand how much of a semweb stack requirement we have here
PaoloCIccarese: if I understand, we're not saying you have to
azaroth: at the moment, we're saying MAY. proposal is to change to SHOULD
<fjh> SHOULD means you should have a good reason not to
PaoloCIccarese: my question is the following...
... I'm obviously using RDF and mint URIs for everything
... typically, they're HTTP ...blah blah blah...where my server is, etc.
... if I reuse identifiers from another system, I should expect those to be resolvable?
... are expecting the URIs we mint to be resolvable?
... let's assume I want to use the JSON with minting as few URIs as possible
... now I need to make them resolvable?
azaroth: SHOULD
PaoloCIccarese: let's say, I set out to make them resolvable
... now I have to link into another system that should stay up longer than I stay up
... is that something we want to recommend? minting URIs for all the parts of an annotation? and expecting them to be reused "forever"?
azaroth: the body of the annotation seems significant, so maybe that should be a SHOULD
... a style? a selector? a scope?
... perhaps even a specific resource?
<Zakim> fjh, you wanted to propose publishing updated WD after edits
azaroth: all of those seem more edge case to me
fjh: I have a suggestion. maybe we should get implementer feedback
... shepazu asked some questions, the over all concern being that it's deployable and adoptable without requiring understanding of semweb tech
... I'm not sure we can resolve it with discussion
... maybe we should publish this as a WD with a note near the SHOULD asking for implementer feedback
... is there a better way to get feedback?
azaroth: getting implementer feedback would be valuable
... about the actual cost of minting URIs
fjh: the SHOULD sounds like what we want...unless the cost is too high for implementers
... let's publish another WD and then go from there
... and then get more feedback and the TAG discussion could follow that as well
TimCole: if you think it makes sense, given PaoloCIccarese comments, it may the SHOULD only covers bodies and targets
... obviously, the servers need to be able to mint URIs
<fjh> proposed RESOLUTION: Publish updated WD of Web Annotation Protocol incorporating changes proposed by fjh in email and Tim Cole
TimCole: it can be a bit of work
<azaroth> +1
TimCole: but if we narrow it to bodies and targets perhaps its more acceptable
<Jacob> +1
<TimCole> +1
RESOLUTION: Publish updated WD of Web Annotation Protocol incorporating changes proposed by fjh in email and Tim Cole
fjh: I can help azaroth with the publication process if that would help
<fjh> motivatedBy/multiple Bodies
azaroth: the issue of multiple bodies, where the bodies have different roles
... quite some discussion on the list without any real consensus
... on the correct or appropriate result
... the concern was, for example, in the case where you have multiple bodies
... one body is a comment
... another body is an edit--a specific change to make to the document
... the comment is some explanation for the edit
... it's important for the client to know which body is which
... the use of motivation can't do that in its current form
... there was lots of discussion about how to implement it
... one proposal:
... to add relationships between the two
... or to have information directly about the bodies--"I am a replacement" or "I am a comment"
... or to have a motivation about a specific resource, so that the body resource can be used in different roles in different annotations
<Jacob> Why not have a separate annotations solution?
<Jacob> annotations about other annotations
azaroth: or not to have bodies at all, but to have only one body and use separate annotations
PaoloCIccarese: given the use cases,...I go back to firefox bookmarks....
... if you have a bookmark that says, this is the URL I am annotation, this is the description, and these are the tags
<fjh> why motivations cannot be on bodies https://lists.w3.org/Archives/Public/public-annotation/2015Jun/0152.html
PaoloCIccarese: now my original goal of "describe the resource" is not achieved any more
... the meaning is no longer conveyed
TimCole: so, I'm seeing this as a granularity issue
... sometime I want to talk about the group
... sometimes I want to talk about them individually
... having each one as a separate annotation, makes talking about them individually, easy
... however, I don't have a way in the protocol at least, for fetching them in one unit
<Jacob> this could be a use case for collections of annotations?
TimCole: from the standpoint of the client, the easiest thing would be to send one graph to the server that contains both my edit and my comment
<fjh> original model proposal https://lists.w3.org/Archives/Public/public-annotation/2015Jun/0112.html
TimCole: what would the server do with it?
... if I have resources that have direct containers that can contain annotations
... do I have a way to have the client retrieve a graph with multiple annotations?
... and at the same time allow one to retrieve individual annotations?
azaroth: yes....but you'd need to have one container for each of those sets of annotations
<fjh> TimCole proposal - allow containers to be used for publishing and retrieval sets of annotations (?)
azaroth: it'd be a lot of containers, essentially
<shepazu> trackbot, make minutes
<trackbot> Sorry, shepazu, I don't understand 'trackbot, make minutes'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.
azaroth: the client would need to create the container to then push the annotations to
TimCole: what if the graph contains more than one annotation...do we allow that?
... and if it is allowed...there are LDP examples that match this for assets and liabilities...
... there's still a resource that you can use to get both the assets and liabilities
... but you can also ask for those two things individually
... but I thought the LDP model made it pretty straightforward
... but maybe I'm wrong
shepazu: I think that the current characterization didn't capture what I felt was important in the issue
... how the two annotations relate feels like a detail to me
... the real issue is how do we have an annotation that has parts with different roles that a client might treat differently
... the other bits, like does this comment relate to this edit body
... honestly, i'm not really motivated...that doesn't really concern me
... that's not the bit I think is the important bit
azaroth: I apologies if I characterized this as about relating the two bodies
<Jacob> Not sure how this will ever be interoperable? Isn't it a really complex implementation to dig into an annotationa and then do something different with every body?
<azaroth> { @type : Annotation , hasComment: { chars : this is great now } , hasEdit { chars : patch } }
shepazu: to me an annotation is not just this thing that says...it's the frame, it's the target, and the body
azaroth: it really can't be all of those things
... say you're targeting a web page, and the web page is the annotation?
shepazu: no, I'm saying it's the bit that points to where the target is and that says what the body is
azaroth: yep, and the same body can be pointed to just like the target
<fjh> is this an optimization?
shepazu: so...this is where we differ...maybe it's something I don't understand
... to me, the JSON is the bit that talks about the target
... the URL to the youtube video may be in that body...
... let's say I have an image...
... let's say people are making comments on facebook
... people are making comments with a bunch of replies, etc
... somebody tosses in a meme
... and others might reuse that meme
... it's common to reuse a meme to say it's relevant to the current conversation
... someone else may do the same...but to me that's a different annotation
azaroth: the meme example is a great usecase
... the background comes from the semantic web decisions...the linked data...rdf model....
... which is, that anyone can make an assertion about any resource
... and that it's not limited by the scope of the document in which you're making that assertion
...example: "that annotation body over there is in French"
... or "that image is a jpeg"
... it's not only true within the annotation or graph...it's a global assertion
... if the role of the image in one annotation is a property of that image
... then it would have to always be true....and therefore is an invalid assertion because it's not global
shepazu: that claim doesn't make sense to me
... I could point to some image somewhere else
... or I could upload the file...include the image as the body within the annotation
... inline or by reference
... but if I make that assertion
... i'm not making that assertion about anything else but what i'm asserting
... it doesn't mean that someone else can't say something different about it
... maybe i'm suggestion someone else change their meme to use this one--making an edit
... I don't understand what this global assertion is
azaroth: it's the rdf model...the global open world model
shepazu: that doesn't answer the question for me
fjh: it's not part of the annotation model, right?
azaroth: by using rdf, we inherit all of those requirements
... if we said it wasn't an rdf-based model, we wouldn't have these requirements
RayD: one of the approaches got missed
... instead of multiple bodies submitted as annotations
... they are actually annotations of a base annotation
... it seems to me that would address the problem
azaroth: yep. we discussed multiple annotations individually
<fjh> it looks like we need to clarify the relationship of the high level user-view of annotation architecture with the implications of the underlying linked data model
azaroth: but we did miss the nested hierarchy option
PaoloCIccarese: this is not addressing what shepazu was saying...but something i'd though before
... adding new levels is going to be just confusing
... sometimes we'll have it...sometimes we won't
... ideally, adding relationships that are better qualified
... having someway to tag the bodies seems like the simplest to implement
... frankly having hierarchies....is going to be hard to implement
... detecting when things are or are not hierarchies and then dealing with the variations...
... all of these are possible, but i hope we can avoid implementation pain
shepazu: what's the hierarchy option
PaoloCIccarese: basically, you have one annotation, and it references several other annotations that clarify the parent
... firefox bookmark example
... one annotation that is the bookmark, another for the tags, the other for the description
... the tag and description annotations annotate the bookmark annotation
... if I'm an implementor, then I have to understand the chain of annotations
... and that it's trying to say more complicated things
... we'll have to distinguish them, and the code will have to distinguish them, etc.
... I like the idea of the relationships, etc.
... but now we have a proliferation of relationships
... and we'll need to understand those as well
<chrisbirk> does hasComment allow multiple comment bodies?
PaoloCIccarese: it could be a rabbit hole...but it still feels simpler
fjh: main thing is are we having a call next week?
... azaroth and I can't chair
... should we wait to announce on the list?
<fjh> regrets for next week from Frederick and Rob
shepazu: straw poll: should we do a call next week?
-1 skip without the chairs in the house
<Jacob> -1, especially since we'll likely need to continue this discussion
<Matt_Haas> -1
<chrisbirk> -1
RESOLUTION: no call next week.
azaroth: thanks everyone for the call.
... i'll make the changes to the WD
fjh: we should also publish the WD; thank you bigbluehat for scribing