Re: IAFA templates: a user's comment

[Martijn Koster <[e-mail]>]

Thomas,

Thanks for your comments, I'll see if I can reply to your points.

>   I think it is improper to use variant in that way,

You are absolutely right, the draft is giving conflicting advice.
Variants should describe variants of the resource, not variants
of field values.

Fortunately the 7.2 section offers a solution in Note 11:

| 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.

I'll see if I can go trough it and rectify this.

>   Another problem with the current version of the IAFA templates
>   is that there seems to be no provision for a document to be
>   contained in several parts. For example it occurs that authors
>   put in one PostScript file, but the graph in  a gif. Of course
>   they should not do it, but they do and I think we need to 
>   take account of that. Again, both the PostScript and the
>   gif are part of the same resource, one without the other
>   would not be the complete resource. 
> 
>   To solve this problem, I suggest to introduce part information
>   alongside variant information. Part information should be signaled
>   with -p<number>. I would then rewrite my example as:
>
>   [examples deleted]
> 
>   I would suggest to integrate this part syntax for the next update
>   of the templates. 

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.

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 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).

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.


> *** 2 
> 
>   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-Classifcation:
> 
>   field. That would allow me the write
> 
>   Subject-Classification: JEL A34, B7

Nothing is stopping you from writing that. The reason a particular
field is not specified in the draft is that you then get into the
problems of different classification schemes. It'd be far better to
have 'LOC-Classification', 'Dewey-Classification' etc. However, I'm
not qualified to make these recommendations/decisions as I' not a
librarian. In fact, I think that for it to be used correctly you'd need
extensive examples and specifications, which probably require a
separate document. After all, these issues are true for other encodings
than the IAFA templates as well.

> *** 3
> 
>   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, any more votes on this? I'm personally happy to see a standard
Description field accross all templates. It makes parsing and more
importantly presentation so much easier.

>   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. 

See my reply to point 2. Pricing is an even more contentious issue, as
prices may vary depending on who buys from where, by what means etc.
We don't want to turn a simple resource template into a marketing
brochure.

-- Martijn
__________
Internet: [e-mail]
X-400: C=GB; A= ; P=Nexor; O=Nexor; S=koster; I=M
X-500: c=GB@o=NEXOR Ltd@cn=Martijn Koster
WWW: http://web.nexor.co.uk/mak/mak.html