W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > September 2001

Re: namedNode? in predicate position?

From: pat hayes <phayes@ai.uwf.edu>
Date: Fri, 7 Sep 2001 07:57:41 -0700
Message-Id: <v04210105b7be20624937@[]>
To: Graham Klyne <Graham.Klyne@Baltimore.com>
Cc: w3c-rdfcore-wg@w3.org
>At 12:13 PM 9/4/01 -0700, pat hayes wrote:
>>>I think that princeNodes should be allowed in the predicate 
>>>slot... they're rather useful.
>>>While I'm giving unsolicited advice, I think that a DLG is 
>>>probably not the best way to represent the RDF model... it's sort 
>>>of difficult to picture arrows pointing at other arrows.
>>If *that* is allowed then the M&S is totally screwed up. Is it 
>>legal RDF to have a property be the value of another property??

Whoops, I now see that I was confused here  ^^^^^^ and may have 
generated more confusion, sorry.

Dumb of me. Of *course* it is OK to have a property be a value of a 
property, and the MT can handle that fine; it's one of the things 
that the extension mapping handles for free. But that doesn't require 
one to write an arrow pointing to another arrow; it only requires 
using the same URI on a node as on an arrow.

An arrow pointing to another arrow would correspond to a property 
whose value was, not a property, but a single property instance, ie a 
single <s, o> pair, rather than a set of such pairs. And those I 
don't think we need (but if we did, then indeed the MT would need to 
be re-written.)

>This is something that I have found intuitively "easy" but difficult 
>to explain clearly.
>My intuition is that an arc is somehow associated with a property 
>node, but that different arcs with the same property label are still 
>different arcs.  (The programmer in me might say that an arc is an 
>instance of a type described by the property.)  But this is 
>inadequate as a formal explanation...

No, that is pretty good. A relational extension is a set (= class) of 
pairs, after all, and each arc is one of those pairs, so is an 
instance of the class, exactly. The MT account of this is that every 
URI denotes one 'thing'; but that when that thing is a property, it 
has an extension which is a set of pairs. Every time we write an URI 
on an arc we are saying that the pair of things whose names are at 
the ends of that arc is in the extension of the thing named by the 
URI. Since there can be many pairs in the extension of one property, 
its OK to write the same URI on many arcs. But to write the same URI 
on two *nodes* would be saying that the URI names two different 
things, which is silly.

>Turning to the MT document for guidance (28-Aug-01 draft, section 0, 
>penultimate para).  We have one node for each uriref, anonNode or 
>qLiteral in the document, and one edge for each triple.  But what 
>about the urirefs that are used to identify properties?  This seems 
>to be a problem with the description as given.

It is OK if you keep the property/extension distinction in mind.

>It seems to me that there is a difference in the treatment of URIs 
>used to label nodes and URIs used to label arcs, but I'm not sure 
>how that is formalized.  I used to think of reification as providing 
>a way to create an effect that might have a graph syntax of an arc 
>pointing to/from another arc.

I don't think you need to involve reification at all; but then I may 
just be completely confused about what RDF reification means.

>In any case, I think it's certainly possible to have the uri that 
>labels a property arc also be used to label a node that is the 
>subject and/or object of another property, which some might say is 
>"to have a property be the value of another property".

Yes, that is OK. No need to change the MT (or the graph syntax) to 
allow this. I will put a short note into the MT document to draw 
attention to this.

>So my points are:
>(1) I think the MT text about URIs in graphs may need refining.
>(2) My answer to your question is "maybe, yes".
>Should arcs be allowed to be "princeNodes"?
>I note that allowing property arcs to be "princeNodes" is not the 
>same as having ordinary nodes be princeNodes.  A URI denotes a node 
>resource, but it is an attribute of a property arc.  How does a 
>formalization capture this kind of distinction?

Not sure I follow that distinction. ("attribute" ?)

>I have also found that to describe RDF-schema-based inferences, I 
>have wanted to construct expressions in which the RDF property is a 
>"variable".  I think the required effect could be achieved by means 
>other than "princeNode" arcs, but maybe less intuitive for a 

Yes, others have noted this also. OK,  this also can be allowed in 
the syntax without changing the MT; but I think that if we do allow 
this then I ought to rewrite the model theory slightly, because as it 
stands right now its not  quite clear what this would mean. The MT 
uses a standard logical device to describe existentials, basically 
saying that the existential is true if there is some interpretation 
of what it denotes that makes the assertion true. The trouble with 
this trick for relations (properties) is, that the simple denotation 
of a property isn't really all that important: what makes assertions 
involving it true or false are the *extensions* of those denotations. 
So a lot turns on whether those extensions are allowed to change when 
the denotation of the anonymous node is allowed to change. The only 
way to interpret this that would produce a reasonable proof theory 
would be to take the extension mappings as fixed and let just the 
denotations vary; which is what the MT says right now, in fact, but 
it ought to say it much more clearly and explicitly, since a lot 
hangs on that point if we are going to allow princeProperties.

>(Hmmm... are we finding out why CGs use bipartite graphs rather than 
>labelled arcs?)

Maybe, but we can go with the more liberal syntax. CGs are based on a 
slightly more traditional logic which doesn't have explicit extension 
mappings and doesn't allow properties to apply to other properties.


(650)859 6569 w
(650)494 3973 h (until September)
Received on Friday, 7 September 2001 11:07:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:04 UTC