W3C home > Mailing lists > Public > www-rdf-interest@w3.org > October 2001

Re: a new way of thinking about RDF and RDF Schema

From: Brian McBride <bwm@hplb.hpl.hp.com>
Date: Sun, 21 Oct 2001 18:23:05 +0100
Message-ID: <3BD30479.7090707@hplb.hpl.hp.com>
To: "Peter F. Patel-Schneider" <pfps@research.bell-labs.com>
CC: www-rdf-interest@w3.org, simeon@research.bell-labs.com

Peter F. Patel-Schneider wrote:


>>theory in that style.  The resulting RDF model theory is necessarily more 
>>complicated than one for a graph or triple based syntax, since in effect, the 
>>model theory has an RDF parser built into it.  :(
> I'm not sure what you are getting at here.  

Where a model theory based on a graph as syntax can say:

(****ing BT:  I'm offline can't quote the exact words)

   IS : node -> IR       # i.e. there is a simple function from nodes to
                           the things they denote

this model theory has in section 4


for each n in N an element node,
	    M(n) in IR  and  M(n) in CEXT(IS(name(n)))
	    if n has an attribute with name rdf:ID and string-value u
	       then M(n) = IS(UTS(u))
	    if n has an attribute with name rdf:about and string-value u
	       then M(n) = IS(UTS(u))
	    if n has an attribute with name rdf:resource and string-value u
	       < M(n), IS(UTS(u)) > in EXT
	    for each element, attribute, or text node child, n', of n
		     except for attribute nodes with name
		     rdf:ID, rdf:about, rdf:resource, or xsi:type
		< M(n) , M(n') > in EXT
	    if n has a simple type, d
	       then for each child, n', of n that is a text node
		    M(n') = DTS(d)(string-value(n'))

which struck me rather as representing information normally handled in an RDF 
parser, in the model theory itself.

> However, one of the things that I am trying to do here is to eliminate the
> need for an RDF parser.  Parsers take some surface syntax (usually a linear
> sequence of bits) and produce an abstract syntax structure.  Pat uses a
> graph as his abstract syntax structure.  I am using the XQuery 1.0 Data
> Model (well, actually a forest of fragments in that data model) as my
> abstract syntax structure.

Right, but then one has to do the work normally handled by the parser, to 
interpret the XQuery data model as RDF.  There ain't no free lunch.

> One very big (at least to my mind) advantage of my approach is that there
> are (or soon will be) programs that produce my abstract syntax
> structures from arbitrary XML. 

Most RDF parsers are built on a standard XML parser.  This is true of SiRPAC, 
RDFFilter, ARP and Redland's parser.


>>Your ML compiler should have issued a warning here.  This does not cover all the 
>>cases; bnodes are not handled, i.e. what do you do about nodes with no ID, about 
>>or resource attribute.  
> Nodes with no rdf:ID or rdf:about are handled fine.  There is just no
> restriction on M(n) corresponding to the rdf:ID or rdf:about, i.e., they
> are anonymous nodes.  

ok.  I'm struggling to get my head around this way of looking at it.  I was 
going to say that surely there must be a restriction that different anonymous 
nodes map to different resources.  But that is not true of anonymous typed 
nodes.  It seems it ought to be true of property element nodes though.

> Element nodes that have an rdf:resource are also
> anonymous.

Yes.  That's neat.

> Not needed.  In fact, there is no way that you can ``generate'' anything in
> the interpretation.  Interpretations were lying around even before anyone
> thought of RDF or XML or the web or even mathematics.  (Yes, I know I am
> treading perilously close to philosophy here.  :-)  The model theory just
> says that some interpretations are useful in that they correspond to
> (provide models for) certain data sets.  Further, model theory is (or at
> least is supposed to be) functional.  Side effects should be avoided like
> the plague.

Quite.  I'm not very familiar with that way of thinking, hence the lapse into 
procedural language.


>>So let me add a third.  I don't see where you are handling typed nodes; e.g. the 
>>first element above should add:
>>    g = G()
>>   <G(), g>
>>   <rdf:type, g>
>>   <g, a:b>
>>to IEXT.  But one can't add these for all <a:b> elements, only those that are 
>>typed nodes in the grammar.  This is a case where striping must be handled.
> I can't find information on what striping is so I can't address this part
> of the issue.

An ancilliary comment.  Ignore it.

> It is certainly the case that you need to link the nodes to their ``type''
> through an rdf:type resource.  
> This can be done by via
> 	IS >= { <a:b,a>, <rdf:type,t> }
> 	CEXT >= { <a,{x}>, <t,{y,z}> }
> 	IEXT >= { <x,x>,	# link node with ``type'' a:b back to itself
> 	          <x,y>,<y,a>,	# link node with ``type'' a:b to a:b 
> 		  <y,z>,<z,t>,	# give the link a type of rdf:type
> 		  <z,z> }	# provide a ``recursive'' typing for the link
> My revised message gives a larger example of this.

Yes it does.  My point was that any model of RDF/XML with a typed node must have 
this stuff and I couldn't figure out where that constraint was specified.


> <rdf:Description rdf:type="a:b"/> is not valid RDF because a:b is not a
> literal, not (just) because QNames are not allowed as attrib values. 

This is a nit, but the rdf:type attribute is a special case in RDF.  The value 
of the attribute is the URI of a resource, not a literal.  You may wish to add 
that to your list of mistakes in RDF.


> What do you loose?  Well you do loose 
> 1/ rdf:parseType (unrecoverable),
> 2/ part of the difference between classes and properties,
> 3/ bagID, 
> 4/ the strange use of rdf:ID on property elements (unrecoverable),
> 5/ the strange part of the second syntax abbreviation (unrecoverable), 
> 6/ the special treatment of rdf:li, 
> 7/ aboutEach, 
> 8/ and the type and number restrictions on statements.
> I maintain that most of the above are mistakes in RDF.  (Some of them are not handled in
> Pat's model theory.  Some of them are causing controversy in the RDF Core WG.)

Losing all that though, puts it beyond anything RDFCore can use within its 
current charter.

Received on Sunday, 21 October 2001 13:29:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:44:32 UTC