[Prev][Next][Index][Thread]
Re: High-level annotation issues
> From: "R. Martin Roscheisen" <rmr@cs.stanford.edu>
> OK. Thanks, Dan.
And thanks for your quick comments.
I said:
> >An annotation server may serve annotations for several distinct sets of
> >URLs. Each set, called an annotation set, ...
This is perhaps ambiguous, or at least confusing. A single annotation
set consists of a set of URLs that have annotations in the set. (Typically
the URLs will be related in some way.) For each URL in the set, there
may be a set of annotations. All these annotations for all these URLs are
"in" the annotation set, though a two level structure is more correct.
> >An annotation set may contain several annotation subsets and may be
> >contained by several annotation supersets.
> What you are saying here is that this [representation of hierarchical
> set structure] should be extended to also having set
> structures on the server side. This might be a useful generalization,
> ok. Then, I guess it is to clarify what a superset can contain: can
> it contain a mixture of plain annotations and sets (like directories
> can contain other directories and files), or only other sets. I
> suspect the latter one might be better in this case. The notion of a
> subset seems intricate operationally; maybe this should be left out.
The idea of sets within sets seems a pretty natural extension for
us, though we haven't worked out all the details yet. We do think of
sets as containing other sets and also the annotations within each set,
much like directories, as you suggest. But I won't press it much yet
until we see how it works out in the implementation.
In any case, the generalization to collections composed of subcollections
is dominant enough in the web that I expect a collection protocol will
emerge, upon which we can build annotation sets.
> >on different servers. Everything about a single set should probably
> >be on a single server, but not necessarily if we can make it work.
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> We tried this at some point, but this introduced far more complexity
> than it was ever worth it (think of the security issues involved and
> its ramifications for the protocol request types).
Yes, let's drop that one. If we were to make it work, it would
be via something like distributed file systems, as you suggest.
> Well, since supersets are built on top of sets, we could also decide
> to leave them out entirely for now, get the basic protocol done first,
> and then go back and extend the annotation and set request protocol to
> include things such as supersets and other things. [But if you already
> have thought it through...fine.]
This is a reasonable plan - and it wouldnt get in the way of the
extension later to support subsetting. Later then (but not too much later).
> >The server of annotations itself may or may not know about all the
> >annotation sets it serves, so the annotation protocol should not be
> >about talking with annotation servers so much as annotation sets. An
> ??? Annotation sets are uniquely defined by their name and the server
> which they are on. For example, if I create an annotation set, then
> the protocol has to deal with the annotation server of course.
This relates to subsets, actually. So maybe not thinking about
subsets does interfere a bit.
The model I am working from is that http servers should not be
considered the information units. Servers are administrative units
that function more as proxies to the actual data than as the keepers of
all the data. A single server might have numerous annotation sets
maintained by several independent groups that might not even talk to
each other. Why should the server know about all the annotation sets
that might happen to be on the server?
In this model, the data itself (an annotation set in this case) and
the code associated with the data (whether in cgi scripts or other
extension modules) are the real annotation server. There isn't
necessarily a single piece of code that handles all annotation sets
that might be on the server.
If there is to be a grouping of some *related* annotation sets,
collecting them into a single superset would be the way I would want to
do it. But in this case, it is probably even more important to support
sets that cross server boundaries since all related annotation sets
might not be on the same server.
The main point I want to make is that all the annotation sets on a single
server are *not* necessarily related, so the server should not be
providing a list of them as if they were related. The fact that they
are on the same server is largely irrelevant.
A server would have to know how to lookup a particular object which
turns out to be an annotation set and then do things with it, like find
annotations in it. But that does not mean the server must know where
all the objects are that are annotation sets so it can list them.
I have a similar complaint about the idea of searching through all
documents on a server. It should be searching through documents in a
*collection*, not the server as a whole. It may happen that all
documents on a particular server are related and so may be in the
same collection, but this is not necessarily so for all servers.
> >The set of annotations of an object is another collection.
> ~~~~~~~~~~~~~~~~~~~~~
> ...but this is generally not an annotation set.
I didn't mean to suggest (by my ambiguity) that it would be an
annotation set. Nor did I mean the set of all annotations in the
world. I meant the set of annotations of an object in a particular
annotation set.
"Set" has almost the same meaning as "collection", so all I was
suggesting was that the protocol for manipulating other kinds of
collections might apply here too. In particular, searching for a
particular object in a collection works here too.
> >Add Annotation (aSet, URL, annotation)
> > - the annotation of the URL is added to the set
> >Get Annotations (aSet, URL, selector, parts)
> > - return all annotations of the URL in the set. If selector given,
> > select only those annotations that meet the criteria. If parts
> > given, return the parts requested from each annotation.
> How about:
> - Delete Annotation
Yep, forgot that one. Also edit, but that is getting into version control..
> - Get List of all annotations in set aSet with <select>
> [this is very important to help people find stuff]
That's what I have above for "Get Annotations" with a selector and
parts spec, without being too clear about it, I know.
Notice, I've left out all management of groups and members. We need
another protocol for this. Do we need another working group or should
we take it on too? I think it deserves a different group more closely
involved with security. Things like roles and credentials should be
considered, as well as hierarchical and distributed groups, keys and
what not.
We also need a protocol for manipulation of access control lists that
identify who can do what functions to what objects.
It's a bit difficult to build a high level protocol without the
lower level pieces already in place.
The next step in specifying the protocol is to map it onto two different
lower level protocols: HTTP via CGI and HTTP via new methods. CGI
because current servers can deal with it, and new methods because we
are extending the server to handle arbitrary new methods using a general
method handler interface (MHI).
dan
Follow-Ups: