W3C home > Mailing lists > Public > www-rdf-logic@w3.org > May 2001

Re: Predicates and Arcs vs Triples RE: use/mention and reification: rdf:predicate/subject/object

From: pat hayes <phayes@ai.uwf.edu>
Date: Thu, 31 May 2001 11:05:44 -0500
Message-Id: <v04210119b73c171f2a4c@[]>
To: Graham Klyne <GK@ninebynine.org>
Cc: www-rdf-logic@w3.org
>I've been mulling your response, on and off, for a couple of days. 
>I think I'd like to take your points out of order, as the second 
>part may shed light on the first...
>>>I view "arcs and nodes" (as in directed labelled graphs) and 
>>>"triples" as different presentations of what is fundamentally the 
>>>same syntax.
>>I would respectfully suggest that you might want to re-think this 
>>identification; or at least, that you distinguish *syntax* from 
>>*structure*. A single structure can encode a variety of different 
>>syntaxes, but the logical semantics needs to have the actual syntax 
>>to attach to, not its implementation structure.
>You are right that I have not been clear about "syntax" vs 
>"structure":  I had been treating syntax as a kind of structure.  If 
>I interpret you correctly, "structure" refers to some way of 
>constructing information composites from component parts (lists, 
>arrays, sequences, tuples... even triples).  Syntax, on the other 
>hand, describes a a set of rules for construction of valid 
>sentences;  thus, a syntactically valid sentence has not only some 
>surface form, but an associated parse tree - to which the semantics 
>might be attached.
>Am I on track so far?

Yes (other than your use of 'valid', which has a different meaning in 
logic. Terminological quibble only.)

>I had thought I was treating graphs and triples in the syntactic 
>sense when I made the claim above.  But I'm beginning to see that 
>the syntactic structure of just triples is too simple to provide 
>hooks for meaningful semantics.


>I think you may be saying that, in order to attach meaningful 
>semantics, certain values or sets of values that appear within the 
>triple structure must be recognized as distinguished symbols in the 
>syntax, in order to be able to say that they have specific 
>associated semantics.

Well, *something* needs to be indicating which parts of the 
triple-sets are being used to indicate logical syntax and which are 
genuine assertions. Using special values is one way to do it.

>For example, for "reification" to be at all workable as a mechanism 
>for attaching new semantics to RDF graphs, the properties and 
>classes that are used by reification must be recognized as distinct 
>syntactic symbols with specific syntax productions governing their 

Well, reification is clearly indicated in current RDF. The point is 
more that some of these reifications are genuine reifications, but 
others seem to be being used to encode syntax, and there is no way to 
tell which is which. (However, I will admit that Dan Connolley's 
recent message 
suggests that by careful use of quotation and invoking a 
truthpredicate (wtr) to do appropriate dereification, the whle thing 
can be made to work, and as far as I can se he may well be right. I 
guess my reaction is that this seems like a very longwinded way of 
encoding syntax, and one that is potentialy dangerous, since a single 
missing quote mark will change the intended meaning drastically.)

>So, to defend my original statement above about the equivalence of 
>"arcs and nodes" and "triples", I should have described them has 
>"fundamentally the same structure".  Or I could choose to view them 
>as the same syntax, but that would be a syntax that is fundamentally 
>too primitive to serve as a basis for any useful semantics.

OK, fair enough.

>At 11:41 AM 5/29/01 -0500, pat hayes wrote:
>>>At 01:52 PM 5/27/01 -0400, Jonathan Borden wrote:
>>>>This argument is oft stated. And in the early days of software, similar
>>>>arguments were made regading the lack of ability of a high level 
>>>>language to
>>>>express anything beyond what is expressed in machine language.
>>>That is very different from the argument I am advancing.  I am 
>>>saying that triples are something in which the various "high level 
>>>languages" of resource description might be grounded, and 
>>>(assuming adequate semantics) through which the various forms of 
>>>"high language may" be related.
>>Let me home in on this. A problem, I think, with a lot of this 
>>discussion, is that words like 'grounded' and 'related' are used 
>>without being clearly defined. There is certainly one sense in 
>>which any notation can be 'grounded' in triples, or represented as 
>>triples, since any graph can be encoded as a collection of triples. 
>>OK, let us agree on that. And these structures can be used to 
>>encode all of the syntactic forms of  various "high-level" 
>>languages, which can be provided with suitable semantics, 
>>presumably. All of that is uncontroversial.
>Yes.  But I had hoped that "grounded" might be a stronger idea.  See 
>my final comments below.
>>The heat is generated when one tries to fit these together. The RDF 
>>model tries to attach the semantics directly at the triples level, 
>>which forces it to use reification as a kind of universal syntactic 
>Aha!  In consideration of the first part above, I think I see a 
>chink of light here.
>> That is what some of us find an unacceptable trade-off, as it uses 
>>a huge burden of semantic expressivity (KIF is probably the only 
>>formalism on the planet with a fully defined truth predicate, and 
>>even that has never been used in practice by anyone, as far as I 
>>know, and is likely to be eliminated from the new KIF standard) to 
>>purchase a tiny advantage in interoperability (the property that 
>>any set of triples is well-formed.) Also, we are pretty sure it is 
>>going to lead to problems later: it is notoriously easy to produce 
>>paradoxes if used casually, it renders any 'genuine' usage of 
>>reification semantically suspect, and so on.
>... but now you've lost me.

