[log in to unmask] wrote:
> I'm concerned about this whole business of "guerrilla DC". I don't know how
> enforceable this whole thing is, but it seems to me to be unacceptable to
> have specialist groups unilaterally appropriating the DC prefix.
I am concerned about some issues relating to this as well.
Issue 1
-------
I am myself working on an implemention that uses DC 1.0 as a metadata "core".
I also need to be able to add some bits that are specific to my application
(the application is to be used by an entity I consult for, which is a company
called "FAST Search anf Transfer).
The solution I've adopted is to use the "DC/dc" prefix for strict DC
elements, and the prefix "FAST/fast" for application specific elements.
I don't see any problem mixing the two, so I have records like the
following.
In XML/RDF:
<?xml version="1.0"?>
<rdf:RDF
xmlns:rdf="http://www.w3.org/TR/REC-rdf-syntax#"
xmlns:dc="http://purl.org/dc/elements/1.0/"
xmlns:fast="http://www.ifi.uio.no/~gisle/fast/meta.html">
<Description xml:lang="en" rdf:about="ftp://ftp.server.edu/bobbas12.zip">
<dc:creator>Bob Smith</DC:Creator>
<fast:proglanguage>Java</FAST:Proglanguage>
</Description>
</RDF>
Add in HTML:
<LINK rel="schema.DC" href="http://purl.org/dc/elements/1.0/">
<LINK rel="schema.FAST" href="
http://www.ifi.uio.no/~gisle/fast/meta.html">
<META NAME="DC.Creator" CONTENT="Bob Smith">
<META NAME="FAST.Proglanguage" CONTENT="Java">
Personally, I think this is reasonable.
Comments?
Issue 2
-------
However -- I have had comments from other participants in the metadata
community who believe that it is _preferable_ to extend DC using
element qualifiers (type) instread of creating a separate namespace.
For exempel, we have an property to deal with version numbers, named
"FAST.Version" (in HTML). Some has written to me and suggested that I
instead create a DC.Date subclass (e.g. "DC.Date.Version") for this
purpose.
I would like to hear the arguments (pro et contra) of:
- using a dicrete namespace (FAST.Version), vs.
- extending DC (DC.Date.Version)
Issue 3
-------
In both XML and in HTML namespaces are qualified (by the "xmlns"
declaration in XML and the "LINK" relationship in HTML).
Currently, I believe that the following is a perfectly valid
start of an XML/RDF file:
?xml version="1.0"?>
<rdf:RDF
xmlns:rdf="http://www.w3.org/TR/REC-rdf-syntax#"
xmlns:dc="http://my.site.com/my-dc.html"
[etc...]
What it does is to dfine a prefix choosen at random (I just happened
to choose "dc" :-) and to state that this prefix is to be
associated with the precise namespace defined by the URI
"http://my.site.com/my-dc.html", (which has nothing whatsoever to do
with the "Dublin Core").
In _theory_ -- this may be fine. The idea is that whatever software
it is that processes this record, it would just have to resolve the
URI, look up the machine readable description of the syntax and
semantics for the qualified namespace, and from there onwards do "the
right thing"[tm].
In _practice_ this will not work. There is (AFAIK) no way to capture
the rich semantics of something like the DC in something machine
readable. So implementors will train their software to recognize
the "dc" prefix declaration and to ignore the contents of the URI
the declaration points to. They can only hope that whatever is
in the file pointed to by the URI is congurent with whatever they
have already hardcoded into their software (which it will be as
long as nobody uses the "dc" for something else out of ignorance
or because they enjoy looking at the fallout).
I don't think we can ignore the practical side of things.
Consequently, we need a registry (e.g. IANA) where one can register
different RDF/XML namespaces. Anyone picking a prefix can then
at least check the registry to see that the one they fancy os
available.
--
- gisle hannemyr ( [log in to unmask] - http://home.sol.no/home/gisle/ )
------------------------------------------------------------------------
"Use the Source, Luke. Use the Source." -- apologies to Obi-Wan Kenobi
------------------------------------------------------------------------
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|