Re: A Note on URC Querying

Leslie Daigle writes:

> Sorry for stepping into this thread a little late -- my mailbox
> turned into a listserv war-zone lately, and careful excavation has
> taken a while...

I keep feeling sympathy for anyone on this list who went on holiday 3
weeks back and came back to find all the URN-related messages to sift
through :-)

> My understanding of the thread is that the proposal is to build
> URC-searching with URCs themselves, defining a semantics for
> handling URC templates as queries.

That's mainly how I see it, with the important proviso that it's not
really a proposal: more a pointer to the fact that the URC proposed
spec actually allows this anyway.  "Whatever is not forbidden is
permitted."  (Quiz: Who said that, and what were they wearing at the
time?  Answers on a postcard, please, but not to me. :-)

The reasoning behind the original posting is as follows: if the spec
allows URCs to be constructed that are basically objects in the strong
sense of the term, can people not build systems which make use of this
feature?  In that case, why not attempt to foresee some of the issues
and pitfalls that will arise?

> Architecturally, I can not say I thnk this is the way to go.  If we
> do URC's right, they will represent characteristics of information
> resources, and, yes, those representations are an integral part of
> effective and efficient searching for resources.  However, if I have
> correctly understood it, the URC spec (or a closely-related one)
> will also incorporate standards for how searches are handled.

I completely agree that it is necessary to get URCs right.

Architecturally speaking, the best guidance we have is the knowledge
that systems consisting of distributed objects can be well understood,
whereas without objects they are are muddy swamp.  I am not saying
that the data representations possible with URCs should be bent in
some way so as to allow searching or retrieval more efficiently
(especially given all the sins committed with efficiency as a
justification).  Search and retrieval are not even the only things
that could conceivably be required of a URC object.  I am only certain
that soon someone will want/need to do something with URCs that I
cannot visualise right now (mobility, multimedia, megalomania...?).
Experience shows that extensibility is well served by use of object
based designs.

In a nutshell, am saying that the spec should not be made into a
straitjacket that will not permit scenerios like the one I originally
proposed.

I also agree with your understanding that the URC spec will ultimately
incorporate searching-related standards.  So far, from my reading of
the URC spec, it seems as if this is concerned with specifying a
minimal guaranteed set of query primitives that can be exploited by
search agents.

> I think this is premature because URCs were constructed after
> studying the task of _representation_ (which is presumably
> understood), not search and retrieval (which isn't -- we don't know
> all tasks which people and/or programs will need to have supported
> by searching through URCs), and the examples that were cited in the
> thread were for more than just search primitives.

I could quote you a few piles of papers on metadata representations,
well no, maybe that's an exaggeration, say one pile.  Some of them are
highly profound, some may be trivial.  One of mine has references to
most of the (other :-) good ones: Madsen, Fogg & Ruggles, "Metadata
Systems: Integrative Information Technologies", Libri 44(3)237-257
(1994).

The example I gave was geared to showing that there were reasonable,
interesting, and complex things that one could quite legitimately ask
for that were (i) not exlicity disallowed by the spec (ii) easy to fit
within the letter of the spec, (iii) technologically possible with
existing tools and languages like Tcl, Obliq, and Java.  Any standard
that excludes reasonable use-demands will not long be adhered to.

> [Mark Madsen wrote:]
> 
> > I'm carrying the quoted example below to maintain the context for the
> > discussion.

(Please note, I did not write this bit.  My guess is it was Terry
Allen or Ron Daniel)
> > > asks whether we could use processing instructions to convey
> > > that info instead.  Here's the example:

(My original example, severely pruned)
> > > > <!doctype urc SYSTEM "urn:x-dns:uri.ansa.co.uk:method-dtd-7">
> > > > <urc>
> > > > <author method="m1">Smith, F.</author>
> > > > <subject method="m2">Cats</subject>
> > > > <URL></URL>
> > > > <results>
> > > > (Initially empty, this container holds the results of the
> > > > searches.)
> > > > </results>
> > > > <methods>
> > > > <m1 lang="niceScript">
> > > > (A script written in the niceScript(TM) language that
> 
> [snip]
> 
> > I would prefer to see all this defined in a way that didn't depend on
> > a particular language.  (I am perfectly happy to see SGML used as the
> > specification language for URC syntax.)

> I urge you to go back and check out the URA Internet-Draft.  The
> structure of the example is not at all dissimilar to the kinds of
> things we've been talking about for URAs.  We haven't suggested an
> implementation methodology at this point, but the test URAs we've
> been playing with (in Silk) have been written in tcl and have a
> similar structure.

I shall go back and have another look at URAs.  I don't have a problem
with URAs doing similar things to what I described for URCs, myself,
because ultimately every computational object on the WWW will
want/need to be able to do things like this.  If URCs and URAs are so
similar, then there may be some point in merging the 2 concepts into
one at the top level and giving them each their own subclass
descriptions.

> By contrast, though, URAs:

> 	a) are not for searching only (although that's primarily what
> 	   we've done with them in Silk)

As I explained above, URCs are not for searching either, since the
method embedding I used contains computationally complete schemes.

> 	b) take a step back to _describe_ the URA's data components (I
> 	   believe it was the "what" section in the paper), or the
> 	   attributes in  the example above.  This means that the URA
> 	   can encapsulate a search for subjects, which can be instantiate
> 	   to be a search for cats...

Likewise, the example I cited could easily have been constructed so as
to instantiate an interface to a search object.  But the example would
have been even longer.

> I'll stop here, because I'm on a beastly slow link and generating
> semantically parsable sentences is quite a challenge.  I'd be happy
> to continue talking about these things if we think there is
> commonality between what is being described here and what we've
> identified in URAs.

There is commonality between what I originally described (URCs as
autonomous agents) and any other distributed object systems.

The message I am getting from your comments is that we all want to
move the Web over to a distributed object model.  That's great,
because here we feel strongly about such things: see

       <URL:http://www.ansa.co.uk/phase3-activities/>

I'd consider it worthwhile to prolong this discussion so as to learn
better how to do that.

> Leslie.

Regards,
         Mark.
--
________________________________________________________________________
Mark Madsen: <msm@ansa.co.uk> <URL:http://www.ansa.co.uk/Staff/msm.html>
Information Services Framework, The ANSA Project, APM Ltd., Castle Park,
Cambridge CB3 0RD, U.K.  <URL:http://www.ansa.co.uk/>;  <apm@ansa.co.uk>
Voice: +44-1223-568934; Reception: +44-1223-515010; Fax: +44-1223-359779

Received on Monday, 3 July 1995 09:40:14 UTC