# Re: Criticism of Kidcode (was Re: KidCode: Next steps )

From: Ron Daniel Jr. <rdaniel@acl.lanl.gov>
Date: Thu, 22 Jun 1995 16:10:02 -0600
Message-Id: <9506221610.ZM777406@macrdan.acl.lanl.gov>
To: "Ronald E. Daniel" <rdaniel@acl.lanl.gov>, Darren New <dnew@sgf.fv.com>
Cc: Martijn Koster <m.koster@nexor.co.uk>, Nathaniel Borenstein <nsb@nsb.fv.com>, rating@junction.net, uri@bunyip.com, www-talk@www10.w3.org
Earlier this week I promised to revise part of the URC Scenarios and
requirements document to accomodate information filtering ala KidCode.
That one section of the document is appended.

Regards,
Ron Daniel
-----------

\subsection{Annotations, Seals of Approval, and Information Filtering.}
\label{sec:soap}

Many projects already use the web as a means for describing, recording,
and coordinating the work of the project members. URCs might be used
as the basis for even more collaborative work. Workflow systems,
and enterprise library systems are a couple of models that might be
constructed on top of a URC service. A very interesting class of
services falls under the general notion of annotation systems''. In the
early days of Mosaic, a global annotation system was provided. However,
that system did not have the necessary scalability, and we are unaware of
any good proposals for global annotations. However, a very good proposal
for group annotations has come out of the Stanford Digital Library effort
\cite{prdm}. Its architecture would enable a variety of interesting
scenarios, including several intriguing business opportunities.

Many scenarios could be constructed using the models mentioned above.
In this paper we will only consider one generic scenario, then describe
how it can be specialized to meet a variety of information filtering
needs. The generic scenario will have one group annotate resources with
a Seal Of APpproval (SOAP), and other groups using such seals as
information filters in order to assure appropriate and/or high quality
information.  SOAPs are one of the interesting products of the
Interpedia effort \cite{rhine}. A SOAP is just a very short review of a
resource indicating approval or disapproval according to the tastes of
the person or organization issuing the review. Being short, it is easy
to query in order to make view / don't-view decisions.  It may have a
link to another resource in order to provide a more comprehensive,
human-readable, review. For the truely paranoid among us, digital
signature techniques could be used to ensure their veracity, as
outlined in earlier scenarios. However, this is not a necessary feature
for all SOAPs.

The first part of the scenario requires a group of people to run a
rating service.  The group might be a professional organization doing
peer review of scholorly publications, a local school board looking for
materials deemed inappropriate for children in the community, a lone
critic reviewing Internet resources, a review group at a facility that
did potentially classified research, or any of a wide number of other
reviewers.  When they find a resource that they wish to rate, they
build a URC for it. This may be a whole new URC, or it may be strongly
based on information provided by the publisher or another third party.
The new URC would contain their review information in whatever format
they believe best meets their needs. Clients of the rating service bear
the responsibility for being able to understand the rating.
Even resources without URNs could have such a 3'rd party URC established
if the URC server can be queried according to URL or other information.

For information filtering, the browser would have a set of active
annotation servers. When the user attempts to access a new resource,
its URN or URL is sent to the annotation servers. If they have any
information on that resource, it could be sent back in the form of
URCs. The browser could then examine the URCs, decide if the content
ratings did or did not meet the criteria for information display,
and either show the resource or not.

In an information discovery scenario, a physics grad student wants
to find high-quality information in a specialized subdiscipline of
string theory.  The student accesses a search page run by the American
Physical Society and puts "string theory" into the subject field and
9 into the "minimum rating" field. (We assume the APS grades accepted
papers on a scale of 1 to 10, a totally unrealistic assumption).
The query is submitted, which searches the APS collection of URCs
on papers they believed were good enough to merit their seal of
approval. A list of papers is returned to the student, who then
decides which ones to look at.

Because of the likely popularity of such services, SOAPs will
become the valuable intellectual property of the reviewing
organizations. Almost all review organizations will probably charge
some money to become a client of their service.

The scenarios above impose two requirements on the URC. First, it must
be possible to extend the URC by adding arbitrary elements. In the case
above, the SOAP is the new element. Second, it must be possible to
ignore elements that you do not understand. For this to be possible it
must be possible to determine where any particular element ends, even
if you know nothing about the structure of information inside the
element. Note that there is an interaction between ignorability and
having a consistent representation for the purposes of digital
signatures. Digital signatures are computed over the {\it external}
representation, which can include experimental elements. Ignorability
is a feature of the conversion from the external to the {\it internal}
representation, where if we do not understand an element we are free to
discard it while we are parsing the URC.

--
Ron Daniel Jr.                     email: rdaniel@lanl.gov
Advanced Computing Lab             voice: (505) 665 0597
MS B287                              fax: (505) 665 4939
Los Alamos National Laboratory      http://www.acl.lanl.gov/~rdaniel/
Los Alamos, NM  87545          tautology:"Conformity is very popular"

Received on Thursday, 22 June 1995 18:06:16 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 27 October 2010 18:14:17 GMT