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

Re: comments on rdf-a

From: Pat Hayes <phayes@ihmc.us>
Date: Tue, 23 Nov 2004 09:09:53 -0600
Message-Id: <p06001f0cbdc9031d2be0@[10.100.0.4]>
To: Jeremy Carroll <jjc@hplb.hpl.hp.com>
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.

Actually I agree, on reflection. That makes much more sense.

>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


-- 
---------------------------------------------------------------------
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 Tuesday, 23 November 2004 15:09:19 GMT

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