Re: Thirdvoice White Paper

Jon Garfunkel wrote:

> What the ThirdVoice White Paper is missing is a sense of meeting some sort
> of standards for annotations. (Not that w3 has offered anything just yet).

Are you thinking of XPointers ?

>
> They do not seem to anticipate an open client/server model, which would
> allow client users to pick whichever servers they want. Currently the
> client is stuck with using the ThirdVoice server.
>
> This may be good for a start, but it seems that eventually users,
> especially institutional ones, will prefer to run their own servers and
> manage their own community.
>

Yes, I agree with that. But this is solved if ThirdVoice sells its server
application
so that any institution can install in "locally".

I fear that the biggest problem of ThirdVoice (and Crit.org) is the fact that
their server is contacted at each browsing request. ThirdVoice becomes
a ThirdEar and raises the problem of privacy : their server can trace users as they

browse the Web.

Of course, the solution is to turn off the service, and then turn it on when the
user
wants to see the annotations on a specific page. But it is not user-friendly : you
have to
remember to turn off the service before you leave a page, adding an overload to
your
browsing activity which usually is already overloaded.
I think a simpler approach would be to contact the service when you wish to see the
annotations
on a page. An other advantage of this approach is its speed since the server is not
contacted
at each browsing activity.

Of course, ThirdVoice is a great improvment over the current annotation systems in
term of
integration within a browser. ThirdVoice has announced a version for NNavigator4,
and I'm waiting
for it... I didn't know that Netscape would provide DOM Level 1 soon (which lets
extra apps - not only
javascripts embedded in the original document - to dynamically change the documents
after it is loaded
by the browser). Do you have any info about this ?

The problem not resolved by the current Web annotation systems is the
identification of an annotation.
They use proprietary protocols and formats. So users cannot insert a link to an
annotation, like they
do today when they insert a link to a document with its URL.
Extended pointers could be a solution : Xpointers already permit the identification
of a phrase
within a document (the anchor point of the annotation). But adding extra parameters
to Xpointers
could be an idea. Imagine an annotation encoded like this :
http://www.yahoo.com/#annotation=<highlighted
phrase>&date=19990225&comment=ok%20with%20that
In this example, I didn't use the XPointer syntax, but replaced it with
annotation=<...> where <...> represents
the string in the document where the annotation will be attached to.
Then other datas may be encoded, like the date of creation, and a short comment...
If comment are longer, the URL of the comment could be inserted in place.

Encoding annotations using this idea would permit the automatic indexation and
retrieval of annotations
published anywhere on the Web (news-groups, Web pages). A search engine could
search the Web and
retrieve all such extended URLs from the Web pages or news-groups it encounters.
Annotations could also be sent by email since they have an unique identifier (the
xURL).

But this idea brings a conceptual problem : usually the URL is made to identify a
resource, but here
an extended URL becomes a resource in itself, since it encodes other data which are
not necessary
to identify the original resource.

Any feedback on this idea would be appreciated.
Laurent.

Received on Wednesday, 19 May 1999 06:42:23 UTC