On Tue, 6 Aug 1996, Stu Weibel wrote:
> Possible SCEME 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
I think we need Schemes (and Types). In ROADS for example we already have
multiple subject schemes in use (UDC, DDC, NLM) at different SBIGs, so
this is something that we have an a priori need for. We also need a way
of separating out authors' names, email addresses, snail mail addresses,
etc, etc. And the Relation DC element is pretty useless without the Type
subelement to tell you what the relation is. So I'd say that subelements
are vital (unless we do the IAFA thing of expanding the number of basic
elements so that we get DC.author-name, DC.author-email,
DC-author-postal-address, etc, etc which is not very inkeeping with the
KISS principle of 13 DC elements).
> 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
I don't think that this is any harder to parse automagically. Here's
what we can get in the NAME attribute of the META tag that's valid:
* No periods : Not done to the standard, take it at face value or ignore.
* Schema.Identifier : The basic standard approach outline in the
"Embedding Metadata in HTML 2.0" document. No problems with this if
you've no Scheme or Type information.
* Schema.Identifier.SCHEME.Schemename : Our new "kludge". If we see more
than one period in the NAME attribute we break up the attribute's value on
the second (and maybe fourth if both SCHEME and TYPE are there) periods.
The first dotted pair still hole the schema information, and the second
(and maybe third) dotted pairs hold our subelement information, with the
subelement type appearing first and the value second. It shouldn't be too
taxing to handle this programmatically (especially in Perl :-) ). And
its (trumpet fanfare) kosher HTML 2.0 (WebTech's HTML validation service
says so and I trust them :-) ).
I don't think that having a standard means of including SCHEME and TYPE
information will impede implementation as they are already optional. If
you don't understand them/don't need them then you can ignore them. For
those of us that do need them then they're there from the start in a nice
standard way that doesn't break your HTML.
> 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 ;-)
Hmm, well if we're going to ignnore the HTML 2.0 DTD then we might as
well go the whole hog and add new attributes for SCHEME and TYPE to the
META tag. That's what Tony's done in his home page. However I disagree
that it won't hurt: I like to validate my important HTML to make sure that
I'm obeying the standards that we sweat blood over and so I'd definately
need counselling to accept this one (as might the SGML die hards on meta2
:-) ). Our new metadata standards (that's what we're after right?)
should at least try to obey the established standards in the technologies
that they make use of.
So what to do now? Vote on it? Update the "Embedding metadata in HTML
2.0" document? Open to suggestions folks.
Tatty bye,
Jim'll
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Jon "Jim'll" Knight, Researcher, Sysop and General Dogsbody, Dept. Computer
Studies, Loughborough University of Technology, Leics., ENGLAND. LE11 3TU.
* I've found I now dream in Perl. More worryingly, I enjoy those dreams. *
|