Re: new iafa draft

Thomas Krichel <T.Krichel@surrey.ac.uk> Fri, 12 January 1996 00:16 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09021; 11 Jan 96 19:16 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09017; 11 Jan 96 19:16 EST
Received: from services.Bunyip.COM by CNRI.Reston.VA.US id aa17625; 11 Jan 96 19:16 EST
Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id TAA10903 for iafa-out; Thu, 11 Jan 1996 19:14: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 TAA10896 for <iafa@services.bunyip.com>; Thu, 11 Jan 1996 19:14:21 -0500
Received: from mailb.surrey.ac.uk by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA09438 (mail destined for iafa@services.bunyip.com); Thu, 11 Jan 96 19:12:12 -0500
Received: from central.surrey.ac.uk by mailb.surrey.ac.uk with SMTP (PP); Fri, 12 Jan 1996 00:12:09 +0000
Received: by central.surrey.ac.uk (1.37.109.8/16.2) id AA06971; Fri, 12 Jan 1996 00:12:06 GMT
Message-Id: <9601120012.AA06971@central.surrey.ac.uk>
Subject: Re: new iafa draft
To: Jon Knight <J.P.Knight@lut.ac.uk>
Date: Fri, 12 Jan 1996 00:12:05 +0000
Cc: iafa@bunyip.com
In-Reply-To: <Pine.SUN.3.91.960111145424.24234U-100000@weeble.lut.ac.uk> from "Jon Knight" at Jan 11, 96 03:01:06 pm
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: 2312
X-Orig-Sender: owner-iafa@bunyip.com
Precedence: bulk


  Jon "Jim'll" Knight writes:

> I think if we're going to get rid of variants (I assume that's what you 
> mean by version) then we might as well go the whole hog and have proper 
> heirarchical templates rather than a single flat file.

  Yes, that is a good point, but we do not have a resolution service
  for these templates yet. If the current effort to collect metadata
  using the current templates  has any meaning---I guess it does have
  some, otherwise we would not worry about it---the flat templates
  can be reasonably used to describe a resource, be it imprecise.

>  And once you've done that, its but a short step to SGML style markup...

  The problem that I forecast for the SGML is that it might be too difficult
  for the average archive provider to provide the info. 
  
> >   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
> 
> How do you associate the URL and Format (and I guess other "variant" 
> style information) to the part name?  They don't seem to be in any 
> particular order and there's now no variant number holding the bits 
> together even if they're spread throughout the template.
 
  Yes, I guess it would be better to have such numbers. I left
  them out since I believed paf did not accept them. They could
  easily be introduced. Note that although the example is not 
  regular in the order, it neverthess gets an ordering across.

  Incidently when the URI group was split I read that Stu Weibel was
  charged with administering a group that would look into metadata
  encoding. Later I read from Stu that he simply wanted to make a 
  draft. Does anybody know what became out of that? 



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