xml-dev - RDF and Dereferencing

[David Megginson <david@megginson.com>]

Sean B. Palmer writes:

 > BTW, Paul: You cannot say that namespaces shouldn't be dereferenced: that
 > would make RDF useless overnight. But on the othr hand, you cannot say that
 > everything shoyuld be dereferenced: that would be absurd!

Actually, it would cause problems only for RDF schemas.  RDF model and
syntax without schemas does not need Namespace dereferencing, though
it does mention it.

Some RDF people want to do something similar with the URIs that act as
resource identifiers (they look and act a lot like Namespace-qualified
names, but technically, they are not), but I believe that is very bad
practice.

Consider the following: ACME News wants to publish some information
about XML, so they publish it like this:

  <rdf:Description>
    <dc:title>XML</dc:title>
    <dc:description>
      The Extensible Markup Language, a specification created
      by the World Wide Web Consortium, based on SGML.
    </dc:description>
    <dc:category rdf:resource="http://acmenews.com/categories/computing"/>
    <dc:category rdf:resource="http://acmenews.com/categories/markup"/>
    <dc:category rdf:resource="http://acmenews.com/categories/web"/>
  </rdf:Description>

Now, the easiest way to identify this (a way used in some of the RDF
spec examples) is to use a local identifier, like this

  <rdf:Description rdf:ID="xml">
   ...
  </rdf:Description>

If the RDF document containing the information were located at

  http://www.acmenews.com/topics

then the full identifier would be

  http://www.acmenews.com/topics#xml

It seems to have a nice symmetry at first -- if any RDF document
refers to the resource http://www.acmenews.com/topics#xml, a processor
can simply dereference the identifier, parse the RDF document, and get
some information about it.

This approach is entirely unsuitable, however, because we want a Web
where *lots* of people can say things about XML, not just ACME News,
and where everyone talking about XML can (if they wish) use the *same*
identifier, which plays a role equivalent to that of a primary key in
databases.

Now, imagine a different approach.  ACME news creates an identifier
for XML

  http://acmenews.com/topics/xml

and because ACME news did it first and is fairly well-known (and
published their identifiers), other people find it convenient to use
the same identifier so that users and search engines can
cross-reference the information.  Now, even though ACME News was the
first to create an identifier for XML, everyone can talk about it
without assuming that ACME news's information has any kind of primacy.

For example, xmlrules.com might have

  <rdf:Description rdf:about="http://acmenews.com/topics/xml">
   <dc:title>XML</dc:title>
   <dc:description>
    The answer to war, disease, and world hunger, XML enables
    instant communication among all peoples, bringing about a
    siblinghood of man.
   </dc:description>   
  </rdf:Description>

and xmlsucks.com might have

  <rdf:Description rdf:about="http://acmenews.com/topics/xml">
   <dc:title>XML</dc:title>
   <dc:description>
    Another pathetic attempt to impose order and authority on the
    free market of ideas that is the Web, probably backed by
    Microsoft or the Rand Corporation.
   </dc:description>
  </rdf:Description>

Someone buying news stories from ACMENews.com (or other providers who
use ACME's identifiers) can use the topic identifier in the story to
look up background information on XML from a variety of sources, not
just from ACME itself.

After all, who's to say that ACME News's apparently neutral
description is any better than the apprently biased ones at
xmlrules.com or xmlsucks.com?  Should each have been forced to use a
different identifier for the same thing?  Should the party that
invents the identifier automatically have precedence in the
definition?

If RDF were intended only for providing metadata about Web pages, then
an approach like this would probably work; but in that case, we
wouldn't really need RDF to begin with (a little clever meta-tag
manipulation would be as much as most users could handle).


All the best,


David

-- 
David Megginson                 david@megginson.com
           http://www.megginson.com/