W3C home > Mailing lists > Public > public-rdf-in-xhtml-tf@w3.org > November 2004

Re: comments on rdf-a

From: Jeremy Carroll <jjc@hplb.hpl.hp.com>
Date: Tue, 23 Nov 2004 09:27:33 +0000
Message-ID: <41A30285.6000009@hplb.hpl.hp.com>
To: Pat Hayes <phayes@ihmc.us>
Cc: public-rdf-in-xhtml-tf@w3.org


I think I prefer an approach where a missing subject is filled in from 
as far up the XML tree as you  have to go.

This would mean that any statement is about whatever part of the XHTML 
document that is identified.

Concerning Pat's comments:
Any use of bnodes should either:
- be deliberately marked by the author through the nodeID attribute
- associate the bnodes with some resource that is identified in the 
XHTML document

More in a bit ...

Jeremy




Pat Hayes wrote:
> 
> (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
> 
Received on Tuesday, 23 November 2004 09:28:16 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:14:59 GMT