Meta Folk,
The issue of Scheme specification is one of those detail devils we here
so much about. Its something we have to come to grips with, but its
hard to balance the need for simplicity (to promote the sort of rapid
adoption that is critical to achieving `market-presence') and the
precision necessary to support machine parsability and a coherent data
model.
Here are some possible approaches, gleaned from discussions with Jon
Knight, Paul Miller, and Eric Miller and others
Possible SCHEME schemes:
I. Discourage use of schemes for the time being
Rationale: One step at a time... if we promote a simple,
straightforward means of embedding metadata in HTML, then the
likelihood of adoption goes up.
A. PROS: 1. simple to understand
2. simple to parse
3. we have consensus now
B. CONS: 1. No means for specification of scheme, hence less coherence of
data and lower
likelihood for machine-parsable data
II. Dot.kludge approach:
<META NAME="DC.author.SCHEME.e-mail" CONTENT="[log in to unmask]">
Rationale: keep HTML pure
A. PROS: 1. Keeps HTML pure
2. allows unambiguous specification of scheme
B. CONS: 1. harder to parse automatically
2. SCHEMEs of any flavor will be hard to explain, and will thereby
impede adoption
III. Slip-in-a-SCHEME Kludge:
<META NAME="DC.author SCHEME=e-mail CONTENT="[log in to unmask]">
Rationale: It may not be strictly kosher HTML, but it won't really hurt,
and it allows a cleaner implementation of SCHEME
A. PROS: 1. easy to ignore SCHEME specifications for brain-dead robots
2. keeps SCHEME separate from NAMEd element types
B. CONS: 1. OK, OK... its broken HTML
2. No common consensus
3. SCHEMEs of any flavor will be hard to explain, and will thereby
impede adoption
4. may require counselling for HTML hardliners ;-)
IV. HTML-be-damned approach (Miller and Miller)
<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">
Rationale: HTML is still moving, and there is no one at the wheel
anyway... so lets do this right from the start.
A. PROS: 1. good foundation for a complete scheme specification;
some chance it may stand up to serious use
2. very flexible
B. CONS: 1. Breaks HTML validators big time
(there go Jon's counselling fees)
2. No consensus at this time
3. has the potential to become very complex (otherside of the
flexibility PRO coin).
|