Well, reification is almost unknown outside the RDF world; it is 
generally considered a very exotic and rarely-used device, only put 
into a few languages to keep the damned theoreticans happy, and so 
on; and so it seems odd to see it being used at the very simplest 
level of the langauge to do the simplest kind of propositional 
syntax. That is only an aesthetic argument,  but it might help to 
explain the intensity of the feelings in these discussions. The basic 
point is that there seems to be no rational reason for using it, 
other than RDF being forced to use it in order to avoid having any 
kind of syntactic structure above the lone triple, and this in turn 
seems to be a matter of doctrine, with no rational basis for it.
The 'problems' arise if we ever want to have genuine reification (as 
opposed to reification being used to encode syntax), eg of the 'John 
said "...."' variety. That had better not be interpreted as merely a 
syntactic encoding, or the reasoners that really need to be able to 
handle reification will not be able to distinguish reified encodings 
of transparent contexts from genuinely opaque contexts, and will 
prodice invalid conclusions (any with the careless use of negation, 
paradoxical conclusions.)

>In other messages, I've tried to explore the possibility of using 
>"reification" to achieve some stated goals *without* requiring a 
>truth predicate.

I will need to go back and look at those again.

>What I'm taking from this exchange is the possible idea that this 
>cannot be done based on the syntax(sic) of triples alone.  For this 
>one needs (at least) a richer syntax that, if encoded in triples, 
>recognizes special combinations of triples, such as "reification" 
>and others, as distinct syntactic constructs.

Yes, I believe that is the case. As I say, it MAY be possible, with 
enough ingenuity, to do it all using reification and 
truth-predicates. BUt I see no pressing reason to base what is 
supposed to be a robust interchange langauge on such a delicate 
conjuring trick.

>>>> >
>>>> > I think their is a fair community investment in the triple 
>>>>form, and that
>>>> > it should not be discarded unless we are certain that it is 
>>>> > inadequate.
>>>>I submit that the community investment is in _arcs and nodes_ not triples
>>>>per se.
>I think the investment is in both.
>In view of the above comments, I would suggest that the 
>"interesting" challenge here may be to devise an abstract syntax for 
>RDF that *can* be encoded in arcs+nodes/triples/XML in a way that is 
>consistent with current implementations of RDF applications.

I agree, that is an interesting challenge. I will get back to you on that.

>I don't think I've said anything significant above that hasn't 
>already been said by you or others.
>But something that exercises me is the possibility that there might 
>be a "basic RDF", complete with model theoretic semantics, that 
>corresponds approximately to Existential-Conjunctive (EC) logic [1], 
>and one or more "extended RDF"s that share the same EC-based 
>semantic foundation, even though they add different semantics on 
>top.  Roughly, this would mean that any RDF expression that used 
>only the EC subset would be interpreted equivalently by different 
>"extended RDF" systems.
>Why do I think this is an interesting, maybe useful idea?
>(a) it provides a common, simple basis for representing ground 
>facts, and exchanging them between systems.
>(b) it is very simple to implement for applications that don't need 
>to do any more than interpret ground facts.
>(c) I have a hunch that it is compatible with the use of RDF by many 
>current applications.

I agree that is a desireable outcome. I dont think it can be done 
without some 'damage' to RDF, but I think the damage can be contained 
sufficiently to preserve most backward compatibility.  I agree with 
you about "EC logic" having genuine utility, although RDF is actually 
a restriction even of EC logic, since it allows only binary relations 
to be utilised directly.

Pat Hayes

IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
Received on Thursday, 31 May 2001 12:05:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:45:38 UTC