Re: IAFA templates: a user's comment

Thomas Krichel <ecs1tk@surrey.ac.uk> Fri, 24 March 1995 08:21 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa27477; 24 Mar 95 3:21 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa27473; 24 Mar 95 3:21 EST
Received: from services.Bunyip.COM by CNRI.Reston.VA.US id aa25278; 24 Mar 95 3:21 EST
Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id DAA15192 for iafa-out; Fri, 24 Mar 1995 03:21:24 -0500
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 DAA15187 for <iafa@services.bunyip.com>; Fri, 24 Mar 1995 03:21:20 -0500
Received: from maila.surrey.ac.uk by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA09728 (mail destined for iafa@services.bunyip.com) on Fri, 24 Mar 95 03:21:15 -0500
Received: from central.surrey.ac.uk by maila.surrey.ac.uk with SMTP (PP); Fri, 24 Mar 1995 08:20:59 +0000
Received: by central.surrey.ac.uk (1.37.109.8/16.2) id AA27851; Fri, 24 Mar 1995 08:20:56 GMT
Message-Id: <9503240820.AA27851@central.surrey.ac.uk>
Subject: Re: IAFA templates: a user's comment
To: Martijn Koster <m.koster@nexor.co.uk>
Date: Fri, 24 Mar 1995 08:20:56 +0000
Cc: iafa@bunyip.com
In-Reply-To: <9503220932.AA02765@central.surrey.ac.uk> from "Martijn Koster" at Mar 22, 95 09:23:36 am
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Thomas Krichel <ecs1tk@surrey.ac.uk>
Reply-To: Thomas Krichel <ecs1tk@surrey.ac.uk>
X-Org.: Department of Economics, University of Surrey, Guildford GU2 5XH, UK
X-Tel.: 44-(0)483-300800x2785, Fax: 44-(0)483-303775, Ethnic origin: Saarland
Content-Type: text
Content-Length: 2665
X-Orig-Sender: owner-iafa@bunyip.com
Precedence: bulk

  Martijn Koster writes:

> | If there are multiple authors or editors, they should
> | all be separated by the word and.
> 
> This should of course be generalised tot names other than
> author/editor, but means you donot need to repeat a Author field for
> multiple authors, or duplicate values accross variants of a document.

  Problems with this strategy have been pointed out by Jon and ToK in
  recent messages.

> The variant part of the IAFA templates are a quick fix for a small
> domain of problems surrounding manifestations of a
> document. Personally I'd like to see it removed altogether, but it'll
> have to stay in for backward compatibility.

  Can you give us an idea what the replacement will look like and maybe
  a date at which we may expect another version.

> I don't think it's appropriate for the IAFA templates to attempt to
> solve all the issues, especially when it impacts the templates main
> selling point, simplicity.

  I would warn against making the templates to simple. The emphasis
  should be on giving a good description, and have some people watch
  that the info provided  does not contain too many mistakes. That
  would be the point of an intermediary like WoPEc.

> I tend to think of a resource as a "something on the internet", that I
> can point to. The variants came in to fix the case where two resources
> are the same intellectual content. Describing parts however, splits
> the resource up, I can no longer point to it, the parts don't have the
> same intellectual content. So the parts are resources themselves.  If
> they're not meant to be, becuase they're part of say one document,
> then this document should be made available as a resource
> (tar/zip/stuffit whatever).

  Yes, I agree with that, but in practice it is a problem because
  there are a number of different archivers arround and because some
  publlishers do not compress/archive their resource. They do not care
  to do that. Emailing them is useless, they do not reply. 

  Let me add: If the templates are made to describe a single file, then
  this should be said so in the doc. IMHO this would be quite a severe
  drawback.

> We need to draw a line somewhere; otherwise we'll be talking about
> URL-v0-p1-e2-l3 to describe a gzipped copy on a european machine of
> part 1 of an english variant of a document, etc. We cannot solve all
> problems in one. I'm very, very wary of making it more complex than it
> is at the moment.

  I very much agree with this. Have a good day!

 

  Thomas Krichel                              mailto::T.Krichel@surrey.ac.uk
                                    http://netec.mcc.ac.uk/~lgecstk/ToK.html