Re: Referring to resources in RDF attributes

Hi Dan,

Dan Connolly wrote:

> > Changing the namespace is a significant step.  Is there any way to
> > avoid that?
> 
> Of course: just make no changes to the language.

I'd like to make our assumptions/arguments explicit here.  I have two
questions:

  o what changes can we make without changing the namespace URI?

  o what are our goals for backward compatibility?

If we change the namespace URI, then old processors will not be able
process any rdf 1.1 data.  Maybe that will turn out to be unavoidable,
but shouldn't we look for more backward compatible solutions.

Lets take Graham's Qname issue as an example.  You rightly point out
that one can't tell the difference between a Qname and URI by just
examining the syntax.  But that doesn't by itself mean that nothing can
be done.

We could say that given xxx:yyyyyyyyyyyyy as an attribute value, then if
the xxx matches a namespace prefix decalared in the document and the
YYY... conforms to localname syntax, then this attribute value will be
interpreted as a Qname.

The main problem I see with this is backward compatibility.  An old RDF
processor would process say:

  <rdf:Description rdf:about="rdf:Class">
   ...

incorrectly.  It would be better if old processors barfed when
processing constructs defined in RDF 1.1 rather than processing them
incorrectly.

We could define a new namespace and use new attributes such as aboutQ in
that, but that has the problem that old processors will fail on new
data, even if they could have processed it correctly, e.g:

  <rdf:Decription rdf:about="#foo">
  ...

will fail if the rdf prefix is associated with a new namespace uri.

Another approach would be to put the new attributes in a new namespace
and leave the old ones alone:

  <rdf:Description rdf1:aboutQ="rdf:Class">
    ...

The problem with this approach is that an old processor will process it
incorrectly.  It will regard the rdf1:aboutQ as a property of an
anonymous resource.  Which is maybe not so terrible.

Another approach would be to add the aboutQ to the existing RDF
namespace.  This would have the advantage that processors which check
that they recognise names in the RDF namespace would barf.  From M&S:

  When an RDF processor encounters an XML element or attribute name
  that is declared to be from a namespace whose name begins with the
  string "http://www.w3.org/TR/REC-rdf-syntax" and the processor does
  not recognize the semantics of that name then the processor is
  required to skip (i.e., generate no tuples for) the entire XML
  element, including its content, whose name is unrecognized or that
  has an attribute whose name is unrecognized.

One would hope that the processor would not do this silently.  RDFFilter
barfs on the whole file.  I'm not sure what other processors do.

This last approach does mean adding a term to the RDF namespace.  The
M&S document makes no promises about not extending the namespace.  RDFS
does recommend that *schemas* should not be changed - new ones should be
created.  The motivation for this is to prevent existing things
breaking.

Could a case be made here that adding aboutQ to the RDF namespace would
give us better backward compatibility properties than creating it in a
new namespace?

This message isn't really about Qname attributes.  Its about what our
goals
are for backward compatibility.  The harm that creating a new namespace
as
a working hypothesis might do, is that we might not try as hard as we
should
not to need it.


Brian

Received on Monday, 23 April 2001 03:16:34 UTC