Harry said:
> How does this benefit the DC? Why would we want multiple serializations of
> the namespaces?
Because an RDF/RDFS in XML representation is just one way of describing a
namespace?
It's a useful one (if you understand RDF/RDFS!), sure.... but not the only
one... we're also going to need human-readable descriptions and possibly other
+
machine-readable forms.
I think Chris Croome summed it up
http://www.jiscmail.ac.uk/cgi-bin/wa.exe?A2=ind0110&L=dc-
architecture&F=&S=&P=1795
> we should be doing all we can to make the semantic web
> understandable to people and one way in for people who don't know
> what things like RDF and XML are will no doubt be through pasting
> namespaces into browsers
I think the last bit meant pasting namespace _URIs_, but I think it hits the
nail on the head. People will use the namespace URIs not only as the means of
_identifying_ the DC namespaces but as means of _locating_ information about
the DC namespaces, most likely by feeding them to a browser and expecting to
receive something useful back.
I do it all the time when I encounter new namespaces...;-)
> Why do we need an XML namespace being that all of the DC
> elements are optional and repeatable?
Sorry, Harry, I don't understand this question! Did you mean an XML schema?
> We certaintly (IMHO) do not want or need multiple language versions of the
> namespaces.
I don't think you're arguing that we don't need descriptions of the DC
namespaces in multiple languages....?
Are you arguing against maintaining RDF/RDFS representations in different
languages?
I'm not sure, but I have a feeling this may very well be what is required. And
+
if it is, then we need ways of saying that the RDF/RDFS schema with content in
+
French/German/Korean etc is also a description of the same namespace as the
RDF/RDFS schema in English. Potentially at least, a mechanism like RDDL seems
to facilitate this.
> The language translations can be accomplished better other ways.
Could you expand on this please?
> I don't see a need for the namespace to resolve to a human-readable version
> either.
> It does have to resolve to a machine-readable version
It depends what you mean by "resolve", I think.... yes, it is necessary to be
able to _obtain_ a machine-readable representation using the namespace URI, but
+
as I think Aaron suggested at
http://www.jiscmail.ac.uk/cgi-bin/wa.exe?A2=ind0110&L=dc-
architecture&F=&S=&P=1681
some indirection (e.g. following a link encoded in RDDL) is much more
acceptable here than it is for obtaining the human-readable version. Perhaps
this is the core of the disagreement here?
> I can see how this benefits the RDDL community. I don't see how it benefits
> the DC.
It benefits DC by providing a choice: if the user uses the namespace URI as
a "locator" (which I think we all agree people will do), the RDDL (or
equivalent) option offers a "table of contents" from which the user can
_choose_ the representation of the namespace which is most useful to them in
_their_ context (which may be shaped by language, which machine-readable format
+
they want for their application etc), rather than having only one
representation (RDF/RDFS in XML - which may be incomprehensible to them)
available to them.
And as someone else (sorry, I can't find message to reference) pointed out,
that list of choices is extensible.
Without offering that choice, it certainly gives the _impression_, as Simon Cox
+
said
http://www.jiscmail.ac.uk/cgi-bin/wa.exe?A2=ind0110&L=dc-
architecture&F=&S=&P=1915
of tying DC into RDF/RDFS and of excluding the non-RDF reader/user/implementer.
+
That may not be the intention, but I fear it would look like that to the end
user!
Pete
|