Re: client/server model

Hi, Ray–

On 6/16/15 10:01 AM, Denenberg, Ray wrote:
> Well, since you asked …
>
> I’m not very interested in conformance.I recognize its importance but
> my interest in the client/server discussion is that I like to be able to
> understand the model of process flow and you need to name the pieces in
> order to describe the process.
>
> In my mind, this is the abstract process model.

I'm assuming you really meant to say something like, "For the purposes 
of my immediate goal, let's temporarily set aside the details of 
conformance and establish a common annotation processing model".

(If it's not obvious, conformance is the whole reason we're talking on 
this list, and why we formed this working group. If we're not interested 
in making an implementation that's interoperable with other 
implementations, then there's little point in us discussing what an 
implementation could, would, or should do.)


> /There is a client, which I’ll call the “Annotation Client”. /
>
> /It  does three things:/
>
> /1.//Accepts annotations from a user agent. (Or annotation components:
> target URI, body, etc.)/
>
> /2.//Queries the target resource to find out where annotations are to be
> posted./
>
> /3.//Posts the annotation./
>
> /(I realize that the first is not included in out model, but it’s part
> of my mental model.)/

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.

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 choosing (which choice may be informed by suggestions from the 
resource, the Resource Server, the Annotation Client, or even some 
unspecified Annotation Server discovery mechanism).

An Annotation Client might do several things:

1. Create an annotation on a resource (which is located on a Resource 
Server) based on user action

2. Publish the annotation to an Annotation Server of the user's choice

3. Query one or more Annotation Servers for annotations which have the 
current resource as a target; the list of candidate Annotation Servers 
might be those subscribed to by the user, or suggested by the resource 
or Resource Server or Annotation Client

4. Retrieve the selected annotations from the Annotation Servers; this 
might happen repeatedly while the user is on the same resource, to get 
live updates

5. Filter and order annotations based on the user's settings

6. Anchor the annotations on the resource, and apply any highlight styling

