Thus spoke Paul Miller (at least at 05:08 PM 8/6/96 +0100)
>Here's a first stab at one person's (me!)
>interpretation of the options.
Thanks for starting this. A couple of comments/questions...
Editorial Comments -
You might add a short narrative to each of the options explaining their
key features, then give the example. The discussion of good and bad
points is useful.
You need to add some material at the top on just what "schemes" and
"types" are, and why we should try to accomodate them.
> OPTION 1
> --------
>
>Example:
>
> <META NAME = "DC.date"
> TYPE = "creation"
> SCHEME = "ISO31"
> CONTENT = "1996-06-17">
> <LINK REL = SCHEMA.dc HREF =
> "http://purl.org/metadata/dublin_core_elements#date">
> <LINK REL = SCHEMA.iso31 REFERENCE =
> "ISO 31-1:1992 Quantities & units -- Part 1: space & time">
>
>Documented at: http://www.ncl.ac.uk/~napm1/ads/metadata.html
Can you change this example to remove the #date from the SCHEMA.DC <LINK>?
> OPTION 2
> --------
>
>Don't use SCHEMEs at all for now
>
[...]
>Cons: Less coherence in descriptions
> Difficulty for user in interpreting metadata
> Less likelihood of data being machine-parsable
> Impossible (or extremely difficult) to include the important meta-metadata
An additional "con" is that it doesn't meet needs of systems currently
under development, such as ROADS.
> OPTION 4
> --------
>
>Example:
>
><META NAME="DC.author SCHEME=e-mail CONTENT="[log in to unmask]">
I'm not clear on how this proposal differs from Option 1. The LINK
element is not shown, but I thought that was part of Eric's work.
Also, you are missing a closing " after DC.author, unless this proposal
is really supposed to be NAME="DC.author SCHEME=e-mail" (i.e. space as
the delimiter). Of course, that approach has such strong cons that I
don't think it was what you were proposing.
> OPTION 5
> --------
>
>Example:
>
><META NAME="DC.author(e-mail)" CONTENT="[log in to unmask]">
>
>Documented at: http://purl.oclc.org/net/eric/publications/metadata/minimal.html
>
>Discussion: the syntax suggested at Warwick, I believe...
>
>Pros: HTML compliant
>
>Cons: Difficult for user to interpret?
This option also uses ':' as the delimiter for type information, which
should be mentioned. One of the standard objections to such an approach is
the potential for conflict when the field name contains one of the reserved
characters, so that should be added to the cons list.
Regards,
Ron Daniel Jr. email: [log in to unmask]
Advanced Computing Lab voice: +1 505 665 0597
MS B287 fax: +1 505 665 4939
Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/
Los Alamos, NM, USA 87545 tautology:"Conformity is very popular"
|