As Aaron and many others pointed out: One URI can serve several purposes.
One is: They imply other URI's
xmlns:dc="http://purl.org/dc/elements/1.1/"
automatically from the specification gives
"http://purl.org/dc/elements/1.1/title"
when we use dc:title in an RDF/XML record.
That's how it is.
The current resolving (redirect) of "http://purl.org/dc/elements/1.1/" is to
"http://dublincore.org/2001/08/14/dces#" .
I don't think "/ #" substitution is dictated by the definition of "purl" - or?.
The consequence of the seemingly innocent change "/" to a "#" at the end, is that we retrieve always the same object:
Regardless whether we call the namespace URI or "http://purl.org/dc/elements/1.1/title" -
In case i'm right about purl resolving, there is a plethora of things we could discuss under the header "to what resolves..."
Anyhow: An RDF Parser should get from the the result of retrieval of "http://purl.org/dc/elements/1.1/" at minimum what it
get's right now about dc15. [Analogously for terms and types and ....].
-------------
RDDL: My understanding of http://www.openhealth.org/RDDL/rddl.rdfs# [1] is, that RDDL has a preferred interpretation in RDF.
This is impression is supported further by http://www.openhealth.org/RDDL/rddl2rdf.xsl [2]
This causes a problem thanks to substantial semantic overlap of RDDL with DublinCore - recognizable for a human.
On the other side form the viewpoint of an RDF application taking [2] into account,
RDDL currently appears as a metadata language unrelated to DublinCore.
[1] and [2] are declared by http://www.openhealth.org as non-normative examples. I have no idea what a non-normative example
possibly could be.
It would be desirable for a metadata registry to provide machine understandable relations -
I'm not sure about whether the DC-registry people have considered this kind of issue.
I think it's a fairly real one - as this kind of behaviour RDDL shares with some other metadata languages with preferred
mapping to RDF.
---------
Cheers
rs
