Paul Miller wrote:
> The issue that has been taxing our brains is that of the case used in
> element names, and a conflict between our approach in HTML and that emerging
> for an alternative solution via XML/RDF.
> As we saw it, there are a number of things that might be done, none of which
> is perfect for various reasons. These are;
(to paraphrase)
1) Encode DC in XML/RDF with leading capitals (which conflicts with
current practice in the XML community)
2) Encode DC always in lowercase, regardless of current practice in the
coding language community
3) Same as (2), but not retrospective
4) Make DC case insensitive, and leave implementation to coding language
communities
5) Do nothing
> What do you all think? (I *know* which one I prefer, but then I'm biased)
I'm concerned that you've limited your vision to the finite worlds of
HTML and XML. What about the next generation? What if I want to share a
coding scheme implemented in PERL?
Perhaps we can indicate that the names of the fields are, for example:
Dublin Core Document Title
Dublin Core Document Description
Dublin Core Rights Statement
Dublin Core Creator
Dublin Core Contributor
... and that the names should be encoded in a fasion that is consistent
with the vernacular for a particular coding language, eg the Dublin Core
Element Set could be described as:
"Element Descriptions
1.Title
The name given to the resource by the CREATOR or PUBLISHER.
2.Author or Creator
The person or organization primarily responsible for creating the
intellectual
content of the resource. For example, authors in the case of
written documents,
artists, photographers, or illustrators in the case of visual
resources.
3.Subject and Keywords
The topic of the resource. Typically, subject will be expressed as
keywords or
phrases that describe the subject or content of the resource. The
use of
controlled vocabularies and formal classification schemas is
encouraged.
...
Element Encodings
The Dublin Core elements are coded into a particular language using the
vernacular of that particular language. Standards have been set for XML
and HTML as follows:
Element XML/RDF label HTML name
Title dc:title DC.Title
Author or Creator dc:creator DC.Creator
Subject and Keywords dc:subject DC.Subject
..."
This would be similar to the layers used in other data communications
standards. Having a specific mapping for each language, that is distinct
from the names of the actual elements, means that we can apply the same
mapping system to implementations, rather than models.
For example:
Element Perl "DC" module
Title $document->{Title}
Author or Creator $document->{Creator}
Subject and Keywords $document->{Subject}
...
Prescribing an interface for implementations will allow interoperability
at the programmatic level, if not at the logical level.
So my vote is for (5). Since the current standards aren't broken, why
fix them?
Implementors who are converting from one representation standard to
another will just have to be aware that what is represented in HTML as
<META NAME="DC.Title" CONTENT="..."> must be converted to an entirely
different format in XML/RDF. It's not just a case of converting the name
from "DC.Title" to "dc:title" - you'll also be converting from EBCDIC or
ASCII to Unicode.
Regards
Alex
--
Alex Satrapa
tSA Consulting Group Pty Ltd.
Canberra, Australia
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|