Re: IAFA templates: a user's comment

"Jon P. Knight" <J.P.Knight@lut.ac.uk> Wed, 22 March 1995 13:28 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02178; 22 Mar 95 8:28 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02174; 22 Mar 95 8:28 EST
Received: from services.Bunyip.COM by CNRI.Reston.VA.US id aa04361; 22 Mar 95 8:28 EST
Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id IAA08336 for iafa-out; Wed, 22 Mar 1995 08:28:16 -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 IAA08330 for <iafa@services.bunyip.com>; Wed, 22 Mar 1995 08:28:06 -0500
Received: from bgate.lut.ac.uk by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA19454 (mail destined for iafa@services.bunyip.com) on Wed, 22 Mar 95 08:27:46 -0500
Received: from suna ([158.125.101.100]) by suna.lut.ac.uk (8.6.11/8.6.11) with SMTP id NAA20592; Wed, 22 Mar 1995 13:26:19 GMT
Date: Wed, 22 Mar 1995 12:56:09 +0000
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: Thomas Krichel <ecs1tk@surrey.ac.uk>
Cc: iafa@bunyip.com
In-Reply-To: <9503210645.AA21199@central.surrey.ac.uk>
Message-Id: <Pine.3.05.9503221208.B19821-d100000@suna>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-Orig-Sender: owner-iafa@bunyip.com
Precedence: bulk

On Tue, 21 Mar 1995, Thomas Krichel wrote:
>   Title: CIA and KGB compared
>   Author-Name-v1: Joe Cowboy
>   Author-Name-v2: Leonid Rostrywizkdgt
> 
>   I think it is improper to use variant in that way, because
>   although Joe Cowboy and Leonid Rostrywizkdgt are variants
>   of the homo sapiens, they should rather be considered a 
>   part of the author group.

I would have said this was the _proper_ way of doing things because Joe
Cowboy and Leonid Rostrywizkdgt are likely to each have different data in
the rest of the USER cluster fields.  For example:

Author-Name-v1: Joe Cowboy
Author-Email-v1: joecowboy@wildwest.com
Author-Job-Title-v1: Herdsman
Author-Department-v1: The Great Outdoors
Author-Work-Phone-v1: +1 555 1212
Author-Worl-Postal-v1: Buffalos Inc, Somewhere, The Wild West, USA.
Author-Name-v2: Leonid Rostrywizkdgt
Author-Email-v2: L.Rostrywizkdgt@querty.edu
Author-Job-Title-v2: Spelling Advisor
Author-Department-v2: Spelling and Grammer
Author-Work-Postal-v2: TypeRight Ltd, Clickerty Street, London, UK.

By using the variant syntax with the cluster elements we can link up the
name, email address, phone number, etc of each author correctly.  Note
that some fields in the cluster may be blank and they're all plaintext so
having things like ``and'' to join the entries together gets messy (and
the things like ``Spelling and Grammer'' in Author-Department-v2 would
screw it up unless there was some form of and-escaping).

>   AFAICS, there is no provision for the subject codes in the current 
>   version. Subject codes are however quite important in some disciplines.
>   In Economics, the Journal of Economics Literature classification
>   scheme is widely used. I would suggest to introduce a 
>   Subject-Classification: JEL A34, B7

There is the Library-Catalog-v* variant field which I've taken to mean any
classification system you care to use.  It might be better to have a
Classification-Scheme-v* field as well so that the template carries the
name (and version?) of the classification system used in the associated
Library-Catalog-v* field.

>   The word "abstract" would be better suited when we describe documents,
>   rather then talking about "description". I would suggest to allow
>   the word abstract as a synonym for description otherwise we will
>   have a hard time convincing people to give up on the word abstract.

Hmm, careful: abstract!=description.  I think Abstract should be a
separate field that is the abstract provided by the author of the resource
the template is pointing to.  In my mind Description is something that the
template creator usually generates that provides useful meta information
(eg: ``This document is part of a series of 16 technical reports by the
same authors that should all be read together'').  Adding a new field is a
low overhead way of handling this.  Fields are cheap after all :-)

>   Price information should also be allowed for organisations
>   that would wish to make information available that has no
>   URL, but can be ordered form the postal address. I would need
>   that field for another project I am involved in that collects
>   info on printed papers. 

Ah, well Thomas; you're the Economist so this one's your baby! :-)
Remember that templates are going to be part of global, highly dynamic
environment so you'll need to take into acount different currencies,
pricing lifetimes, etc.  I'd be highly tempted to make Price-v* a variant
that takes a URL.  It'll need to be a variant because different formats
may be priced differently (plaintext is free but PostScript costs $$$ for
example) and the URL could be used to point to a server that will tell you
the current price and how long that price is guaranteed to remain stable
(plus MD5 checksums, etc, etc).  But of course this ends up replicating
the sort of thing the commercial versions of HTTP are trying to do. 

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 *