On Tue, 6 Aug 1996, Stu Weibel wrote:
> > So what to do now? Vote on it? Update the "Embedding metadata in HTML
> > 2.0" document? Open to suggestions folks.
>
> I'd like to see the list of alternatives fleshed out further and then
> put together a formal position paper with recommendations.
OK... seems like a good idea. Here's a first stab at one person's (me!)
interpretation of the options. Needless to say, my vote currently goes to
the scheme as proposed for the ADS (option 1). If it seems useful, I can
distill a version of this message onto a Web page and add other people's
suggestions as they come in... That way we all end up referring to the
same list of possibilities.
Right, here goes (lifting quite a lot more or less straight out of
earlier messages today)...
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
Discussion: Proposed implementation for the UK's Archaeological Data
Service (ADS). This format is clear and easily understood by the reader.
It also (usefully) makes full use of the LINK tag to provide the
necessary meta-metadata. After all, WE might know what ISO31 is, but if a
major aim of DC is to open metadata to wider appeal, how many potential
USERS will...?
Pros: readable
provides EXPLICIT links to any relevant schemes used in the
object description
Cons: Breaks HTML validators
Quite wordy
OPTION 2
--------
Don't use SCHEMEs at all for now
Discussion: One step at a time... if we promote a simple,
straightforward means of embedding metadata in HTML, then the likelihood
of adoption goes up.
Pros: simple to understand
simple to parse
consensus on style already exists
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
OPTION 3
--------
Example:
<META NAME="DC.author.SCHEME.e-mail" CONTENT="[log in to unmask]">
Discussion: Arguably inelegant, but it keeps the HTML pure.
Pros: Pure HTML
unambiguous SCHEME specification
Cons: Difficult to parse automatically
Hard to explain the SCHEMEs to the reader
OPTION 4
--------
Example:
<META NAME="DC.author SCHEME=e-mail CONTENT="[log in to unmask]">
Documented at: http://purl.oclc.org/net/eric/publications/metadata/issues.html
Discussion: Introduces the SCHEME element more cleanly than OPTION 3, but
breaks HTML rules
Pros: SCHEME element can be ignored by simple robots
keeps SCHEME and NAME separate
Cons: Bad HTML
No consensus
Hard to explain the SCHEMEs to the reader
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?
Anyone want to add others, or modify the list above in any way?
Paul
/======================================================================\
| Paul Miller |
| Graphics & GIS Advisor, University Computing Service |
| University of Newcastle, Claremont Tower, Claremont Road, Newcastle |
| upon Tyne NE1 7RU. tel (0191) 222 8212/8039, fax (0191) 222 8765 |
| |
| e-mail [log in to unmask] WWW http://www.ncl.ac.uk/~napm1/ |
| [log in to unmask] http://www.ncl.ac.uk/~ngraphic/ |
\======================================================================/
|