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

```

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

[[[

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

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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:07:38 UTC