RE: client/server model

Ok Doug, I have finally found time to address your substantive points.



From: Doug Schepers [mailto:schepers@w3.org]

> I'd characterize it a bit differently, since the Annotation Client might create or

> consume annotations… in other words, the Annotation Client is the "user

> agent" in your #1.



Ok.



> Your model also seems to assume a centralized architecture, where the

> target resource dictates where the annotation is to be published; that's one

> possible model, but I'd assume a more decentralized architecture, in which

> the annotation can be published on an Annotation Server of the user's

Well, by my reading of the protocol, the target resource is essentially saying, "if you want me to take your annotations seriously, here is where to put them.  Of course, you can put them wherever you like, but if you put them somewhere else, it is unlikely I'll ever know about them."   Maybe I'm reading too much into the protocol, but then, that's why I like models explicitly described.





> An Annotation Client might do several things:



You've listed a lot of things, and an annotation client might do all these things, but I was (for now) trying to model only the minimal functionality, as in, if you cannot do these things, don't call yourself an annotation client.    Also, it isn't clear (to me, if at all) where functionality like filtering will reside - on the annotation client or annotation server.





> Note that the Resource Server might not be a server at all, but an ebook

> on a ebook reader.  ....



But it's a web resource, right?  (That's what we're annotating, web resources.)  If it's a web resource I consider it to reside on a web server.



...  And that the Annotation Server might not be a server,

> but local storage on a device like a tablet, phone, or ebook reader.



If it performs the functions of an annotation server, I consider it to be a server.





And

> that the Annotation Client and Annotation Server might also be the same,

> for a similar offline or local storage scenario. And that Annotation

> Servers might talk to one another, and share content, such as via user

> sharing or aggregation, or local storage syncing with a remote (public

> or private) cloud storage, or local storage syncing between two devices

> (in which case, each Annotation Server might play the role of an

> Annotation Client).



> These are all perfectly plausible scenarios, and maybe even likely.



Yes of course. But I think you misunderstand my purpose. I am not trying to *develop* a model.  I am simply trying to *infer* a model, from the existing draft specs.  Most of these things you mention have not been addressed in any of our documents.



> > The Annotation Client interacts with the Resource Server and the

> > Annotation Server respectively, for steps 2 and 3 above./

>

> That's one scenario, but I don't think it's the most likely one.



Once again, that's how I interpret the protocol.  If I want to annotate a resource of interest to me, I first have to find out where to post the annotation, and I realize you and I don't necessarily agree on that point, but that's really the point of this exercise: there is an implicit model and there is disagreement about the model, and the best way to resolve that disagreement is to make the model explicit rather than implicit.





> Normally, I wouldn't expect (much or any) direct interaction between the

> Annotation Client and the Resource Server; that's more or less the

> scenario with have with commenting systems today, where the resource (or

> Resource Server) dictates where (and if) the comments are published,

> either on the same Resource Server as the resource, or on some

> preselected commenting service that's embedded into the resource.

>

> That doesn't increase control or privacy to users, nor offer much beyond

> what is done today; I'm hopeful that the distributed architecture I

> described above is the dominant outcome.



Well again, if the client can post an annotation any old place it wants to, that raises the question of how the resource (or resource server) finds out about it.  There are of course several possible ways but I don't think any of our documents covers this.  So I think it's time to start thinking about that.





> I'm inclined to think that we would be well-served by creating a Web

> Annotation Architecture document that would explain how all the moving

> parts (that is, the WG's specs) fit together,



I think so too. And I think an abstract model and an architecture are roughly the same thing, so if you want to call it an architecture, that’s fine with me.





... and provides a high-level

> overview for people just learning about Web Annotations.



Separate document,  I think.  At some point there will be a Primer, I assume.





I look forward to continuing this discussion.



Ray