IETF Logo Mail Archive

Re: new iafa draft

Thomas Krichel <T.Krichel@surrey.ac.uk> Thu, 11 January 1996 00:22 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16567; 10 Jan 96 19:22 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa16563; 10 Jan 96 19:22 EST
Received: from services.Bunyip.COM by CNRI.Reston.VA.US id aa14919; 10 Jan 96 19:22 EST
Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id RAA20262 for iafa-out; Wed, 10 Jan 1996 17:43:57 -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 RAA20257 for <iafa@services.bunyip.com>; Wed, 10 Jan 1996 17:43:55 -0500
Received: from mailb.surrey.ac.uk by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA00592 (mail destined for iafa@services.bunyip.com); Wed, 10 Jan 96 17:43:43 -0500
Received: from central.surrey.ac.uk by mailb.surrey.ac.uk with SMTP (PP); Wed, 10 Jan 1996 21:02:30 +0000
Received: by central.surrey.ac.uk (1.37.109.8/16.2) id AA16368; Wed, 10 Jan 1996 21:02:27 GMT
Message-Id: <9601102102.AA16368@central.surrey.ac.uk>
Subject: Re: new iafa draft
To: Chris Weider <clw@bunyip.com>
Date: Wed, 10 Jan 1996 21:02:27 +0000
Cc: iafa@bunyip.com
In-Reply-To: <199601101539.KAA06467@kosh.bunyip.com> from "Chris Weider" at Jan 10, 96 10:39:05 am
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Thomas Krichel <T.Krichel@surrey.ac.uk>
Reply-To: Thomas Krichel <T.Krichel@surrey.ac.uk>
X-Org.: Department of Economics, University of Surrey, Guildford GU2 5XH, UK
X-Tel.: 44-(0)1483-300800x2785, Fax: 44-(0)1483-303775, Ethnic origin: Saarland
X-Mailer: ELM [version 2.4 PL24]
Mime-Version: 1.0
Content-Type: text/plain; charset="UK-ASCII"
Content-Transfer-Encoding: 8bit
Content-Length: 1464
X-Orig-Sender: owner-iafa@bunyip.com
Precedence: bulk

  Chris Weider writes:

> With some minor exceptions, you should be able to use IAFA templates as-is
> with the WHOIS++ servers that are extant.

  That is encouraging news. 

>  The whole metadata template work is still very much in flux, with not
>  much progress made last year. 

  One approach to resolve the problems with the current draft
  is to dump the concept of version to replace it by a part
  concept. A resource could be thought of as a collection of
  files that are related in some way. How they related to each
  other is difficult to express in  a template form. Thererfore
  one should list the parts, the format of each part and 
  a description of its functionality.

  For example, assume I present something about snowpeople. I would
  like to encode something like

  Abstract: This resource is about the sex life of snowpeople
  Part: Slides with main results in English
  Format: application/slideprocessor
  URL: snow.slide
  Part: Slides with main results in French
  Format: application/slideprocessor
  URL: neige.slide
  Format: application/video
  Part: Video of Snowpeople having sex, in French
  URL: sexedeneige.video
  Format: text/fortram
  Part: programme to compute increase in room temperature through
        sexual activity of snowpeople
  URL:  snowsextemper.for


  Thomas Krichel                               mailto:T.Krichel@surrey.ac.uk
                                  http://www.surrey.ac.uk/Economics/tkrichel

v2.23.0 | Report a Bug | By Email