7. Display the annotations in a manner appropriate to the resource 
content (for example, show only annotations that are anchored on the 
content that's in the current viewport)

8. Navigate to sections of the resource based on interaction with the 
active annotations

9. Allow users to reply to (annotate) other annotations

(There's actually quite a lot of other things an Annotation Client could 
do, but these seem like the core basics.)



> /There is a server.  Actually two servers.  One is where the resource
> (to be annotated) resides.  The other is where the annotations for that
> resource reside. Since these can be different servers, there need to be
> two servers named in the model (and of course in any instance they can
> be the same server).  So for lack of a better name, I’ll call them the
> Resource Server and the Annotation Server.

Yes, the Annotation Server and Resource Server might be the same.

Note that the Resource Server might not be a server at all, but an ebook 
on a ebook reader. And that the Annotation Server might not be a server, 
but local storage on a device like a tablet, phone, or ebook reader. 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.

Identifying roles for different components, such as "Server" and 
"Client", is still a useful exercise for clarity, however, so your 
terminology seems sound to me. As you say, it's an abstract model, but I 
thought it might be useful to spell out just how abstract it is, and how 
flexible the Web Annotation architecture is.



> 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.

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.


> Now whether or not we actually include this abstract process model in
> one of our documents, my point is that this is the model that I infer
> from the model and protocol documents, but since we have never
> articulated it succinctly as such, I don’t really know for sure.  And if
> there are differing opinions about whether this is the abstract model,
> then that argues for including the real abstract processing model
> explicitly (normative or non-normative, I don’t care which).

I agree that it's good to be explicit about it. I hope my model matches 
others' ideas about it, or that someone can improve upon my model or 
show where there are flaws that can be corrected.

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, and provides a high-level 
overview for people just learning about Web Annotations.

It could even be a normative document, like I described earlier today in 
another thread [1] about copy-edit behavior: a "spec that defines such 
behaviors [around the "editing" motivation], and which would presumably 
also talk about how to use the Annotation Protocol to create, send, 
download annotation in the Web Annotation Data Model, and how to apply 
the selectors from the data model to anchor them in the document using 
the RangeFinder API, and so on".


[1] https://lists.w3.org/Archives/Public/public-annotation/2015Jun/0107.html

Regards–
–Doug


> Ray
>
> *From:*Robert Sanderson [mailto:azaroth42@gmail.com]
> *Sent:* Monday, June 15, 2015 6:58 PM
> *To:* Denenberg, Ray
> *Cc:* Web Annotation
> *Subject:* Re: client/server model
>
> Revised content:
>
> http://w3c.github.io/web-annotation/model/wd/
>
> The majority mentions of client that are left in are when there was an
> opinion about conformance.  For example that clients need not process
> Styles, either using the Style class or when embedded in SVG selectors.
>     Also the word "application" is used synonymously with "client".
>
> Are there opinions about where this sort of thing should live?  Is this
> a good on ramp to the levels of conformance discussion for the model?
>
> Thanks!
>
> Rob
>
> On Mon, Jun 15, 2015 at 2:28 PM, Robert Sanderson <azaroth42@gmail.com
> <mailto:azaroth42@gmail.com>> wrote:
>
> Yes and Yes :)  I'll try and generally reduce the client/server
> discussion in the model document as unnecessary once we have a protocol
> spec.
>
> Rob
>
> On Mon, Jun 15, 2015 at 2:26 PM, Denenberg, Ray <rden@loc.gov
> <mailto:rden@loc.gov>> wrote:
>
> Thank, Rob.  Just to confirm my understanding:. Two questions:
>
> (1)
>
> * client: A system that receives an annotation …..
>
> Is it safe to say this means “A system that requests and receives an
> annotation from the server …”
>
> I don’t mean to be Captain Obvious, but it probably would be a good idea
> to spell this out.  “Receives an annotation” could be interpreted to
> mean “receives an annotation from a user (which it will then submit to
> the server”.
>
> (2)
>
> Do I understand correctly that the process of creating of an annotation
> is not (yet) covered by these definitions?
>
> Thanks.
>
> Ray
>
> *From:*Robert Sanderson [mailto:azaroth42@gmail.com
> <mailto:azaroth42@gmail.com>]
> *Sent:* Monday, June 15, 2015 4:23 PM
> *To:* Denenberg, Ray
> *Cc:* Web Annotation
> *Subject:* Re: client/server model
>
> Hi Ray,
>
> That's a great question!  In the community group, we intentionally
> didn't discuss protocol between clients and servers and left that for
> future work.
>
> The use of client (or equivalent 'consuming client') and server in the
> model should only ever be informative rather than requiring behavior.
> Behaviors should be in the protocol specification.  I'll go through and
> work on that, as we were probably not at all rigorous.
>
> The implicit understanding of client and server in the model doc at the
> moment I think are:
>
> * client: A system that receives an annotation according to this model
>
> * server: A system that makes available an annotation according to this
> model
>
> So just the base line retrieval function (and not even specifying how),
> rather than creation of the annotation or discovery of annotations
> according to some criteria.
>
> Does that answer your questions?
>
> Rob
>
> On Mon, Jun 15, 2015 at 11:14 AM, Denenberg, Ray <rden@loc.gov
> <mailto:rden@loc.gov>> wrote:
>
> This is a fairly basic question about the model.
>
> I’m trying to write an annotation profile (to profile the Web annotation
> model for bibliographic applications).  I’d like to express parts of it
> in terms of client/server  modeling.
>
> The current model (http://www.w3.org/TR/annotation-model/) hint at such
> a thing, it uses the terms “client” and “server”,   but doesn’t define
> them. Also, the terms “client” and “consuming client” are used, and I am
> not sure what is the difference (if there is any difference).
>
> In the model in my mind, there is a user with an interest in a resource,
> and wants to do one (or both) of the following:
>
> 1.Find annotations on the resource
>
> 2.Annotate the resource
>
> ·I assume the *annotation client* is the client that performs these
> requests on the users behalf. Does “consuming client” refer to #1 above,
> that is, the client consumes annotations on behalf of the user?
>
> · The *annotation server*. The client is going to have to interact both
> with the server where the resource resides and the server where the
> annotations reside.  These could be different servers.
>
> It might be useful to clarify this in the model.
>
> Ray
>
>
>
> --
>
> Rob Sanderson
>
> Information Standards Advocate
>
> Digital Library Systems and Services
>
> Stanford, CA 94305
>
>
>
> --
>
> Rob Sanderson
>
> Information Standards Advocate
>
> Digital Library Systems and Services
>
> Stanford, CA 94305
>
>
>
> --
>
> Rob Sanderson
>
> Information Standards Advocate
>
> Digital Library Systems and Services
>
> Stanford, CA 94305
>

Received on Wednesday, 17 June 2015 02:52:43 UTC