Re: IAFA templates: a user's comment

"Jon P. Knight" <J.P.Knight@lut.ac.uk> Mon, 03 April 1995 09:46 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01276; 3 Apr 95 5:46 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01272; 3 Apr 95 5:46 EDT
Received: from services.Bunyip.COM by CNRI.Reston.VA.US id aa02350; 3 Apr 95 5:46 EDT
Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id FAA29739 for iafa-out; Mon, 3 Apr 1995 05:46:22 -0400
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id FAA29718 for <iafa@services.bunyip.com>; Mon, 3 Apr 1995 05:46:12 -0400
Received: from bgate.lut.ac.uk by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA16929 (mail destined for iafa@services.bunyip.com) on Mon, 3 Apr 95 05:46:09 -0400
Received: from suna ([158.125.101.100]) by suna.lut.ac.uk (8.6.11/8.6.11) with SMTP id KAA14189; Mon, 3 Apr 1995 10:44:28 +0100
Date: Mon, 03 Apr 1995 10:26:09 +0100
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "Jon P. Knight" <J.P.Knight@lut.ac.uk>
Subject: Re: IAFA templates: a user's comment
To: Martijn Koster <m.koster@nexor.co.uk>
Cc: Jill Foster <Jill.Foster@newcastle.ac.uk>, iafa@bunyip.com, mrp@itd.adelaide.edu.au
In-Reply-To: <9504030842.AA16812@mocha.bunyip.com>
Message-Id: <Pine.3.05.9504031008.C13874-c100000@suna>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-Orig-Sender: owner-iafa@bunyip.com
Precedence: bulk

On Mon, 3 Apr 1995, Martijn Koster wrote:
> So lets see: Jill Foster think's it's ugly, I think they're gross,
> Alan doesn't care for them, and the IESG doens't like them either. I
> have said in the past we should probably keep them because of the
> legacy, but after all this *is* a draft. Sounds to me like they need
> to go, or at the very least marked as deprecated.

You chaps might not like them, but I think it provides some of the core
functionality of the IAFA template format.  If its the actual textual
format of the variant fields that's worrying people then fair enough;
we've all got to sit down and come up with a cleaner replacement syntax
(LISP pretty printed format maybe?).  If its the fact that you think end
users will have difficulty creating them, then I think that's going to be
an inherent problem in any decent metadata representation.  Just look at
good old MARC for example - you wouldn't want to have your naive users
creating MARC based templates would you?  The problem therefore seems to
be creating a set of template creation/management tools that have a
reasonable human interface that tries to extract as much information out
of the naive human user as possible whilst insulating them from the
underlying complex and powerful template format.  I think we may be trying
to make people into librarians without expecting them to understand any of
the details of cataloguing, classification, etc.  Could be fun... :-)

However, I don't think that they can just go or be deprecated because IMHO
they provide a very useful function.  If they are to be _replaced_, it
would be nice if a new format was devised inconjunction with the WHOIS++
and URC development so that we don't end up with three different metadata
formats.  After all many of the people here are on two or more of the WG
mailing lists - why duplicate the effort (both in terms of the design of
the format and also the creation and use of tools to handle them).

> So would you say it's more important to have the one description
> pointing to "somewhere" where all these files are, than explicit
> mapping between variants and locations?

One word: URN.  Which kinda bring us full circle... :-)

Jon

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Jon Knight, Research Student in High Performance Networking and Distributed
Systems in the Department of _Computer_Studies_ at Loughborough University.
* It's not how big your share is, its how much you share that's important *