Re: Referring to resources in RDF attributes

Brian McBride wrote:
> 
> 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?

"Brick walls are the only rules; the rest are just suggestions."

And actually, in this case, I don't see any brick walls.

So we have a whole range of options.

I lean toward the conservative end: if

	-- somebody out there is relying on some aspect of the language
	in practice (or: our best guess is that someone does)

	-- that aspect of the language is something you can
	get from a not-to-warped interpreation of the spec

then we don't change that aspect of the language without
chaning the namespace name.

Hmm... that suggests something W3C could usefully add
to its process: during CR, tell folks that if they're
relying on some feature, they should notify W3C that
they rely on it; in return, the WG agrees to notify
them of any intent to remove/change that feature.

>   o what are our goals for backward compatibility?

Mine are, in order:

1. to make it straightforward to deploy RDF stuff
(tools, software, layered apps, understanding) in the future,
but

2. to preserve the investment of folks that are
using RDF today.

Where these goals conflict, I lean towards #1, since
the future is longer than the past.

> 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.

Yes; each of us has agreed to participate per the charter,
which says, among other things:

[[[
Backwards compatibility with existing RDF applications is a
priority for the RDF Core Working Group.
]]]

--        W3C Semantic Web: RDF Core Working Group Charter
http://www.w3.org/2001/sw/RDFCoreWGCharter
Wed, 28 Mar 2001 14:11:33 GMT


> 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.

Yes, that's a coherent design.

I find it very unappealing; in particular, I can't specify
it using XML Schema, and I can't think of a straightforward
way to deal with it in XSLT (of course, XSLT is turing-complete,
so it can be done somehow.)

Plus, this problem you see is unacceptable to me:

> 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.

yes.

> 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.

Yes, that's a very creative way to mix in new stuff while
not being flat-out-inconsistent with old stuff.

But this is the sort of thing that's going to make it *harder*,
not easier, to deploy RDF stuff in the future. So I'm not
a fan of stuff this contorted.


> 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.

But the existing RDF namespace name does *not*
start with http://www.w3.org/TR/REC-rdf-syntax .

So I don't get your point here.

> 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?

Certainly: you just made such a case.

Is it persuasive? yes, I think so.

> This message isn't really about Qname attributes.  Its about what our
> goals
> are for backward compatibility.

[Really? Then change the subject line, please.]

>  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.

Yes, but let's be careful...
if we have 4 alternatives proposals for
mixing aboutQ into RDF 1.0 syntax, and we use the
same name for all of them, chaos reigns. It's straightfoward
to make 4 "copies" of RDF 1.0 syntax and hack on them
independently, and then decide to replace RDF 1.0 syntax
with one of them after we've compared/constrasted them.

-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/

Received on Monday, 23 April 2001 10:22:30 UTC