[Prev][Next][Index][Thread]
Re: High-level annotation issues
Hi,
OK. Thanks, Dan.
>An annotation server may serve annotations for several distinct sets of
>URLs. Each set, called an annotation set, should be considered a
>distinct logical grouping or collection that is independent of other
>sets that may be on the same server, except for the following. An
>annotation set may contain several annotation subsets and may be
>contained by several annotation supersets. Subsets and supersets may be
Let me just describe the related decisions we made in ComMentor (just
to explain it from there without suggesting to adopt this): Sets
structure annotations into units. This affects primarily the server
(how it is stored there) and somewhat the client (which sets a user
can select in the interface). This is all the structure we have in
ComMentor on the server-side (although, of course, you can structure
the presentation of the html pages which describe sets in any way you
want). Every user is then free on the client-side to structure sets
into whatever way they like, e.g. into a hierarchy. What you are
saying here is that this 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.
>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). I would suggest the
assumption here that sets are conceptually units of storage per
server; in order to distribute load, orthogonal mechanisms (such as
distributed file systems etc.) can be used to deal with this.
>This DAG structure of annotation sets should apply to collections
>in general, and a separate protocol for dealing with collections needs
>to be defined for use by the annotation protocol. We could define
>the collection protocol first and make it visible, or just define the
>annotation protocol hiding the collection protocol it is built on.
>(This is inheritance vs composition, in OO terms.)
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.]
>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. And
since the server stores the sets and has to reply to queries about
them, it should of course know which ones there are (?). For example,
if I query for all annotations in set XY on server S, then the client
submits the authentication information for server S, server S checks
group membership, then determines whether this group has access to set
XY, and then returns the info for set XY.
>The set of annotations of an object is another collection. Annotations
~~~~~~~~~~~~~~~~~~~~~
...but this is generally not an annotation set. You can define this as a
collection mathematically, but it will generally not be computable due
to the access restrictions. The argument would also be that this
collection does not make any sense in a usage perspective: e.g. all
annotations in any set on the world which annotate the Stanford home
page...what does this mean. Note that if someone wants to use a page
as a space for discussion on a certain topic, they can always create a
set and have the convention to annotate this page only. Also note
that with the ability to query the server for a list of annotations in
a specific set with specific properties (I added this function to your
list below), people can easily get the info from a certain set (which
is used for a certain context of use).
>of annotations may be in the same annotation set as the annotation, but
>note that a different object is being annotated.
This special case should follow automatically.
>The annotation protocol should facilitate scalable lookup of annotations
>by clients and servers. This implies that annotation servers should be
>able to offer information to clients about all the URLs that have
>annotations or may have annotations so that clients may avoid making
>requests of a server that has no annotations in the set. This set may
>be given in terms of a pattern or list of alternative patterns to
>abbreviate the transfer and speed the lookup. The format of such
>patterns should be in the scope of the annotation protocol.
Yup. In ComMentor, a simple list of FQDN's was already very effective;
anything fancier can only be better.
>Create (name: string, descriptionDoc: URL) return URL of set.
> - a new annotation set is created with no superset.
>
>Destroy (aSet)
>
>Add Subset (aSet, aSubset)
>Delete Subset (aSet, aSubset)
> - this is how you put one set in another and remove it.
>
>Get Subsets (aSet)
>Get Supersets (aSet)
>
>Add URL Pattern (aSet, aPattern)
> - a pattern may be a specific URL too.
>Delete URL Pattern (aSet, aPattern)
> - deletion may be equivalent to adding a negative pattern.
>
>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
- Get List of all annotations in set aSet with <select>
[this is very important to help people find stuff]
>This is getting close to a query language. It could be considered
Well, it is...
>An annotation is an object with a URL.
>
>Get (URL) - get the annotation object.
Cheers, - Martin
PS: For reference: The ComMentor protocol is at
http://www-diglib.stanford.edu/diglib/pub/reports/commentor.html#APPENDIXC
(substitute "PRDMitem" with "annotation" and you
get the meaning...;-)
References: