comments on rdf-a

(From a message sent to Dan Connolly, commenting on 
http://www.formsplayer.com/notes/rdf-a.html  Ralph Swick asked me to 
re-post them to the archive. Quick reaction after a quick read. 
_Pat.)

This does indeed look very nice, though I find 'rev' too close to 
'ref' for comfort (the two keys are even adjacent on the keyboard, 
guys. Have a heart for us ex-hunt-and-peckers. "backref", maybe?), 
and I still don't understand the distinction between <link> and 
<meta> or why it is needed.  Also I can't help smiling at section 
5.1.2, which quite casually re-invents the (bnode+properties) design 
that the WG rejected for handling typed literals, as though it were 
the most natural thing in the world (which of course it is :-)

One (big) issue I would raise however concerns the use of blank 
nodes, as illustrated in the 'note' at the end of section 3.2.  This 
is awful. The text immediately before it says that the metadata has 
been attached to the blockquote, but this is completely misleading. 
It hasn't been attached to anything: there is no way to get from the 
metadata to what it is about. (Just being located at the same place 
in the document does not constitute attachment!! )

This seems to almost never be a useful thing to do. In the example, 
surely the real subject of those triples should be the blockquote in 
the document.  Reducing this to a mere bnode emasculates the RDF, and 
severs its connection to its real subject; which I would have thought 
was the entire point of having the RDF markup in any case. Knowing 
that a quote from Dostoevsky *exists* tell us nothing we didn't 
already know; knowing that there is such a quote to found at a 
particular place in the document does. (This reminds me of the 
philosophical warning signs one sees on interstates in New Mexico: 
"Gusty winds may exist" which are fine as long as you don't move them 
away from the place where the winds are.) In Margaret's case 
[http://www.carmapro.com/vadirectory.htm] I know that she will want 
to be able to get back from the RDF to her pictures, so that she can 
use it (the RDF) to write 'smart' searchers. Bnodes just won't hack 
it.

Suggestion: ALL triples which are generated from qualifying 
information in the document are about an object in the document, and 
should somehow record that they are. To achieve this, any qualifying 
statement creates an XML id of its parent element, according to some 
fixed scheme (if it doesnt already have one) and then the triple uses 
that as subject. The scheme might be for example a kind of unique 
hashcoding, or something like "link_nnn' where nnn is some arbitrary 
numbering scheme (I'd suggest not restricted to be in document order 
:-).

I guess having XML objects create or modify others goes against the 
spirit of XML as a state-free markup language and not a programming 
language. Sigh.  Still, if this is a fatal objection, then just put 
the unique IDs in the RDF triples. This is no more onerous than the 
idea of a unique anonymous ID, but it is a lot more use in practice. 
They will at least identify the document and say, in effect 
'something in here is the subject' rather than just 'a subject 
exists'. And then practical editing/composing tools will almost 
certainly nag at their users to fill in 'unknown' xmlIDs with real 
IDs that are some actual use, or (the one I would buy) will just 
insert them in to the XHTML being composed automatically.

At any rate, I'd suggest that the document emphasize the use of 
id="q1" style subject specification before it goes on about bnodes, 
eg when introducing qualifying statements in section 3.2 .  Right now 
it gives the unfortunate impression that bnodes are the norm. I would 
have the text point out explicitly that markup with bnodes in it is 
(a) not likely to be much practical use and (b) can be generated by 
any competent RDF reasoner from the same RDF with genuine URIrefs in 
the subject position; so its almost never better to use bnodes in 
real markup.

Pat

-- 
---------------------------------------------------------------------
IHMC		(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32502			(850)291 0667    cell
phayes@ihmc.us       http://www.ihmc.us/users/phayes

Received on Friday, 19 November 2004 22:26:18 UTC